*"Yea if you want all the super dooper features of a high end version you pay, but you don't deliberately make the low end version conk out on same memory that high end version can handle."

As Xenophonz mentioned...... it's called Vue and E-On did excactly what you describe.

You should find that turning the "Cloth self-collision" option on helps in situations where there are going to wrinkles.

Cloth self collision was on, although that was secondary to the point I was making - big polygon creases even though smooth polygons was on.

Babylon 5? hehee.. had freinds actually working on the effects for that. Loved it in it's time, but like many pioneering cgi tv shows, it's effects haven't stood the test of time too well. The later seasons still look good, though, since there were lightwave advancements.

And for the record, back then Lightwave cost more then $2,000, and a video toaster add on would have set you back another 2-3 grand as well. You forget, I was using lightwave back then.

And you didn't use an amiga 500, you used an amiga 1000 or 2000  (later 2500) fully loaded for bear. My one freind had 5 amiga 200 systems networked together (networking alone set him back almost $1000 back then!), and his loan to set up his amiga videotoaster studio ran him $50,000. I well remember him, because that loan and the amount of time invested in setting up his studio almost cost him his marrage.

He currently still is a lightwave teacher at Dave's school. (Last time I spoke with him, which was last year.)

So don't say you could product B5 on a $200 system.. then as today, you needed state of the art hardware and software, and the costs were FAR from consumer based. I REALLY wanted a video toaster, but just couldn't come up with the $4,000 just for a 3d toy.

Even a single still frame render back then on my amiga 2000 would take overnight. Doing TV production on lower end hardware was unthinkable, because 30 frames (1 second) would take you 30 days to render!
 

Stewer: I know ab't the checkbox in the item Properties tag... OTOH, I never knew you were converting it into a pure NURBS object - is that what you're truly doing with it? If so, I am curious - what's the big holdup? I'm not asking to be snide, I want to know (out of curiousity's sake) what steps are occurring during 'clothification' and collision detection - I can take some decent guesses by now, but I also know there would be some gaps in the process that I don't quite grok if I were to guess. Between my own research on the subject and seeing what others out there have done, you've apparently got some big bottlenecks in there that need to be opened up. -- PJ: You pointed out another niggle of mine :) Incidentally, the simulation I pointed to at humus.ca isn't an animation - it's all being calculated and rendered (and dynamically lit as well) in real time. Meanwhile, a miniskirt prop for V3took 5 minutes (?!) to calculate collisions against... a 'floor' made from a large simple low-poly square. A dual Mac G5 + 2GB of RAM, in spite of its relative age, isn't exactly low-end hardware, y'know? --

Quote - " So don't say you could product B5 on a $200 system.. then as today, you needed state of the art hardware and software, and the costs were FAR from consumer based."

...umm, I've heard this argument before... typed at CGTalk, in reference to Poser users. You sure you want to go there? -- /P

Quote - I know ab't the checkbox in the item Properties tag... OTOH, I never knew you were converting it into a pure NURBS object - is that what you're truly doing with it?

REYES renderers dont actually render polygons, they render what are called bicubic patches. By default FF renders these patches at a rez of 0, ie the cage mesh which is identical to the polygons in your scene. However all REYES renderers can render these patches at increasing levels of subdivision as well. When you enable the 'smooth' option, FF simply raises the subdivision level and you get a smooth mesh. This is also why 'smooth' does not have a large render hit, since bicubic patches are inherently smooth to begin with.

(This is a guess based on experience with REYES apps, but it's probably accurate in FF as well.)

Quote - > Quote - I know ab't the checkbox in the item Properties tag... OTOH, I never knew you were converting it into a pure NURBS object - is that what you're truly doing with it?

REYES renderers dont actually render polygons, they render what are called bicubic patches.

That's cool - I mean no offense here, but we aren't talking about "render" in the same sense. When I say "render" in this context, I mean what the active workspace window throws onto the screen via the vidcard's GPU, not what gets finally calculated and fixed into a potential .jpg/.psd/.mpg/etc. A 3d programmer knows that the word has two different meanings - one is the big fat process at the end that most folks here are familiar with when the word "render" is written; the other (what I'm referring to) is more akin to getting the information thrown onto the screen and back to the engine as a "work-in-process" representation of where all those little vertices are and how they're lit. OTOH, most folks in here prolly don't know the difference offhand... my bad. The point I'm getting at is this: there is collision detection that can be done and represented in realtime (as in the humus.ca example), while even with Poser-like clothing, it can probably be done in far, far faster times than what we're seeing right now. Perfect example: if your NURBS-capable modeller has a "drape" function - try it out... in pure NURBS, it's damned fast... add a bit of constraint on half-edge lengths (so it didn't distort down to the floor), and it would be a golden example of what dynamic clothing could be. /P

Quote - Perfect example: if your NURBS-capable modeller has a "drape" function - try it out... in pure NURBS, it's damned fast... add a bit of constraint on half-edge lengths (so it didn't distort down to the floor), and it would be a golden example of what dynamic clothing could be.

One frame of any highly constrained and limited sim is always fast. Can you 'drape' with wind or self collision or in multiple directions in your NURBS modeller ? Can you get your cloth to be cut or react to cloth weight and weave ? Can you adjust it's shear and stretch resistance ?

Your idea, though cool, is founded on your assumption that the 'speed' you are seeing in drape is because of NURBS. While it is actually from the fact that 'drape' is to cloth sims what a 'pose' in poser is to a muscle system.

And NURBS are horrible candidates for any spring system anyway. Polys are basically a network of connected points, which you can simply map to the springs. What would you do with a NURBS surface with trims and stitched surfaces and what not. You would either have to tesselate it all to a polymesh, which is dodgy at best, or make do with the control cage which would be very inaccurate.

Quote -
The point I'm getting at is this: there is collision detection that can be done and represented in realtime (as in the humus.ca example), while even with Poser-like clothing, it can probably be done in far, far faster times than what we're seeing right now.

Sure it can, and is in advanced cloth sims like syflex. Which BTW costs 10x what poser itself does. And incidently, syflex a pure poly cloth sim. Tells you something doesn't it.

Quote -   25 apollo max meshes (total 2 million polys)

Just a small mention. Apollo is exactly 40,000 polys. * 25 = 1,000,000 polys.

Quote - > Quote - Perfect example: if your NURBS-capable modeller has a "drape" function - try it out... in pure NURBS, it's damned fast... add a bit of constraint on half-edge lengths (so it didn't distort down to the floor), and it would be a golden example of what dynamic clothing could be.

One frame of any highly constrained and limited sim is always fast. Can you 'drape' with wind or self collision or in multiple directions in your NURBS modeller ? Can you get your cloth to be cut or react to cloth weight and weave ? Can you adjust it's shear and stretch resistance ?

I don't see why not - the sim I pointed at is only to display one limited function, but with lots of other aspects tied onto it at the same time. Whether it scales up and would survive within Poser's environment I do not know fully - I've only experimented with it lightly against D|S' SDK-exposed functions - even there it would take a bit of internals modification to use that particular rig, but it scaled up fairly well. I wouldn't use it however due to IP issues. > Quote - Your idea, though cool, is founded on your assumption that the 'speed' you are seeing in drape is because of NURBS. While it is actually from the fact that 'drape' is to cloth sims what a 'pose' in poser is to a muscle system.

Not necessarily. While I do believe that the increased speed is due to not having to calculate for each and every vertex, I don't believe that simply being a NURB is the reason why. What I do believe is that if you can reduce the effective number of edges and control points to calculate against, you get a faster response. NURBs is just one of a handful of different methods. > Quote - Polys are basically a network of connected points, which you can simply map to the springs.

Oy... that would slow things down considerably... first off, tying a spring to a pair of half-edges, okay... I can grok the idea you're getting at (and everything is already nice and delineated right down to the very now-predictable initial vectors of those springs, which makes it attractive at first). OTOH, if you take a typical 5,000 poly mesh (say, a knee-length ruffled skirt for V3), you're liable to have roughly 10,000 or so springs (prolly more) to deal with (depending on the # and distribution of tris, quads, and n-polys in the mesh, etc). Calculating collision detection on each vertex against the world is going to eat CPU as it is - now you want retention/stretch info tied in to each and every edge-pair? With an .obj file that has morphing info and possibly joint/quat rotation info tacked onto the top of that? I dunno about you, but these things take forever to read-in to Poser as it is... > Quote - Sure it can, and is in advanced cloth sims like syflex. Which BTW costs 10x what poser itself does. And incidently, syflex a pure poly cloth sim. Tells you something doesn't it.

It does... it tells me that they've either figured out one hell of a nice algorithm, use sub-D and very low-poly mesh, don't use an ASCII format for the file, or that they break it all down internally into something else entirely for calculation (or, possibly that the mesh file being read-in for this is a binary file already chock full of octrees and other sim-friendly structures, or...). I'm not sure what they are using, but I am willing to wager that it wouldn't natively accept anything like a .cr2/.obj pair. I'm not saying it ain't possible, but I am saying that doing that to a traditional Poser-friendly .obj file in typical mesh densities (and scaling... ugh), simply ain't gonna cut the mustard. /P

I haven't read all of the posts in this thread (all 14 pages), but i would like to add, Why the hell is 64bit compatability limited to poser pro?????
64bit processors are NOT limited to professionals, they are as processors go relatively cheap compared to some of these monster processors that CGI companies use, we could all have 64bit machines at home.
ok RenderFarm is in the world of the Pro as after all how many of us can afford 50 PCs ??? not i, sadly,lol.
Im now gonna hope that EF notices that some of the great unwashed (i will bath when i can leave poser alone) and make P7 owners have a 64bit upgrade option without spanking us for the price of Poser7PRO..
thats my rant over with.....

Unfortunately, the 64-bit processor/OS is still a fringe market.  There are more people moving to them lately, but not enough for most companies to make an effort - see most similar complaints about MacOS support.  It'll probably be a couple years before the conversion is enough to warrant such support.  That said, some companies aren't waiting and have already provided such support - like 3DSMax and Cinema 4D.

To emphasize the fringeness of 64-bit OSs at this time, not even Apple will bend to create a 64-bit version of QuickTime which, for its ubiquitousness, is appalling!

I get the impression from reading Cinema 4D's cloth docs that simulating over a perfect sphere is mathematically a lot simpler than it is for other surfaces.

Yes, they use a 'procedural' operation with a sphere object to expedite the simulation calculations in such cases.  Spheres are notoriously simple mathematically. ;)

Quote - Unfortunately, the 64-bit processor/OS is still a fringe market.  There are more people moving to them lately, but not enough for most companies to make an effort - see most similar complaints about MacOS support.  It'll probably be a couple years before the conversion is enough to warrant such support.  That said, some companies aren't waiting and have already provided such support - like 3DSMax and Cinema 4D.

To emphasize the fringeness of 64-bit OSs at this time, not even Apple will bend to create a 64-bit version of QuickTime which, for its ubiquitousness, is appalling!

I agree with this 100%.  64-bit is doubtless the wave of the near future, but it's not in common use yet.  I wonder if 128-bit will already have arrived on the horizon for general use by the time that most everyone finally switches over to 64-bit............

Most of the people that I know who have 64-bit OS's end up with some software incompatibility problems.  Others get around the difficulties by using a dual-boot setup.

64-bit Poser is actually a 'bit' ahead of the game, IMO.

I guess we'll need 128-bit support when the 17 billion GB limit becomes an issue.

I was half-joking in that post......but:

I am reminded of the statement supposedly attributed to Bill Gates regarding 640K being all of the memory that anyone could ever possibly need.  He vehemently denies that he ever said it: but I'm still put in mind of it.

I also once had an engineer who was inordinately proud of his personal 386 PC raise the question as to why anyone could possibly need "all of that power" in regards to the (then) soon-to-be-released 486 processor.

shrug

When it comes to computers, I've gotten away from making any blanket observations on the impracticality of whatever might be coming down the pike.

trying out carrara 6 pro. seems to work o.k. faster than previous versions. imports poser pz3 files after one locates the poser default runtime. it doesn't appear to import the camera nor light(s) associated with the pz3 file, but perhaps I should read the manual first.

You will most likely find that the lighting is better in Carrara. I delete the lights before I save the Pz3 to use in C5Pro. I would think it the same for C6. I won't upgrade for a couple of weeks to let give the frothing mobs a chance to get thiers.Besides, I need to cool my CC off a bit after buying Modo and preorder of Modo301. Which is payed for already this month. LOL

Seems all these upgrade tend to come out around the same time of each other.

yeah, beryl, but I wanted to see if I could get templar's cornell box into c6pro to compare results. for that I need the special light that comes with it, exactly in the right place. p.s. the total download is 1010 MB.

I see, said the blind man, as he waved his hammer and saw. LOL. I been reading at Daz about a few Poser problems to C6. So much for the improved Poser import. LOL

1010MB. I'm glad I'm waiting a couple of weeks. Bad enough at how slow the forums are let alone DL speed. Sometimes it pays to be last or at least makes life easier.

Quote - You will most likely find that the lighting is better in Carrara. I delete the lights before I save the Pz3 to use in C5Pro. I would think it the same for C6. I won't upgrade for a couple of weeks to let give the frothing mobs a chance to get thiers.Besides, I need to cool my CC off a bit after buying Modo and preorder of Modo301. Which is payed for already this month. LOL

I've bought Modo 103 also -- the Luxology website states that they won't charge your CC for the 301 upgrade until the software ships.  They didn't charge you immediately, did they?  I ask because I'm about to do that myself.

Quote - Seems all these upgrade tend to come out around the same time of each other.

Yes.......this seems to be the season for software upgrades.  I don't think that I've seen them all coming so tightly packed together as this before, though.  The competition must be heating up.

No you don't get charged until it get's released. My case was special. They had mistakenly proccessed some of the orders. Mine was one of them. They phoned me to let me know that the money was refunded and I would need to re-order. I they were quite nice about it and as I had pre-ordered 301 in the first place, they let me have the 203 with the free 301 upgrade at the preorder price. Some I think, they gave one or thier tutorials for themistake.

So, Mine is already paid for and I get to catch up a bit to 301 with the 203 version. Worked out fine for me. I keep getting amazed at what Modo can do. So waiting a couple of week before I upgrade my C5pro is no big deal. I'm just having to much fun with Modo right now. Plus It's nice to go to thier site and not have to listen to any Poser bashing. They seem to think of it as anther tool. looks like some tutorials there for Poser/modo use. You gotta like that. LOL.

Nothing wrong with competition, the better for us.

Hmmmm.......makes me wish that they'd make the same mistake with me, then.  :sneaky:

Yes, I've been impressed with what little I've been able to see of Modo so far.  I haven't had the time to go into it in any depth yet.  And I probably won't have the time for several more days.  Grrrrr.........

Quote - Nothing wrong with competition, the better for us.

Definitely true.  But it can also add up, needing to upgrade 7+ different 3D software packages once every 6 months or so.........

PJ: You are correct - a sphere is stupid-easy to calculate against (esp. in collision detections). OTOH, I can confidently say that I've calculated a ~1050 poly clothing item against a morphed PT Milgirl mesh in less than 30 seconds (Thorne's Ziza, to be precise). If I had a Qt license (forthcoming), I could finish my little project, get some smoothing action on, and have a little plugin I've been working on finished... The trick to save time is to knock off the parts of the mesh you don't need to collide against. For instance, take a typical miniskirt. You don't need to calc it against vert-heavy parts like, say, the figure's head, and in reality it breaks down to just six parts at most: hip, abdomen, buttocks, and thighs. Not the 20+ some-odd parts of the body, but merely six. One could also check to see if any other parts are within n units of the cloth (before and after the initial drape), and check against that as well. Wind and other effects can be done after the initial drape, as an option. This way it doesn't waste everyone's time calculating against a null option. ;) But... c'est la vie. The next version of D|S is liable to moot the little plugin I've been tinkering on and off of anyhow. /P

So why don't you just export the parts you need eg. Abbs/hip/butt/thigh for a dress and point a simple Cr2 at the new .obj. If you have saved the pose you are using, it would be a quick drape. I do that quite often when I model clothes. I rarely use a full figure for my dynamics.

...because it would be much easier and less time-consuming to do all of that virtually? /P

True, I was just saying that it can be done now. But I don't understand why ef didn't  add a check list for the rest of the groups other than hands and feet. Or, is it because it's a programers view instead of a users need.

Quote - Or, is it because it's a programers view instead of a users need.

You've just explained 90% of a typical user's frustrations :) (It also explains why Linux --up until Ubuntu-- was pretty slow going sometimes at the desktop market...) /P