Quote - In case you are interested, Vue uses python for scripting - I don't know the details but asking in the Vue forum here (or the scripting forum at Cornucopia3D)  might get you some decent answers.

Well, if it uses python then a python script to switch between preview mode and render mode images shouldn't be at all difficult, assuming Python has access to a method that allows it to do such a thing, and I'm guessing it probably does.

Course, problem is I don't own a copy of vue, but once I get about 40,000 other things off my plate maybe I can look at doing a python script for it :)

Quote -
anyway, my apologies for the bad documentation of the last few poser versions.  unfortunately
it's not the coders who write the manuals, and it's very difficult for tech writers to get the coders
to tell 'em enuff details to write it the way we'd like. 

That's why DAZ had me write theirs for 1.0 - I knew both sides of it. The only thing I would've changed would've been to have more time. I had it fall into my inbox when the previous writer up and left with little-to-no explanation, and only had less than a month and a half to do it. To their credit, the rest of the programming team went out of their way to take time to explain any bits that I got stuck on, and esp. Rob (Code dude) and Nathan (in QA) were excellent critics and ad-hoc editors. :)

--

Anton: stop taking it personally - it's unprofessional and only makes you look silly.

--

Quote - Well, if it uses python then a python script to switch between preview mode and render mode images shouldn't be at all difficult, assuming Python has access to a method that allows it to do such a thing, and I'm guessing it probably does.

You'd be guessing correctly, if the coders are worth a damn. If the app itself can do it, it wouldn't take much at all to expose that bit of API to the scripting engine.

I wouldn't worry about that yet. Toss it on the wish list, IMHO. Not that user requests are insignificant or anything (on the contrary, they're damned valuable), but you've got a big enough hill to climb right now. :)

/P

Quote - [You'd be guessing correctly, if the coders are worth a damn. If the app itself can do it, it wouldn't take much at all to expose that bit of API to the scripting engine.

I wouldn't worry about that yet. Toss it on the wish list, IMHO. Not that user requests are insignificant or anything (on the contrary, they're damned valuable), but you've got a big enough hill to climb right now. :)

/P

Lol - true enough.  Right now I'm concentrating on setting up the development environment.  Did something today that would have the Linux community storming my house with torches and pitch forks if they knew where I lived, I setup a copy of Linux running as a virtual machine under Windows XP 64. 

Yes, I know. blasphemy of the highest order, but my development machine at home also doubles as our primary desktop as well, so setting up a full blown copy of Linux probably wouldn't go over to well with the wife :)

So I'm running a Linux distro under Sun's Virtualbox, must admit so far I'm pretty impressed with virtualbox, seems to run pretty stable and all in all offers pretty much all the bells and whistles VMware does without the hefty price tag.

But I've gotten most of the development environment setup now and the libraries installed, so next step will be mocking up a basic interface and seeing about getting an api built to read Poser format files.  My least favorite part of any job, trying to write code to deal with file formats that somebody else came up with and never fully documented :)

Oh well, once that's out of the way it should be fairly smooth sailing, OGRE already has a lot of the capabilities I need built in, and from what I've been reading ODE will make up a good portion of what OGRE doesn't cover.  Don't get me wrong, still going to be a long haul to alpha, but so far so good

One thing to keep in mind: units in 3D modeling apps bear no relation to real world units, they only describe the relative sizes of objects to each other.
With ODE, things are different. In order to do physics calculations, it needs real world units. One ODE unit equals 1 meter, 1 kilogram or 1 second, the standard international units.
It might be a good idea to adjust imported object sizes to these standard units, so you won't have to scale everytime you send something to ODE (or receive something back from ODE).
Kerkythea is a physics based render engine, and just like ODE, it expects standard international units like meters, In that regard, combining ODE for physics with Kerkythea for rendering would make an even stronger case for real world standard international units for the modeling/posing part of the application!

OGRE comes with some nice examples of how to integrate ODE. Raycasting is also a very handy utility, it'll help determine what object(s) the mouse is hovering over - very useful for selection.
Collision detection might be a challenge, especially if you want accurate detection between complicated geometry. Again, SubD is a great approach to have simpler (and thus faster) collision detection calculations, while the precision of the calculations will usually be enough.
The standard approximation of geometries by primitives won't cut it when you need precise collision detection, but it is certainly good enough for realtime animations or games.

Quote - One thing to keep in mind: units in 3D modeling apps bear no relation to real world units, they only describe the relative sizes of objects to each other..

3dsMax allows you to use metric or feet/inches as units.

Quote - > Quote - One thing to keep in mind: units in 3D modeling apps bear no relation to real world units, they only describe the relative sizes of objects to each other..

3dsMax allows you to use metric or feet/inches as units.

Sure it does. But changing the unit system from metric to feet and adjusting the cameras will get you exactly the same scene as you had before. And a non-physical renderer will render it the same als the scene in metric sizes. To 3DS Max, it doesn't matter - as long as you're not using any physics based plugin (reactor, cloth).

Quote -
Lol - true enough.  Right now I'm concentrating on setting up the development environment.  Did something today that would have the Linux community storming my house with torches and pitch forks if they knew where I lived, I setup a copy of Linux running as a virtual machine under Windows XP 64. 

Yes, I know. blasphemy of the highest order, but my development machine at home also doubles as our primary desktop as well, so setting up a full blown copy of Linux probably wouldn't go over to well with the wife :)

Ain't no sin to do it... best tools for the job under the conditions you're limited to...

Quote - So I'm running a Linux distro under Sun's Virtualbox, must admit so far I'm pretty impressed with virtualbox, seems to run pretty stable and all in all offers pretty much all the bells and whistles VMware does without the hefty price tag.

Nice... I've been using VMWare, Xen, and VirtualPC (on a Mac) for eons now. May have to give it a whirl... what license does Sun put that under?

Quote - But I've gotten most of the development environment setup now and the libraries installed, so next step will be mocking up a basic interface and seeing about getting an api built to read Poser format files.  My least favorite part of any job, trying to write code to deal with file formats that somebody else came up with and never fully documented :)

Actually, this very forum (via the search features) would be a very good place to do some research on the matter. Also google-up Rob Wisenant's home page concerning ERC and other bits and bobs that will likely help you a lot about getting some insight into the Poser file formats. Some other folks to grep for would be Nerd3D, Dodger (and his site at xfx3d.net, I think), and a few others that will come to me once my brain gets out of first gear this morning. I don't think DAZ would have too many objections to helping you grok some of it as well.

Quote - Oh well, once that's out of the way it should be fairly smooth sailing, OGRE already has a lot of the capabilities I need built in, and from what I've been reading ODE will make up a good portion of what OGRE doesn't cover.  Don't get me wrong, still going to be a long haul to alpha, but so far so good

Is OGRE that good for non-game rendering? Heh - I'll have to get off my butt and go take a peek at it. :)

/P

Quote - One thing to keep in mind: units in 3D modeling apps bear no relation to real world units, they only describe the relative sizes of objects to each other.
With ODE, things are different. In order to do physics calculations, it needs real world units. One ODE unit equals 1 meter, 1 kilogram or 1 second, the standard international units.
It might be a good idea to adjust imported object sizes to these standard units, so you won't have to scale everytime you send something to ODE (or receive something back from ODE).
Kerkythea is a physics based render engine, and just like ODE, it expects standard international units like meters, In that regard, combining ODE for physics with Kerkythea for rendering would make an even stronger case for real world standard international units for the modeling/posing part of the application!

Let me second what was written up there... using real-world units may (though not always) mean a loss of flexibility internally, but it helps out everywhere else (as well as helps out the customer/user to boot).

/P

Quote - Quote - "Patorak wrote:
Need original figures for your app?  I'm not talkin' icky Vicky characters or hollow Apollo characters but original figures."

coughs Gotta love that wonderful community spirit among user figure makers; with ryhmes even. What ryhmes with Jane and is equally dismissive of effort and quality? Nah, that would just be lame.

ahahahahaha...snort!...AHAHAHAHAHA!  Stop it!  You're killin' me! 

busted

Of course, if anyone so much as expresses a word of legitimate doubt about any figures you're making, you have a major hissy fit. Aren't you just all give and no take kind of a guy. :rolleyes:

Something else about OGRE that wiould be wonderful for animators: positional 3D audio. Open source, well integrated, and under the same license as OGRE itself. Works very well in realtime rendering, but it should also be possible to make use of it when doing non-realtime animation renders. Anyway, it would beat the pants off the limited audio capabilities of Poser.
Scriptable AI (also available for an OGRE environemnt, open source and free) could also help in setting up long and complicated animations.
In fact, the more I think about it, the more I see a great future for FAST as a tool that can set up an animation as if it were a 3D game or virtual environment, but that also can render video and audio non-realtime at high quality. I don't know of any other application that can do exactly this.

Has anyone seen the new cloth and soft bodies in Bullet?  I was impressed. 

http://www.youtube.com/watch?v=exss517n1I0
 

Quote -
In fact, the more I think about it, the more I see a great future for FAST as a tool that can set up an animation as if it were a 3D game or virtual environment, but that also can render video and audio non-realtime at high quality. I don't know of any other application that can do exactly this.

Which is really all I've waiting for to come along.  Imagine how quickly Epic (Unreal Engine 3) or Crytek (Crysis) could change this business by releasing dedicated machinema tools individuals could afford.

Quote - Something else about OGRE that wiould be wonderful for animators: positional 3D audio. Open source, well integrated, and under the same license as OGRE itself. Works very well in realtime rendering, but it should also be possible to make use of it when doing non-realtime animation renders. Anyway, it would beat the pants off the limited audio capabilities of Poser.
Scriptable AI (also available for an OGRE environemnt, open source and free) could also help in setting up long and complicated animations.
In fact, the more I think about it, the more I see a great future for FAST as a tool that can set up an animation as if it were a 3D game or virtual environment, but that also can render video and audio non-realtime at high quality. I don't know of any other application that can do exactly this.

Ya - I think there is definately a future for this program.  I haven't quite decided how to handle the full spectrum of collision detection yet, primitives  of course for rough animations, but I'd hopefully like to come up with something that is relatively fast and yet gives good enough results.  Always the tradeoff there, the more accurate it is the longer it takes to calculate.

The other thing I thought of today was a distributed computing network of some sort, not at first of course but eventually this might be something to consider.  When it comes to rendering parsing out a render and having to transfer all the necesarry files to a cluster of machines makes it a pretty time/network intensive task and as a result the benefits aren't so pronounced.

But what about a series of servers for doing things like cloth dynamics / collision detection and other math intensive functions?  Since your not having to toss huge image files back and forth, this might prove to be a real boon.

Imagine the SETI project on Linux - only this one dedicated to math calculations for 3d renders under FAST.  Instead of having your PC doing all the heavy lifting as far as calculations are concerned, it connects to a peer to peer network designated for this pupose, tosses calculation packets out to any available servers, coallates the response and applies it to your scene.

Again were probably not looking at something in the first release here, but certainly something I think that could prove to be of huge benefit when it comes to animating and dynamics, being able to use a moderately priced computer to do very complex animation work thanks to a distributed computing model.

Right now I'm hip deep in notes on the rigging system, I need something that will accomodate Posers "Morph the crap out of everything" technology and still be able to handle more advanced rigging with weights and gravity effects. 

One thing I have considered is a rigging "packager" of sorts, allowing you to rerig a figure and release just the rigging info, it would be useless of course to anyone that didn't already own the original figure but it would allow you to apply new rigging to a pre-purchased figure quickly and easily.  Since FAST's internal file system will have a built in database it won't really matter where a file is stored on the actual drive, if the object file referenced exists anywhere in FAST's library it can find it - lol - well fast for lack of a better term.

Quote - Ain't no sin to do it... best tools for the job under the conditions you're limited to...

Lol - well considering how some of your die hard linux folks get I'm still not planning on submitting any screenshots to some of the linux forums I hang out it on occasion :)

Quote - Nice... I've been using VMWare, Xen, and VirtualPC (on a Mac) for eons now. May have to give it a whirl... what license does Sun put that under?

I believe it's under GPL - VMware works pretty good, we use it at work, but I don't have a copy at home and it's still a bit to pricey for my tastes.  Virtual PC, well, it works alright but it has some serious limitations, like 16 bit color, that can make setting up most linux distro's a royal PIA.   Virtualbox has all the goodies of Vmware with tools installed (like the shared folders and such) and detects the color mode of the guest OS.  I had ubuntu desktop up and running inside Windows XP x64 in less that 15 minutes, that's including the time it took me to install and setup VitualBox - pretty much falling off a log easy really.  Ubuntu never knew the difference, and once

I installed the virtualbox tools inside Ubuntu, now it acts like any other applicaiton window under XP.  Like I said, I'm fairly impressed :)  That's actually another first for me, Ubuntu - I'm more of a debian man myself, but under the circumstances I thought Ubuntu would make a better choice, it has a lot of the newer packages for development available without any hoops to jump through, just select and install (love the deb package system). 

Granted, I absolutely despise the default color scheme.. that baby poop brown is just awful, but I'll get that changed hopefully soon enough :)

Quote - Actually, this very forum (via the search features) would be a very good place to do some research on the matter. Also google-up Rob Wisenant's home page concerning ERC and other bits and bobs that will likely help you a lot about getting some insight into the Poser file formats. Some other folks to grep for would be Nerd3D, Dodger (and his site at xfx3d.net, I think), and a few others that will come to me once my brain gets out of first gear this morning. I don't think DAZ would have too many objections to helping you grok some of it as well.

I'll have them all bookmarked by days end :)

Quote - Is OGRE that good for non-game rendering? Heh - I'll have to get off my butt and go take a peek at it. :)

Haven't done any testing with it yet, but from the API it looks like it includes a good 80% of what I need right off the bat.  I figure worst case scenario if I have to I can always look at another library or code some add ons for OGRE if need be, but the initial run through looks very promising.

There are a few other libraries out there that I might make use of too, at least in part, still getting a game plan down now while working on the Poser file API - figure things will go a lot smoother later on down the road that way :)

It'd be cool to have a layered objects palette controlling a physics engine, so that the sim could be made to override or accomodate keyframed or captured motions.  Sometimes you want objects to interact naturally.  Other times, as an animator, you want unrealstic behaviour.  For example let's say you are staging a fight scene.  You animate/capture a figure kicking and apply a force modifier to his foot.  Now any time you call that animation it can physically affect other objects.  (It could even control like a game, with the motions applied to keypresses.)  You could walk around kicking anything in the environment and have it all react realistically.  Sometimes you wouldn't want that.  You might need the recipient of the kick to land in a certain place.  So you'd want to run the sim yet be able to tweak the outcome.  Or if you were controling a vehicle you may need to override the sim to cause a desired outcome, like tweaking a the sim so that the car crashes exactly through the glass...

Sorry, I tried to keep it figure-specific but drifted off into Bruckheimer territory.  Interesting stuff brewing here...

Maybe not fully ethical, but definitely fully legal: I used the 30 day trial version of VMWare Workstation to create a series of virtual machines, and now I use VMWare Player (free) to run them.
The pricey stuff from VMWare is mainly their ESX server line, brilliant software, but not what I need for development.
THere's only one major caveat that I found: graphics acceleration. Virtual machines running in VMWare don't benenfit from hardware accelerated graphics. No OpenGL, no DirectX. That might be a major problem.

But that is VMWare. I don't know how VirtualBox or other virtualization software handle OpenGL.

Collision detection and handling: ODE can do this. Not only using primitive, you can supply ODE with meshes too.
Of course, the more complicated the mesh, the slower the ODE calculation. Another good reason to work with SubD: ODE is certainly capable of doing quick collision detection using 3K or 4 K poly meshes, but any speed will be lost with 60 K poly meshes - just like Poser's collision detection, which I never uses since it is far too slow.

Quote - Maybe not fully ethical, but definitely fully legal: I used the 30 day trial version of VMWare Workstation to create a series of virtual machines, and now I use VMWare Player (free) to run them.
The pricey stuff from VMWare is mainly their ESX server line, brilliant software, but not what I need for development.
THere's only one major caveat that I found: graphics acceleration. Virtual machines running in VMWare don't benenfit from hardware accelerated graphics. No OpenGL, no DirectX. That might be a major problem.

But that is VMWare. I don't know how VirtualBox or other virtualization software handle OpenGL.

I don't think VirtualBox supports the 3d accelerators either, haven't done much testing but I'd be suprised if it did, most virtual machines don't.  But mostly I'll be using it for development purposes so when the time comes to make linux packages for testing I can always setup a full blown version and dual boot.

For right now though I'll be concentrating on the Windows version first, but coding in a Linux environment.  Might seem a bit strange, but there are so many great development packages for Linux and since I really want this to be cross-platform, it seemed the way to go.  I'll work on getting a compiled linux version out once I get the Windows version running the way I want.  As long as I stick to cross platform libs it shouldn't present a problem I don't think.

I've been giving some thought to collision detection, I think that's another one to add to the list of things you can schedule for either batch processing or distributed computing.

Basically what I'd like to be able to do is have a "batch processing window" where you can setup a lot of the more system intense features to run unattended on a schedule on your own pc, in background on other systems in your own network, or in background via a distributed computer network via the internet.

Other things you'll be able to batch process on my list include - renders, animations, dynamic cloth & hair, etc.

Right now I'm considering the best way to code the module/plugins interface, making the app very extensible without overburdening the GUI itself.  More thought needed there, but I'm working on it :)

Quote - It'd be cool to have a layered objects palette controlling a physics engine, so that the sim could be made to override or accomodate keyframed or captured motions.  Sometimes you want objects to interact naturally.  Other times, as an animator, you want unrealstic behaviour.  For example let's say you are staging a fight scene.  You animate/capture a figure kicking and apply a force modifier to his foot.  Now any time you call that animation it can physically affect other objects.  (It could even control like a game, with the motions applied to keypresses.)  You could walk around kicking anything in the environment and have it all react realistically.  Sometimes you wouldn't want that.  You might need the recipient of the kick to land in a certain place.  So you'd want to run the sim yet be able to tweak the outcome.  Or if you were controling a vehicle you may need to override the sim to cause a desired outcome, like tweaking a the sim so that the car crashes exactly through the glass...

Sorry, I tried to keep it figure-specific but drifted off into Bruckheimer territory.  Interesting stuff brewing here...

Lol.. well no garuantees that will make the first version, but I'll see what I can do for later releases :)

I'm giving a lot of thought to the animation interface though, since it will be one of the major features of FAST.    I'm also considering things like facial animations and even lip synching capabilities further down the road, the tough part there is going to be coming up with something that is figure independent but I have a few thoughts along these lines.

With a little luck I'd like to also be able to integrate FAST with some other projects like MakeHuman and a few others, giving people pretty much a full blown 3d suite. 

Does ODE do cloth and softbodies as well as Bullet?  Those seem like essential features for something like this.

Also, unless I missed it, why Ogre over Irrlicht?

(I don't even know enough to be biased, I'm  just wondering how that combination was picked out of the 3 or 4 that would appear equally viable...) 

Why OGRE over Irrlicht?
Hmm. A couple of years ago I did quite a bit of research, together with some colleages, into the usability of open source rendering/game engines for our game technology department. We selected OGRE because of the large and active community, the amount of samples and documentation, and the availability of sound, UI, physics and AI plugins. Irrlicht has a good reputation as well (came in second in our evaluation).

As for cloth, softbodies and ODE - I don't know. I know from personal experience thad ODE handles rigid body physics pretty well, not only primitives but also actual meshes.

Bullet - in that animation, is that really tearable cloth? Now THAT would be cool!

Quote - Bullet - in that animation, is that really tearable cloth? Now THAT would be cool!

I know.  And the rolling jelly ball and the cubes hitting the stretched lines were also impressive. 
Someday  our figures will have to worry about their dynamic pants ripping when they sit down!   

(I'd love to have, for any one of the programs I own, a tool to let me make phone lines and power lines.  With that they could even snap if the pole was knocked over!)

Quote - Has anyone seen the new cloth and soft bodies in Bullet?  I was impressed. 

http://www.youtube.com/watch?v=exss517n1I0
 

Is bullet open source by chance? 

Quote - Does ODE do cloth and softbodies as well as Bullet?  Those seem like essential features for something like this.

Also, unless I missed it, why Ogre over Irrlicht?

(I don't even know enough to be biased, I'm  just wondering how that combination was picked out of the 3 or 4 that would appear equally viable...) 

Well, as far as libraries are concerned, my initial picks may not be the ones that make the final revision, after all there are a ton of open source libraries to choose from and I am still in many ways in the  "reasearch and proposal phase" of the project.  Nothing is set in stone as of yet.

After reading through OGRE's specs,  it would appear that it is well documented, well supported and will do a great deal of what I need with minimal coding effort.  I haven't yet perused Irrlicht quite as completely as I have OGRE, however it too appears to be a good library in it's own right.  I have no deep seated preference either way really, just looking for whatever tool is going to help get the job done.  So if I mention that I'm using a hand drill and you happen to know of a power drill, by all means, give me a shout out  :)

Quote - Bullet - in that animation, is that really tearable cloth? Now THAT would be cool!

Tearable cloth?  Well, if one could predefine "tear points" to avoid the engine from activating on areas that you wanted to try to pose normally I think it might be possible, question is, how intense might the calculations turn out to be in order to get reasonably viewable results?

A very interesting premise though - have to add it to my work list and see what I can come up with :)  Naturally were looking at something here that probably won't make the alpha or even the first few revisions, but later on down the road it would be a great feature to have I think, provided one could work out all the details. 

Quote - > Quote - Bullet - in that animation, is that really tearable cloth? Now THAT would be cool!

Tearable cloth?  Well, if one could predefine "tear points" to avoid the engine from activating on areas that you wanted to try to pose normally I think it might be possible, question is, how intense might the calculations turn out to be in order to get reasonably viewable results?

A very interesting premise though - have to add it to my work list and see what I can come up with :)  Naturally were looking at something here that probably won't make the alpha or even the first few revisions, but later on down the road it would be a great feature to have I think, provided one could work out all the details. 

Tearible cloth is seen running, presumably in realtime, in the video linked to above.  I'm guessing each vertex has a stress coefficient, and the polygons seperate when the vertex reaches it.  I don't know why it couldn't be made to do it along a designated seam, don't know much about it beyond what is shown.

I think the best estimate of reasonably viewable results could be gleaned from what the games are doing now.  Bullet is blender's physics engine and runs in real time there, so I have to guess the cloth is also designed to run in real time.  It may run quicker with less polygons than we are now used to modeling.  Maybe it would oly be useful for things like scarves, flags, or maybe it could be grafted to a non cloth-sim to make coattails or sleeves.  I guess it depends on how it works best.  It may handle a lot of low poly cloth sims better than one high poly one or vice versa.

I expect to find out what it can do when/if it becomes part of blender.

Quote - Tearible cloth is seen running, presumably in realtime, in the video linked to above.  I'm guessing each vertex has a stress coefficient, and the polygons seperate when the vertex reaches it.  I don't know why it couldn't be made to do it along a designated seam, don't know much about it beyond what is shown.

I think the best estimate of reasonably viewable results could be gleaned from what the games are doing now.  Bullet is blender's physics engine and runs in real time there, so I have to guess the cloth is also designed to run in real time.  It may run quicker with less polygons than we are now used to modeling.  Maybe it would oly be useful for things like scarves, flags, or maybe it could be grafted to a non cloth-sim to make coattails or sleeves.  I guess it depends on how it works best.  It may handle a lot of low poly cloth sims better than one high poly one or vice versa.

I expect to find out what it can do when/if it becomes part of blender.

Well I think it's safe to say at least some of bullet will get incorporated into FAST, just from the reading I've done thus far it does seem to offer some pretty interesting capabilities.  The tearable cloth looks very interesting, something I'd definately like to persue, but it's going to require some thought on the implementation side.

I'm not certain I want to, as the documentation suggests, base the tearing applicaiton of the physics engine solely on the stress factor placed on the cloth by various unseen forces in the scene.  While that is certainly a good thing for a gaming engine, for the kind of still/animation production I'm considering I think it would be better to allow the user to decide if a section of cloth should be considered "tearable" or not, thus you could have a lot of various components in a scene (like gravity, forward motion, etc) that might in "real life" cause something to rip but you might not necessarily want it to tear in your animation or still.  Think of Indiana Jones, for example, that hat always seems to stay on no matter what sort of forces are applied to it from velocity, wind, gravity, etc - such are desirable characteristics in some production animation or still work.

But giving the user the ability to specify that certain areas of the cloth could be "torn" would be a great ability, so that they could, for example, specify that yes, this shoulder strap should be "tearable" but the other should not, etc - and have the engine consider that in it's calculations.  That way your not stuck trying to figure out exactly how much force to apply in which direction to get the cloth to "rip" just the way you want it.

Wing's edge hardness might work.  You'd just pick a selection of contiguous edges and set them to be hard, and upon import that would become your tear line.  The you could still have a threshold that the cloth could stretch before tearing. 

I hope you can implement collision detection that won't bog down in memory the way Poser's does.

Well, I'll see what I can do at any rate, if I can do something low stress on system resources I'll have it available as a realtime option, however if it is going to be high stress then it will be moved off into the "dynamics" area, something that can be calculated prior to render or as part of a schedule  batch if you prefer.  If it's somewhere in the middle I'll probably have both available, you can do it realtime if you have the hardware to support it, or for systems with less available resources you can do all the dynamics calculations together prior to render, or as part of a scheduled batch.

I'd like to make fast as useable as possible even on lower resource systems, and at some point I'd really like to look into a distributed computing core so that even very low resource systems can benefit from FAST.

Naturally that will probably be much later in development, a lot of groundwork to be laid first, but I think it will prove feasible in the long run.

Collision detection with the polycounts typical in Poser? It is going to be hella resource-monstrous in anything that doesn't use pure OpenGL (or DirectX) for calculating it (and even then you may still have to hunt down some external libs for it... e.g. GLIDE and such). My best advice is to build with an eye to it, but save it for later, after you (at the very least) have a solid beta.

/P

It should include at least enough collision detection so that it operates like Bryce where you can drop items on top of other items without them going through to the ground. That's actually one of my Poser Pet Peeves. Drop to Ground literally drops everything to the ground instead of Dropping it to the top of whatever is between it and the ground. Bryce does it better!

Example: Figures in a Spaceship/Building/Vehicle should be able to drop to the surface they're above even if it's two stories above ground level.

Quote - Well, I'll see what I can do at any rate, if I can do something low stress on system resources I'll have it available as a realtime option, however if it is going to be high stress then it will be moved off into the "dynamics" area, something that can be calculated prior to render or as part of a schedule  batch if you prefer.  .

For a game, realtime is at least 60fps (30 fps, locked is also used).  For a preview in a 3D graphics app, you could go as low as 10-15.  Poser's cloth never really seemed dynamic to me in that respect.  Any change and you have to run the sim again, and the sim seams to eat more memory the longer the sequence of frames, since it's expected to be able to play things back smoothly after calculating.  The bullet cloth would be dynamic in the sense of constantly calculating.  Now whether you could record it, perhaps to export as a series of morphs the way people are getting Poser cloth into Carrara, would be based on how it was written I imagine.

Does dynamic now mean canned?  I'd say simmed or pre-calculated, if you are referring to things too demanding to give realtime feedback for.  I think Poser, and many others, abuse the term.  I guess dynamic literally means it changes and is not static (or conforming in our lexicon) but I tend to think of dynamic things as being immediate and/or responsive.

Time for bed I think.

Quote - Does dynamic now mean canned?  I'd say simmed or pre-calculated, if you are referring to things too demanding to give realtime feedback for.  I think Poser, and many others, abuse the term.  I guess dynamic literally means it changes and is not static (or conforming in our lexicon) but I tend to think of dynamic things as being immediate and/or responsive.

Time for bed I think.

Lol - well, in this case the use of the term is accurate for both genre, both Poser's non-realtime features and the gaming industries real time updates, the word dynamic of course simply meaning "change".

Poser, and most other 3d apps like it, are designed to output higher quality images or video, where all the calculations for dynamics are pre-calculated and applied, then a render is done, and the final results are then viewed.  Please note the term "higher quality", particularly when applied to lower end apps like Poser, should be taken as a broad term - the technology in both areas has changed significantly several times since apps like Poser started there development cycle.

In a gaming situation, however, you're generally using meshes of lower detail to keep response speeds up and applying calculations real time in order to get an in-game effect.  Both are "dynamic" in the fact that the meshes are being changed by calculations, it's merely a question of when those calculations occur.

So in truth both are dynamic, however in the case of most 3d modeling and rendering apps the calculations are applied prior to the end result, because the end result is generally either a still image file or a movie file.  The final result is "static" either way, every time you play it or view it you will get the same result, so there is no need to sacrafice any image realism for speed.

In the case of 3d games, the dynamics have to be applied in game, because the situations are very mutable, the calculations need to be applied realtime.  In order to maintain a decent frame rate, this generally means much more attention needs to be paid to the modeling and setup because those realtime calculations do come with some additional overhead of there own.

The higher poly your meshes are, the slower your calculations - so for the most part games use much lower poly meshes to accomodate for the overhead needed for their dynamics engines.  However it should be noted that even lower poly meshes, when properly presented and used in conjunction with good texture/displacmenet maps, can still produce some pretty high quality results.

I'd like for FAST to be able to take advantage of the best of both worlds, to be able to do high poly photorealistic output as well as output optimized for gaming, or for animation for that matter. 

Quote - It should include at least enough collision detection so that it operates like Bryce where you can drop items on top of other items without them going through to the ground. That's actually one of my Poser Pet Peeves. Drop to Ground literally drops everything to the ground instead of Dropping it to the top of whatever is between it and the ground. Bryce does it better!

Example: Figures in a Spaceship/Building/Vehicle should be able to drop to the surface they're above even if it's two stories above ground level.

Agreed - I'll add it to the work list :)

Quote - Collision detection with the polycounts typical in Poser? It is going to be hella resource-monstrous in anything that doesn't use pure OpenGL (or DirectX) for calculating it (and even then you may still have to hunt down some external libs for it... e.g. GLIDE and such). My best advice is to build with an eye to it, but save it for later, after you (at the very least) have a solid beta.

/P

Noted - I'm still working on some ideas for "basic collision detection" that won't be so resource intense, one of the notions I've considered is that whenever an item is loaded into FAST's database library it precalculates "bounding boxes" to be used for this purpose, that data is then stored in the database and can be loaded later and the basic collision detection uses this data, rather than the mesh itself, to check for collisions.  Naturally this will require a bit of thought and coding, but I think it might be possible.  Since the calculations needed for the bounding boxes would have already been applied to each item, rather than trying to do it in realtime, the only thing you'd have to do realtime is to check and see if one bounding box collides with another and adjust accordingly.  Some testing would be required of course to see if this will turn out to be fast enough for real time collision detection, but I think the idea is worth investigating.

No worries - the basic math for collision is easy enough to build and incorporate (even if you're tossing around octrees), but you can spend a lot of time on it - a metric ton of time :)

/P

Quote - No worries - the basic math for collision is easy enough to build and incorporate (even if you're tossing around octrees), but you can spend a lot of time on it - a metric ton of time :)

/P

Lol - well, its one of those areas that will probably get most of its attention after the initial beta release, but one that I'm leaving room for in the file formats.

Here's a first installment on that animation wishlist.... ;) Linear keyframing Catmull-Rom Interpolation Bezier interpolation. Beta Splines Quaternion interpolation. dockable triple graph view (for XYZ curve viewing of selected item); adjustable scaling and size. Clickable curve handles on each keyframe, to manipulate tangents (see the Vue 6 Infinite dopesheet for an example). Dopesheet style keyframe panel (similar to Poser/Vue's dopesheets. Global IK on/off. 'sticky' IK (being able to pin any bone along a chain in place, make motion adjustments, then 'unstick' I see you're already talking about bounding box collision; you might want to make this a toggled function. If you can model, you can create low poly forms to attach to the body to get a more precise lay to the dynamic. But the import and generate idea for the bounding box is a good one. It would be like illumination baking. Selectable manipulators. Maybe even make this a scriptable event. Provide a Poser-ish kind of dial, a slider, on OpenGL manipulator directly on the bodypart. Maybe a combination of the first two; a dial for coarse amounts, then a slider for fine movement. That woud avoid the issues both controls have. A robust dynamic force generator. Poser's wind force is pretty much a thick molasses fluid. Being able to introduce turbulence and vector changes without a tremendous amount animation of the generator object would be very nice. As well as being able to set actual numeric values when certain effects are in place (activate the pulse effect, and you get a window to enter pulse duration, for example. Other numerical values could be % of turbulence, an upper and lower velocity for a wind effect, etc). A 'vanishing room' feature. There would be an animation 'room' that would never render out, and all props & primitives that are grouped with that 'room' also never render. That would allow you to construct a stage that you can render a character in, then render the character and wind up with stills and alpha masks for compositing in another program. The old Poser boning system and a more modern weightmapping one; if they can work together, it would up the odds of legacy content being upgraded at some time or other. A dynamic cloth engine that is capable of easily being used in 'hybrid' style clothing. Multithreading and distributed calculation of both hair and cloth. The mulitcore crowd would benefit, and those of us with renderfarms likewise.

Quote - > Quote - It should include at least enough collision detection so that it operates like Bryce where you can drop items on top of other items without them going through to the ground. That's actually one of my Poser Pet Peeves. Drop to Ground literally drops everything to the ground instead of Dropping it to the top of whatever is between it and the ground. Bryce does it better!

Example: Figures in a Spaceship/Building/Vehicle should be able to drop to the surface they're above even if it's two stories above ground level.

Agreed - I'll add it to the work list :)

Maybe you could implement a type of "group space"?  Just as figures parented to a vehicle can move with it, the vehicle could have a ground property that could be positioned (via an axis) and would move with it.  Then instead of a figure just being a child of the global space, it would be a child of the local space of that vehicle.  Other properties could be inclusive or exclusive to that local space.  For example if there were wind in the scene, it wouldn't blow the hair of the figures in the vehicle unless wind were turned on for the vehicle space.  Perhaps lights could even be confined to this space so that in a room or vehicle they wouldn't affect lighting outside of them, but I'm not sure how lights work in Ogre.

Just tossing out ideas. 

The more I think about, the more the hybrid clothing seems necessary for this type of thing.  I think even transmapped hair is the way to go, if it can be made to fall like cloth without detaching form the scalp or falling through itself to badly. 

I also think that collision using collison primitives is probably ideal, but not always.

The jiggles plug in for Carrara seems like a way to extend the life of Poser's rigging.  It uses a map to control how much a body part can be affected by a force (gravity in its case).  Poser figures would benefit from softbodies based solely on the frequency with which their body parts self intersect.  I think if I were modeling for realtime using normal maps and maybe even parallax shaders I'd eventually get models that would render as good as "content" figures without the footprint.  

Something like this would be nice, too:

http://www.youtube.com/watch?v=3vrlJFOCbsM

Quote - Personally I think SM has about 18 months to produce the next version of Poser and they better include a lot of new features (like a completely 64 bit version...

I do believe that they have a version already that is 64 bit. Also , we must remember that Poser 4 was out for many years before Poser 5 came along and it was still extremely popular (meaning P4) when Poser 6 came along ;o)

Quote - > Quote - Personally I think SM has about 18 months to produce the next version of Poser and they better include a lot of new features (like a completely 64 bit version...

I do believe that they have a version already that is 64 bit. Also , we must remember that Poser 4 was out for many years before Poser 5 came along and it was still extremely popular (meaning P4) when Poser 6 came along ;o)

Ok it isn't completely 64 bit I guess, but these are Poser Pro's key features taken from Smith Micro's web site:
Key Features:

• 64-bit Render Engine
  Poser Pro users will benefit from the network rendering and render queue capabilities, including background rendering, built on a 64-Bit render engine for incredible speed and quality!
• HDRI Export
  Poser Pro creates even more realistic images with High Dynamic Range Image (HDRI) support for Image-Based-Lighting and textures.
• Normal Map Support
  Poser Pro allows you to add high resolution 3D detail to any mesh through the use of normal mapping, producing better images, even with low to medium poly models.
• Hosting with PoserFusion™
  Realize the added benefit of using Poser Pro's pre-rigged characters inside of host applications such as Autodesk's 3ds Max and Maya®, and Maxon's CINEMA 4D®.
• Network Rendering
  Get the most out of your hardware and leverage your network to render massive scenes using the network render queue.
• Professional Content
  Create lifelike animations by combining multiple strands of action into one fluid animation using layers. Keyframes automate between poses.

With the amount of people still using Poser 4 and 5 even today, Poser won't die even if they stop making it. I would imagine the most likely replacement would be D|S since that's what they've been working on for a while now, but Poser will be there for a while.

Quote - With the amount of people still using Poser 4 and 5 even today, Poser won't die even if they stop making it. I would imagine the most likely replacement would be D|S since that's what they've been working on for a while now, but Poser will be there for a while.

No, I think we can expect Poser use to continue long into the future, however it isn't really how many people that are using poser 2, 3 or even 5 years from now that concerns me, it's the course of Poser's development.

What was a moderately priced entry level program is still an entry level program, but sadly it is no longer moderately priced.  That, and sadly at least, many areas of Poser have remained virutally undeveloped for far too long, which is why I started development on FAST in the first place.

Quote - I do believe that they have a version already that is 64 bit. Also , we must remember that Poser 4 was out for many years before Poser 5 came along and it was still extremely popular (meaning P4) when Poser 6 came along ;o)

I think someone else already mentioned that Poser is still a 32 bit application, only firefly (the rendering engine) has been updated to 64 bit.  Also, Poser did at that time fill a market niche that no other program really filled.

SM has abandoned that niche in favor of new and uncharted waters.  But hey, if folks are still using Poser years from now that's ok by  me, I've just realized that I'm rapidly outgrowing the program itself, and that Poser's development is not at all keeping pace with available technology in many key areas.

Hence what I feel is the need for an open source replacement.  But if you prefer to stick with Poser that's ok by me, I'm not making any money off this project one way or the other :)

As some have pointed out I think people use Poser mostly because of content rather than for the program itself. I myself never do any render in Poser, I use it for content and to do the posing, then export everything to my program of choice, Vue. I suspect many people do that with all kind of other 3D programs. I'm not sure exactly what your aim is with FAST, but it needs to be clear. Are you hoping to replace poser as a content and posing program, if so will it support all the legacy content? Will it use its own new content type? Are you working on building a full featured rendering engine for it, and if so will it support all the bells and whistles like Global Illumination, Radiosity, etc? Personally I predict that if Poser does go away, the big benefactors will be the other 3D programs as people move on to those, and most people will still use Poser or move to D|S simply for the content / posing elements, but I wish you luck as there is room for a brand new, high performance and fully featured 3D posing and animation software.

"I've just realized that I'm rapidly outgrowing the program itself, and that Poser's development is not at all keeping pace with available technology in many key areas."

That seems to be the common point. I have always considered the last couple of versions, nothing more than point upgrades. That is why I have invested most of my time and money with higher end software. I still use poser for rigging and the walk designer and quick storyboards but it is getting less use as the tech of everything else is advancing.