ggaliens

Well ... if polygons can be "STREAMED" through a graphics card into a 2D framebuffer as some folks have at least alluded to (and would make some sense for Cards to work this way in a perfect world ) maybe I should accept no polygon limit ???? Seriously. Why not have "Stand-Ins" for some Objects (SEE MIPMAP in wikipedia and thing 3D analog for MIPMAP) ??? Sure this is not an existing feature ... but it would make a great test for how graphics cards work. If polygons can't be streamed ... and we can't have my Billions of polygons by streaming them from DISK in a not so tricky way (should be extremely simple), then the fallout is that Cards do inherently have a MAXIMUM MAXIMUM polygon limit in addition to a MAXIMUM framerate with a given polygon set. As it turns out ... I was probably mistaken about my assertion that my card has 256MB Ram. I think in fact I was biased by someone elses suggestion that an NVIDIA 8500GT has 256MB. NVIDIA 8500 may come in at least two variants 256MB and 512MB). Shame on my for not finding that control panal a long time ago. My NVIDIA Control panel does say 512MB. So I'm now thinking that when I went to my buddies house to test on 64bit machine ... he may well have had less memory than me on Graphics card. So maybe explains a bit of why 64bit 8GB main RAM didn't make the experience that much better. There was another bottleneck that got tighter. I'm a programmer 9-5 in multimedia and video compression ... and I know that it's not always easy to diagnose root causes of bugs in a complex system such as 3DCoat. I don't have the source code. But I do see some of the BUG-REPORTS that pop up in the Web-Browser after a crash. I try to envision what they might mean ... and what I can't deduce from them. If Andrew says a 1GB Graphics card is cheap ( I think he did ), then I do hold out some hope for more polygons in the near future. I WANT 100 Million polygons in my scenes. I want to be able to work with 20 Million in memory at once. That should be enough for me. I want to be able to off-load some to DISK by keeping aorund only PROXIES in memory since in VOXEL space a proxy should be super easy to calculate. I'm dreaming big dreams, I know. But I think Andrew can get us lots more polygons ... with some clever tricks.

Add another flavor of hidden VOX Object ... Hidden on DISK as opposed to Hidden in Memory. Hidden on DISK items should have the option of being rendered as a LOW-RES Proxy version of what is hidden. Which brings up a related subject .... Aren't VOXEL Objects the perfect candidate for implementing PROXY or STAND-IN objects of much much lower resolution ??? Much simpler than in polygon space. Why not develop a Version of a VOXEL Object that is more or less "FINISHED". Meaning it would be in a less immediately maliable state where it would contain a few levels of PROXY Objects. You could implement as a 3D version of MIPMAPS in voxel space. If the user wants to edit ... then there is a pause/penalty for changing his mind back to unfinshed. Simple. http://en.wikipedia.org/wiki/Mipmap If you were careful about putting all these ideas together ... you could probably give users 200 million to 1 billion polygon rendering capability with very little extra technology beyond what you already have developed. A simpler but less inspiring way of saying all the above might be ... Why Not have a way of having only PART of the scene in memory at a given time ... like not so much of a scene ????

"Alpha software and bugs, go hand in hand. " Right ... and there has to be a ROOT cause for every bug. THE ROOT cause is not ... "It's alpha software". And in this case ... since the bug only appears when system resources are very demanding on both the main RAM and the graphics card. And since I can't "MEASURE" the demand on the graphics card in as direct a manner as I can mesure the PAGING files and RAM usage ... I have to be at least a little suspicious of having an under-performing graphics card where ULTIMATE capacity is concerned. I am still of the opinion that a graphics card borrowing resources from the system is probably a very bad thing ... and this may very well be what I have going on on my machine. I have no complaints about brush speed at all. I understand that they all have inherent speed limitations of their own. I'm definately getting mostly OUT OF MEMORY ERRORS. But I would not trust 3DCOat to be categorizing these OUT OF MEMORY ERRORS with anything but large "sweeping generalized buckets". I know my self that I'd be hard pressed to write code that always proeduces a most meaningful error message that cannot be misconstrued. So I'm happy to continue investigating the likelihood of this being a case of lame graphics card.

I'm not having any problems with sufficient frame rate with high polygon count. If I was ... I would have talked about that. Turn off shadows ... and I can quite easily VOX sculpt on 10,000,000 polygon model. My problem is with instability, crashes ... all seeming to happen when the program have to do a VOX merge, smooth, combine, ... a object level vox transformation , tweek of some kind. I'm very suspicious that I need a new graphics card ... but there are some folks who say my card should be borrowing from my system memory. If that's the case ... then why do I still have problems on a system with 8GB Ram (testing on such system the other day, 64bit Vista). I'm trying to gather information on how other folks systems are behaving. Andrew has an aggressive schdule for delivery of V 3.0 with VOX as far as I can tell ... and in another thread, he is talking about getting pretty down and dirty with stats and testing on more hardware. No time like the present to start formulating a test plan.

----------------------------------------------------------------------------- That is question of program stability, not really Video RAM issue. Inc res seems take more memory then need on intermediate stage. It can be tweaked and improved. Also, it is important, have you set /3GB in boot.ini? ---------------------------------------------------------------------------- Andrew ... if any single part of the system resources chain would be "maxed out", I'd expect pretty odd behavior ... including instability. Why would VIDEO Ram paging not lead to instability ??? A DisplayList is a batch of OpenGL commands needed to construct a frame of video. In a perfect world, my displayLists would not be pages or shared into many separate memory subsystems. In order to figure out what is wrong ... sometimes one has to suspect and point a finger at a lot of things that are not wrong (this is called working through ones own confusuion). You know what I mean. I just did a short search on how folks feel about Video cards stealing system RAM. Seems I'm not the only paranoid one. It may very well be that lots of video Cards do this ... but it does not mean that it should be considered best practice to allow this to happen. I did set the /3GB setting.

OK ... JokerMax ... Andrew says that .... 128 MB = 3 728 270 vertices So this probably means THAT LOTS AND LOTS of 3DCoat VOX users are having memory swapped in and out of the VIDEO Card ram. This seems like a VERY Huge problem for users. I'd caution any users against developing a workflow where VIDEO Ram gets paged in an out in order to support large displayLists. But how is a user to become aware this is happening ??? Like GI Joe saided ... knowing is half the battle (And maybe no the easy part). Furthermore ... even if a video card can (in the generic case) do this kind of paging ... I'd be pretty doubtful about how well it would work. It seems like a bad idea. I think Andrew should take the time to investigate what a displayList is and maybe report back his findings regarding the wisdom of paging displayLists into video RAM a bit at a time. Just seems like a horrible idea to me. I'll try to get more information myself ro bring back here. So far ... the pikins are slim. The big question is ... can your OpenGL programmer identify and flag when a display list is so large that it would have to be streamed to card in parts in order to build a frame of video. If he can ... then displaying some kind of warning might be a great idea. TEXT IS CHEAP ... LIKE RAM. So I type a lot ;-)

Mine is not too slow in Frame Per second. I can do 10 million polygons or even 20 million and get sufficient frames per second at the scene level. Then I turn off visibility for sub-object to get down to maybe 8-Million showing with no shadows ... and I'm OK for modelling. GED ... thanks for sharing. Mine is slow and crashy when it comes to doing MERGES, RES CHANGES, UNDOS, etc ... things where what's going on with Memory are dynamic, but not so well understoof at user level. But my most recent problem is that this does not go away with 8GB RAM and 64 bit machine. Still similar freeze problems and lack of progress bars feedbacks, etc. A couple well constructed progress bars might go a fairways towards eliminating some consternation. There exist a few ... but a bunch of progress bars ar missing (Particularly on import OBJ files).

----------------------------------------------------- But expected count of polygones if not very dependent on video card, video card gives you speed. Count of polygones is dependent on RAM. I really have no statictics about Polygones(RAM), but I witt try to make it when my ---------------------------------------------------- Let's try to explore the implications of what you just said above. 1) Are you using DisplayLists in openGL. I assume you must be. If you are ... then am I to infer that a display list can be streamed to an OpenGL / NVidia card ??? Somehow that does not sound likely to me ... but I'm no OpenGL expert. Just a guess based on intuition which might be flawed. I know that a Video Card must convert OPENGL commands to a pixel frame buffer on the card. But one would think that that the pixel frame buffer is not filled in the following manner ... Polygon count gets huge so most video card RAM is filled ... POLYGONS converted to pixels. More polygons loaded to card ... more pixels created. Finally ... 2D frame buffer is dumped to display. This seems too complicated to me Andrew. I think entire scene is on card at same time. Which means there is a polygon limit. Prove me wrong. Send me an educational link. Do you really know how this works at a hardware level ??? Fairly advances question I'd say ... but perhaps an important one if the 10 million 20 million, 30 million polys are filling my grahics card RAM. From you reaction ... I'd ahev to assume you belive the polygons are streamed into the Frame buffer so that a display list of "set" of polygons in a scene don't have to all be on card at one time. Personally, I don't belive it until I see it in writing from card manufacturer. I believe that all polygons in a displayList or it's DIRECTX equal (scene) would be on card at same time. Video Card frames per second is an entirely different problem in my mind. But where can I get intelligent description of these processes ??? Maybe I can't. The typical solution for developers as well as users is .... TOSS MORE $$$ at the problem. But new hardware. Well, this is a problem of finding the "WEAKEST LINK" in a complete hardware package. I still don't know if it is the graphics card. Pehaps the BUG reports and the call stacks I send you mean something. I hope so. I am working VERY HARD, at trying to discover the source of my frustrations with the Coat. I go frome elation and joy to frustration ... as should be the case. THIS IS ALPHA TESTING. So please bare with me as I work though my hardware issues.

It's not about what was said before. It's about what was NOT said before. You don't have best statistics coming in from your user base (which must be growing). You need to collect performance stats so you can help people spend their money wisely. If you have such stats ... you are not sharing them in a meaningful way. Before you said "MEMORY IS CHEAP LIKE DUST". If I take this at face value ... it mean I need to either buy 4GB since I only have 1.5 GB main system RAM. Or I need to borrow a machine. I chose to do the latter. I tested on a 64bit machine with 8GB RAM yesterday on my 17,000,000 polygon scene. The performance was NOT much better (just a little). This makes me wonder if graphics card is the bottleneck. It might very well be. ** I don't see A spot on your Forum where I can get a feeling for how many polygons to expect (A VOX IS RENDERED) from a NVIDIA 256MB, 512MB and 1GB Cards. I'd like to see this kind of information being collected from the field of users, and then reviewed and certified by someone with experience ... and most importantly, organize in a meaningful easy to understand chart. I still crash when assembling a scene ... about 4 out or 5 tries at assembling a scene ends in 3DCoat crash. I go to task manager and kill. And I ain't no dope when it comes to doing an analysis of bottlenecks. The problem is I just don't have the system resources and hardware needed to do all the empirical testing. If I did ... I would. Let's get all the performance based threads in one spot and get them organized, and recruit some good analytcial testers to help write up a better F.A.Q. for VOXEL sculpt.

This thread should be rolled into the graphics card thread IMHO. And if MUST but a new CUDA NVIDIA Card ... then this is a very important fact. Sure changes the price for 3DCOat. For me ... changes the price from $200.00 to $300.00. I bought a new NVIDIA card about 1 year ago. NVIDIA GeForce 8500 GT. And now I find it is no longer any good for this app ??? Well ... then I must consider it part of the price of getting 3DCoat. You can break it down mentally however you see fit. But this is the way I see it. I think due to the buggy Alpha, missing progress bars (see VOX import), and other considerations ... you might want to think about extending the alpha another few months to get this thing right. Otherwise ... I might have to toss down another couple hundred and get ZBrush instead. I love 3DCoat ... and I do see it moving along well. But having to buy a new Graphics card is a huge consideration for me ... even if it's just another $100.00 card.

Guys .... Andrew ... you recommend 512MB card ... but you don't suggest what the upper limit for that card will be in polygons. I believe there is an upper limit because of the 512MB aspect of the card. After all ... a displayList surely has to be on the card all at once, right ??? I mean ... you don't "STREAM" a display list to a card. Someone help me out here. This question has been bothering me. And I want to buy a new card, I just want to know how to predict it's performance.

Common error on OBJ (Wavefont import) ??? I get long spikes or runs of voxels off to infinity or maybe just very long. This is mostly on very details OBJ imports. Is this familiar Andrew ???? Or do you need screen shots and maybe sample models. This is very troublesome bug. If you can't fix this bug (import bug) directly so that the spike-runs never happen ... how about adding a "delete thin features" or "delete by kernel" that would take a very precise neighborhood specification and could run that kernel clean up tricks in a direction from point A to Point B so as to not have to run over entire model (that would be slow). This could be a very nice addition to "Smooth All".

How to "restart" an aborted turn-table render ??? I'm fairly sure there is not way to do this if you have move or rotated you scene post-render. I mistakenly turned my machine off during a render last night. I suspect I'm screwd and cannot finish the last 50 frames of a 720 frame turn table that took 8 hours. If there is no way ... can you serialize the OpenGL stream into a "saved render spec" ??? So that a render can be restarted in an "official way". This should save shaders, lighting, all the render setup. And if I have missed a good re-start feature that's in there already, someone let me know. The don't overwrite frames is in there ... I know ... but that seems like only part of the battle.

I must say I do fill a bit silly for not having tried Blender in the several years since it underwent the big fund-drive. But I'm a Wings3D Plugin developer and I do like Wings3D for medium weight polygon meshes. Wings seems to have enough polygon tricks to make it "CLOSE" to being a scuptor in the hands of someone well versed. See TWEAK and CONNECT modes. Yeah ... its not a realy polygon sculptor ine thee sense fo Hex, Modo, Blender, Zbruh, SILO. It is awsome at medium to medium-low res meshes. I'll be doing more soup-to-nuts 3DCoat VOXEL sculpting soon. PimpMyMonkey ... what video card and video card RAM do you have ??? Mine is NVidia with only 256MB Ram. I think for pure voxel sculpting, I might need to upgrade soon. But I'm trying to gather opinions on this.

I suspect you meant "default shader" as opposed to current shader. Did you know you can easily HACK the GLSL shaders with a text editor if you have the desire. I already made colored clay shader for myself. Andrew will probably need other folks to step up and create shaders to be posted in the forum. The desired permutations of shaders will just be too many for one person to handle.

I don't think a youtube video would add anything to this thread. Let me respecify what it is I'm interested in hearing about. I want to know how a user figures out what system resource is the real bottleneck when 3DCoat starts behaving badly. Bad behavior is slow and painful and not something that lends itself to good video, LOL. I have a feeling that for a lot of users it could be the graphics card. For example, I just sat at a modern DUAL CORE PC with Vista 64bit, 8GB Ram, 256MB NVidia card (bought in fall), and a complex 3DCoat scene. While that 65 bit PC seemed my more powerful than my usual 32bit,WinXP 1.5GB Ram , Single core, HP Pavilion a730n .... That 64bit sculpting session was only marginally more successful than on my HP. The 64bit session ended in a horrible freeze at 30+ million polygons in VOX MOde. 3.4 MB Swap was in use. Maybe 2.x GB Ram. The unknown seems to be what was happening at the interface between the graphics card and the PC. I bet the graphics card was overwhelmed. Andrew ... what can you add to help inform a user when the graphics card is maxed out ??? Anything ???? And I monitor my NVidia card perfomance with an extrnal tool ??? Let's talk about how to discover where the bottlenecks are. Andrew ... you already said Memory is cheap as dust, well ... the dust won't buy me any perfomance if my graphics card is the real problem. I don't want to spend $200.00 on 3DCoat, $200-$300 on a top notch graphics card, and $100.00 on Ram. I might be doing better to buy Zbrush in such a case. So I'm going to have to continue to watch myself so I don't crash catastophically, and figure out the real bottlenecks. My buddy is going to throw a 1GB Grphics card in his 64bit machine so I can try that to see if it will break the 30million poly barrier. WE NEED SOME RECOMMENDED HARDWARE along with predictions of performance with such hardware.

I can do almost 20,000,000 polys (VOX MODE) I have a 1.5GB Ram machine with swap-space set as per Andrews recommendations. How many can you do ??? Can someone with a 6GB or larger RAM and 64 bit machine ... can someone like that comment on their personal experience with 3DCoat ???? How many polys could you do with 6GB Ram, 8GB Ram ??? Some collected stats would be interesting. Andrew, have you tried this VOXEL sculpt on a machine with BIG BIG MEMORY 64BIT ??? Is the VOXEL mode coded to take advantage of 64bit architecture/memory spaces ???? Or would that just tend to blow out the graphics card ????

Art4Med ... Let me jump in here for Andrew so that he does nto have to toot his own horn. LOL. THIS 3DCOAT VOXELS IS GOING TO BE AWESOME FOR YOU !!!!!! Well ... it is for me. I've been having so much fun with the alpha testing. It feels so much different and works just the way you would want. It is so refreshingly different. I've always been awe inspired by ZBrush, but it is just a bit above my price point. 3DCoat might not be nearly as refined due to single developer and new product, but I think 3DCoat will be indispensible for me as an artist, even if I had ZBrush. Time will tell just how awesome it will be. I just need more shaders and some color support because I don't want to get into re-top. And I don't want to get into external rendering. I want 3DCoat to be my one-stop place for Artistic good-times !

Lighting and TurnTable renders Question ... I have noticed that often-times when I set up a turn-table render and light it while the camera is positioned in the front of the object, when I get to rendering the back of the object ... those frames are much darker. The obvious question at that point is .... did I not have the light close enough to OVERHEAD position ??? SO NEXT, I try to position the light much closer to being an overhead light (the light that is not the ambient one) ... the one that controls shadows is positioned overhead. THEN, Do turn table render again expecting somewhat more uniform lighting ... but with almost no difference. Back of object is still much darker. Anyone else think they have exerience this problem ??? Reasonable chance it is really just my problem setting up might lights. But like I said ... light overhead way up on Y axis (I use Wings3D for starting my primatives) should have softened the problem. Andrew, can you add anything for attaching a light relative to the camera ???? I don't mean on the camera ... just in a fix relative location ... as if it were held way out on a "BOOM" or pole over the object being rendered (by the camera guy). Again ... apologies if I just need to learn some more features. Please nudge me in the right direction with some words of wisdom.

JokerMax ... Nice Doodle. Very nice.

Guys ... I'm thinking that some of the new shaders need a control for "frequency". Marble ones in particular. Is this in there already ??? Please advise. Somehow ... these shaders need to be able to elicit their own parameters or at least help the 3Dcoat core to elicit them.

More fooling with 3DCoat and Wings3D. Old models ... new 3DCoat setting and render. Lots of fun. Cave made with hand subtracted from sphere.

I don't think it worked bery well. But could have been USER-ERROR. Still, this should not be a hidden feature. I think the merge help tip should mention that it is invertable. I used the "invert" check box instead. Subtracted a hand from a sphere. Very nice Andrew. Very nice. I love it.

VOX Mode ... Merge Negative (Subtract) Yes as in boolean subtract merged object from current scene ... turn off overlapping voxels. Should be really easy, right ??? Maybe it is in there already and I have not seen it yet ??? Please advise.

Volumetric Shader ... Andrew ... others ... is it possible to write a Volumetric shader in GLSL that would help break up the monotony of how things are colored ??? I'm fairly sure it is possible, based on what I have seen a bit of in Wings3D. Pewter, OldBone, Skin and a few other shaders are cool, but we need a bunch more. And Andrew should not have to make them all since GLSL should be very accessible to any of the part-time graphics programmers out there. All this being said ... MAYBE its already in there and I can render somehow my VOXELS with color patterns ??? With volumetric ... should be able to do Worley and cellular like patterns in color without have to paint them onto the VOXELS. Excuse me if I sound crazy ... but I love this program and I'm thirsty for better built-in rendering tricks, having written a few shaders for it recently, I'm seeing the possibilities. Perhaps even a marble shader like ... http://www.davidcornette.com/glsl/noise.html