PDA

View Full Version : Biggest problem with SOFT BODY DYNAMICS???


Mike Pauza
06-16-2003, 05:09 PM
Hi guys!

I was wondering what beefs people are having with current implementations of soft body dynamics?

I just started working on some new methods of doing this stuff, and I wanted to get a lot of opinions on "what the biggest problems are".

Thanks for any and all feedback. -Mike :)

policarpo
06-16-2003, 05:13 PM
i find the setup process a little taxing and a little convoluted. sure, it makes sense once you've done it a few times, but it really lacks the faculty of play and discovery.

wouldn't it be cool to have a few default setups which you could run through in real time, and tweak variables, and have it update in realtime, a sort of viper for soft body dynamics...and when you are happy with your tweaks, you save these out as presets to build off of later?

you know...make it like a kid poking a slug with a stick, or squeezing playdoh in your hands...or running a finger on stretched out lycra on the shirt rack at the local BR. i'd like a system built around a natural model of Soft Body dynamics...something closer to the model of physical interaction.

i'm not sure if this is the type of feedback you want. :)

E_Moelzer
06-16-2003, 05:27 PM
Hello
I think it should be more interactive and better integrated.
The whole "add this deformation- plugin to make it work with that"-stuff is not that great either.
It would be great to have a (maybe not so precise) realtime- preview, so one could twaek settings interactively (on a certain frame) without having to rerun the entire simulation over and over again. It should support weightmaps (i.e for defining stiffness, or to fix some parts) and it should work with Subpatches.
And please, please give it an interface that is understandable, as well as some more presets than MD has.
It should also be able to recoginze the current way polygons are arranged if selfcollision is on (you can get into trouble with MD trying to rearrange inersecting parts). Oh and I want to be able to define a few objects as collision- objecs etc.
Keep us updated, I am very interested in your project.
CU
Elmar

adrencg
06-16-2003, 05:38 PM
Originally posted by Mike Pauza
Hi guys!

I was wondering what beefs people are having with current implementations of soft body dynamics?

I just started working on some new methods of doing this stuff, and I wanted to get a lot of opinions on "what the biggest problems are".

Thanks for any and all feedback. -Mike :)

Oh my god, where do I start?

Let's talk about Motion Designer for a sec....

I have gotten to a point where I can actually get some results out of it, but I still think its an abomination of interface design. Sliders and values should not be 1 to 3 for one value, then 1 to 100 for another value, then 1 to -eeee-1to100000000squared.

It makes no sense and its so unbelieveable to me that someone smart enough to design something as powerful as Motion designer can't make it somewhat intuitive to use.

There are way too many ways to screw up your simulation. How are we supposed to know that compress stress has to be set to 20000 to make the object not twist into a mangled wad of polys?

All setting should make smooth calculation. No setting or combination of settings should make the simulation go haywire. What I'm saying is maybe make it less tempermental than Motion Designer. In fact look at Motion Designer as an example of what NOT to do.

Ideally, dynamics would be another tab on the object panel. Click a button to make it a soft body. Roll down some presets for different properties. Pick collision objects from a list.

Don't give us too many options, the way MD does. Keep it simple. We're not all rocket scientist out here. Me stupid artist. Me make pretty pictures. Me not understand what parallel resistance and compress stress is.

I'm not yelling at you, I hope you create something that makes Newtek wonder what they were thinking when they passed off MD as a usable dynamics engine. Good luck.

Mike

policarpo
06-16-2003, 05:42 PM
I also think the selection process should be a point and click affair. You select this object as a hard object, this one as a soft object....and now when you move them to the point of contact, they react accordingly.

It would also be nice to have a Slider mechanism attached to this so you could tweak influences and such.

I think the approach of embedding a simulation engine within the creation aspect of Soft Bodies is really important. Fast previews will be a great thing to have, even if they are only slightly accurate...

I think having a 2 mode creation process for Soft Body simulations would be a bonus as well...a simplified version if you just need generic/canned effects (the slider based concept), and an intermediate version where you could plug in variables and really tweak the system to reflect accurate simulations (this could be a toggle in the main interface that you reveal for when you want to get in there and tweak till the coffee wears off).

Also having the ability to localize the effects on parts of an object would be really cool too. I guess this is where weight maps come into play.

proton
06-16-2003, 05:57 PM
You guys should go check out Motion Drive .....it's a newer version of Motion Designer and it rocks!


http://www.dstorm.co.jp/FXMnD/e/

CIM
06-16-2003, 06:10 PM
Originally posted by proton
You guys should go check out Motion Drive .....it's a newer version of Motion Designer and it rocks!


http://www.dstorm.co.jp/FXMnD/e/

We can propably expect that and the other new DStorm plugins to be thrown into LW, like usual. :surprised :hmm:

policarpo
06-16-2003, 06:24 PM
Originally posted by CIM
We can propably expect that and the other new DStorm plugins to be thrown into LW, like usual. :surprised :hmm:

what does that comment have to do with with what Mike is asking for?

Please stay on topic if you are on this thread.

thanks.

Mike Pauza
06-16-2003, 06:44 PM
Hi Will:

Thanks for the link. I'll take a peek at thier new stuff. BTW, you still owe me a couple of shirts dude. :)



policarpo, E_Moelzer, adrencg:

What I hear you guys saying is that you want something that's stable, easy to set up, and fast. That's pretty much what I was thinking. I have a few (still very basic) demos for windows if anyone's interested in taking a peek...email me at sharonpauza@aol.com (my wife's email) if you want them.

-Mike

HowardM
06-16-2003, 06:53 PM
Hey Mike-
I know your pain...but once you play with MD enough, you start to kind of get it! :)
check this out if you havent (http://www.cgtalk.com/showthread.php?s=&threadid=69032)
...its pretty fast to calculate, but yeah, still no real clue what each variable does exactly....

nostromo_va
06-16-2003, 06:54 PM
Proton,

I'd like to try out Motion Drive, but I'm leery of anything that says it will disable anoter peice and then not be able to save. I can't afford to lose functionality in that area right now.

Can you give a short description of how it is better over the "old" motion interface?

Thanks!

NanoGator
06-16-2003, 07:05 PM
Originally posted by CIM
We can propably expect that and the other new DStorm plugins to be thrown into LW, like usual. :surprised :hmm:

We can probably expect the use of the word 'rewrite' soon, like usual. :surprised :hmm:

anieves
06-16-2003, 07:35 PM
I just spent a whole weekend "trying out" settings in MD, it wasn't fun. You have an idea on what might happen when changing settings but then you run the sim and realize it wasn't what you thought you were going to get. MD takes too long to set up and "experiment" with to get something decent out of it making it not a good choice for production. Unles you are doing skirts and balls dropping on a piece of cloth;)

policarpo
06-16-2003, 07:39 PM
Hey guys...let's be sure to offer suggestions to Mike about what we would like to see instead of discussing current issues or discussing unrelated topics.

We all know how things are...let's talk about how they should be...:thumbsup:

I think more presets are needed so we can build new simulations off of existing Soft Body dynamics.

cgman27
06-16-2003, 07:55 PM
Definately a preset shelf for self made settings.

BUT I disagree with you guys wanting to add this option (soft body) to the object tab.

Reason being, I like having it as a surface. It goes back to the heart of OOP, the old IS and HAS. An object can have attributes of a softbody, and can also be a softbody, but when you encounter dycotimies in OO design you usually stick them into the HAS category, since you could use the HAS attributes to cover the entire object. Once you go IS there is no mixing.

IOW, making all objects with the softbody check box on, makes them just that, and there would be no room to say make a trampouline easily in one layer. From what I have done in the SDK you would lose the ability to PIN the softbody stuff at edges. Like a flag attached to a pole.

Then again, maybe the new SDK will allow for newer ways/access, wish I had that info.

:shrug:

Mike Pauza
06-16-2003, 08:14 PM
Let me clarify guys:

I talked to Andrew Cross of NewTek a while back and "MAY" be helping them out on the physics/theoretical part of some new dynamics code. If not them, then I'll be trying to get it incorporated via a plug-in somehow. But I will hopefully get some new and exciting soft body dynamics stuff developed for wavers in one form or another.

Many users (like HowardM) have developed some cool stuff using MD despite it's flaw's, but everybody struggles with MD because it's very bad piece of code. Dynamics code needs to be stable, predictable, and easy to set up. Hopefully, I've come up with a workable plan to do that. Again, I have some basic PC demos now if anyone wants to comment on them...email me at sharonpauza@aol.com. I will hopefully have a killer demo ready in a couple of months.

Keep the ideas comming. They're good for everyone. :)

-Mike

NanoGator
06-16-2003, 08:16 PM
My apologies to both Policarpo and Mike. Just sick of hearing complaints even tho we're well aware of them.

I've experimented with the soft body dynamics a bit. Sometimes I get really good results, others it feels like it's not working at all. Part of the problem is the UI, which is a bit intermittent sometimes.

I've played with it enough to know, though, that some startlingly cool stuff can be done with it. It's just a matter of understanding what each of the settings for it do. Remember when the Enterprise crashed into the Scimitar in Star Trek Nemsis? I think a similar 'shredding metal' effect can be done with it.

yog
06-16-2003, 08:32 PM
I personally think that the settings should be simpler and less of them.
There seem to be too many settings in Motion Designer that adversly effect other settings, you get one right, alter another setting and the whole effects starts going away from what you originally wanted.
I know Howard and others have been able to get some very creative effects simulating some non standard mediums with some thinking outside the box, but I would say that most users just want to simulate some cloth / fabric.
Perhaps just having Coarse/Smooth and Heavy/Light sliders might be over simplistic, but they could be a good starting point.

I agree with others that the application of the effect via weight maps would be a major step forward.

Perhaps things would simplified greatly if there was a Softbodies simulator with very simple/few controlls aimed at cloth simulation and a more in depth version with all the bells and whistles for the other effects like gel / liquid that people like Howard excel at.

DarkLight
06-16-2003, 09:06 PM
Have you seen Syflex (http://www.syflex.biz/) ?

Before anyone points out that it is a maya plugin, i do realise that :)

This produces some very nice results. Does anyone have any experience of using it?

HowardM
06-16-2003, 09:12 PM
yes, like everyone has said...simplify the interface and were 99% there....is it possible to keep the existing code and just redesign the interface, remove reduntant settings...make them easier to understand? I really think that would help out alot.

I havent played with XSI or Maya or any other simulations, so I cant fully judge how good MD is, but MD works fine WHEN it works...
maybe it doesnt, someone have enough MD and other package experience to tell us?

the biggest problem is the fact that you tweak one variable and everything is fine, and you tweak another slightly and youve got polygon freakout! ...fix that, by simplifying redundant variables, and I think MD could be alot better!
:)

Zithen
06-16-2003, 09:31 PM
I think messiah:animate's soft body features are worthwhile, even though it's not complete yet.

But it is very interactive and fairly easy to set up.

Here are some features that I'd like to see.
--Separate controls/parameters for all types of springs (sheer, structrual and flex).
--Some kind of smoothing feature that would do a gradiation of the spring parameters from one surface to another.
--The ability to use bones with soft bodies. messiah:animate has something called "Hold springs" which are basically springs that attach the softbody point to the predeformed softbody point. That way you can use bones and other deform tools and the softbody object will be effected by them.
--All values should be animatable.
--It would be great if you could have some soft-IK features, like in C4d. This is where you have dynamics at the joints of hierarchial characters. For example, you could have a chain of bones, move the base bone and have the whole chain wiggle. A value that could weight these dynamics with the keyframed motion would also be essential.
--Of course, stability and speed makes the thing all the more better.

Maxx
06-16-2003, 09:36 PM
Personally, I'd like to see the soft bodies be able to settle on a collision surface. As it is now, if you drop a piece of cloth onto a table, for instance - something I'm called on to do with surprising regularity - if MD decides not to freak out and throw a crumple of fabric into the stratosphere in two frames, the fabric jiggles and shimmies when on the table. I believe that I heard an explanation once that MD does not discontinue calculations when the body has come to rest. If this has been solved, then ignore this post - I got fed up with MD and its' mystery settings quite some time ago and haven't played with it in a while.

Mike Pauza
06-16-2003, 09:38 PM
The whole interface problem stems from the fact that a models geometry rarely has any internal "structure". Simming such an object is like building a skyscraper without and any I-Beams...then attempting to hold it all up with glue & duct tape. :)

Syflex has some nice examples..looks like they're using angular springs for bending...a very slick approach. :)



Zithen & Maxx...I'll respond later...cool ideas!

whattawa
06-16-2003, 10:26 PM
I personally don't want less options in MD. I just want it better organized. Whoever programmed it put all those options in there because they thought they were useful. I have found some use to a lot of them, but even with a 2GHz processor I can't see results to my changes fast enough unless I use really low poly models. Maybe instead of getting rid of a lot of options, put them under an "Advanced" tab or just organize them and name them in a way that we all can understand.

More than that, though, is the fact that with a lot of options you need to be able to see results to your changes right away. As others have mentioned, a Viper-type thing would be incredibly helpful for MD. When playing around with settings, the quicker you see the results the more enjoyable the experimentation process will be.

m_luscombe
06-16-2003, 10:47 PM
I would like to see the separate MD panel done away with.

Soft-body (and future hard-body) settings should just be another tab in the object properties panel. You should be able to save an objects MD properties straight from the object panel and load them into another object.

And, similar to the "radiosity: on/off" flag, there should be a "simulation: on/off" flag when animating.

I was astounded when I saw that the deformation was in real-time in Cinema4D. Even when pulling objects around with your mouse. I don't think that there should be a viper-like anything for MD: I think it should be real-time. Maybe LW doesn't come close to Maya, but it should come close to Cinema.

I'm with CIM on this, MD feels like a separate program.

Motion Drive looks like, well, like nothing. Who in their right mind would install a plugin that disables your particles and prevents you from saving? Sorry D-Storm. Maybe it rocks, but I can't even see the user-manual online (page not found).

Celshader
06-16-2003, 10:57 PM
Originally posted by Maxx
Personally, I'd like to see the soft bodies be able to settle on a collision surface. As it is now, if you drop a piece of cloth onto a table, for instance - something I'm called on to do with surprising regularity - if MD decides not to freak out and throw a crumple of fabric into the stratosphere in two frames, the fabric jiggles and shimmies when on the table. I believe that I heard an explanation once that MD does not discontinue calculations when the body has come to rest. If this has been solved, then ignore this post - I got fed up with MD and its' mystery settings quite some time ago and haven't played with it in a while.

Fixes for this problem:


Increase the Calculate Resolution to 100 in the Options panel. This usually does it for me.
Try increasing the Viscosity for the target object, to absorb vibrations.
Try reducing the Bound force of the collision object to 0, so that the target's points do not bounce off of the collision surface at all.


I like Motion Designer. My biggest complaint is the documentation -- I had to use the software for a while to figure out most of the settings.

That said, MD can do some cool stuff:
http://www.celshader.com/gallery/md/

Celshader
06-16-2003, 11:02 PM
Originally posted by Mike Pauza
The whole interface problem stems from the fact that a models geometry rarely has any internal "structure".

One of my "tricks" is to add rigid polygons inside an object, run MD on that object, delete the rigid polygons for that object and save it under a different filename, and play back the calculated MDD on the object without the rigid polygons. As long as the point order remains the same, MD won't give you any grief.

That's how I kept the volume on these cables (http://www.celshader.com/gallery/md/3cabletest01a.mov). If I had run the MDD calculation on the playback object, which did not have the extra rigid polygons, these cables would have collapsed like windsocks.

Facial Deluxe
06-16-2003, 11:16 PM
Originally posted by proton
You guys should go check out Motion Drive .....it's a newer version of Motion Designer and it rocks!


http://www.dstorm.co.jp/FXMnD/e/
Did you try it ?
The lack of infos scares me, before installing it. Couldn't NT do something about this, make it more official ?

Mike Pauza
06-17-2003, 12:00 AM
Zithen:

Sounds like you want any new soft body dynamics to work alongside character rigs...that could be really sweet.



whattawa:

Well, some users would want to simply select the material type and it simply work (try that with MD), but yeah having the ability to contorl all the parameters that exist in the code are a must.



Maxx:

Yeah, damping control is a must.



m_luscombe:

Yeah, realtime is a must.



Celshader:

Hi Jennifer. I've seen some of your MD stuff and it's amazing you figured out how to use it as well as you have...but I'd like to see what you could do with some real tools. :) BTW, your method of simming using a simplified object is a great idea. I'm hoping to do something somewhat similiar.



Facial:

Hey Oliver! The new Motion Designer...are you kidding??? Hope you are well.

E_Moelzer
06-17-2003, 01:19 AM
A few more suggestions on my side:
I really like the way particle fX work in this regard.
It seems much simpler.
If NT hires you to do the SBDs make sure you do a whole dynamics- sytem (also hardbodies, which should IMHO be even easier) and put the settings into surface- editor. I think that surf- ed would be a great and very logical place to put material- settings like these. What do you others think?
Also make sure you take a good look at how realtime- game- engines handle this nowadays. I think that it could be a simillar, but more precise aproach.
CU
Elmar

HowardM
06-17-2003, 01:26 AM
"Also make sure you take a good look at how realtime- game- engines handle this nowadays. I think that it could be a simillar, but more precise aproach."

yep, I think NTs programmers need to learn from game programmers....alot!
I know LW cant do everything realtime, games are specifically made to just do what they need to, thats why they can do things realtime, but eventually dont we all see this as the evolution for even LW? total hardware render system off of a graphics card? no software!
:)
really , maybe there is some genius out there that will program a modular system that utilizes JUST what it needs to at that moment in realtime...and doesnt 'load' the rest of the bells and whistles into memory to hog it up...so when i use pfx or MD, the whole engine is taken over and MD is realtime...then move on to lighting... realtime, like g2 with shadows, everything 99% rendered...etc...
That way you could still have a robust program that can do it all, but only specifically at the time you need it...

make sense?

well, im no progammer, but i can dream...
:)

Mike Pauza
06-17-2003, 03:26 AM
Elmar & Howard:

I know "a little" 3D programming, but I'm basically just a "physics simulation guy". Hopefully I can help them out where they need it.

NewTek is very aware that collision detection (like in games) is extremely important...that's where 90% of the computational overhead is. Games do collision dection very efficiently and hopefully NT can learn from this. Game engines typically have terrible collision response though...hopefully I can help in that area too.

Putting some sim material settings in the surface editor I think is a great idea.

"Realtime" 3D cards are really comming along....simulations might eventually be running on them instead of the cpu.




I'm going to be coding again tonight...hopefully I can make my demos a little bit interactive. :)

pelos
06-17-2003, 08:31 AM
one problem is the fac you need to work with points insted polygons, so you need many point, more calculation time.

one trick is to triply every soft body and no use of subdivsurface, the problem with this is that the object can be broken or have diferent reaccion between to near point, (one jump more than the other, and because is not subdivsurface, you see how gets weird!!!)

i would like that the calculation be with poly (0soft body) vs (poly but) thinking in subdivsurface,


another thing, is that you cant select many colicion objects, if you need a skirt to toch the floor because the girl seats, or something she drop,
you can create a plane use a bone with weightmap, and atach it to the main bone, so when she goes down, you can move the bone with the plane, and act like the floor is being a colicion, is faster if you only add another collicion object.


i make sense?

Arte
06-17-2003, 09:31 AM
Originally posted by Mike Pauza
Let me clarify guys:

I talked to Andrew Cross of NewTek a while back and "MAY" be helping them out on the physics/theoretical part of some new dynamics code.

Keep the ideas comming. They're good for everyone. :)

-Mike

This is fantastic news and solid proof that Nt does have a development program in action.

Mike there are a number of aspects that can be improved and methods that can be used. Can you be a little more specific on what you would need as input as I will gladly help out where I can.

Good luck.

X

anieves
06-17-2003, 03:21 PM
Originally posted by policarpo
Hey guys...let's be sure to offer suggestions to Mike about what we would like to see instead of discussing current issues or discussing unrelated topics.

We all know how things are...let's talk about how they should be...:thumbsup:

I think more presets are needed so we can build new simulations off of existing Soft Body dynamics.

Well, the original question leads me to think he wants to know what I find most problematic with SBD in LW, the only way I can contribute is based on personal experience:shrug:

Anyways would a preset shelf really work? If SBD in MD are based on real elastic body models then the presets wouldn't work as expected on every case and you would end up with the same presets you already have in MD. right?

Does anybody here use the Hide button? just curious.

I'm curious about FX Motion Drive but I really don't want to replace any components in the middle of projects... I would like to see a page with examples but aparently is coming soon.

I'll email Mike to check out the demo:thumbsup:

Mike Pauza
06-18-2003, 05:22 AM
pelos:

Yes. Simulating using a SubPatch value of 0 (or simulating using bones :) ), and displaying the resulting mesh at a high SubPatch value would work really well.



anieves:

Yes presets are a must IMO, assuming they work like they should.



Arte:

I guess what I want is to hear is how people think NT's MD stacks up to the competition, and what they think a similar technology could become.



The new demo is slower comming than I had hoped. I'm trying to speed up the demo a ton by doing it in 3D, but I'm having some annoying problems. Hopefully I'll have a much faster, better looking, and interactive version soon. :)

Arte
06-18-2003, 02:33 PM
Originally posted by Mike Pauza

Arte:

I guess what I want is to hear is how people think NT's MD stacks up to the competition, and what they think a similar technology could become.



Hi Mike. Arte is my place of work:) It's kind of nice to look at something like this. This is what I used to do for a living. I.e take a look at broken/old technology and find ways to replace it for good. Was fun until I got ordered to back off by the doctor from the stress:) This entire post is fairly generic as I don't do freebies but I can give some pointers:)

What would you say if I said I see displacment, surfacing and soft/hard bodies becoming one thing? Actually it is a lot more unified than that but that's all you asked about:) Edges, and other effects become instantly realistic, as well as multiple undo's...

It is not only possible I worked out how to do it in about 45 minutes.

It is reliant on NT's project manager (Is that Andrew C) being willing to throw away the horseshit plugin and communication interface built into LW though.

Sound interesting?

X

fastfinger
06-18-2003, 03:08 PM
Motion Designer itself works 100% ok for me.
And it`s final quiality`s A+ or A0.
But the main problem is that the particles can`t deform the clothes. I cant make rain deform clothes. There`s only one way to go within LW. MD....press start...FX Start....

My favorite default settings to start with is...
Spring 5000(How stiff the cloth is)
Subsurface 5000(How stretchy it is-the velocity of stretching)
Stretch limit(the LIMIT for the stretchness 30%)
the resistance and viscosity`s easy to setup

Dont forget to subdivide the mesh a lot of times.
This is really important.

Joviex
06-18-2003, 06:26 PM
Mike,

You check PM's on here? I sent ya one the other day.

pixelmonk
06-18-2003, 09:06 PM
Originally posted by policarpo
what does that comment have to do with with what Mike is asking for?

Please stay on topic if you are on this thread.

thanks.

Meaning that Motion Drive may be the next version of softbody dynamics in LW8. Who knows what will happen.

I'm glad you decided what you felt was on or off topic. CIM was on topic so he should continue. Carry on.

:buttrock:

DarkLight
06-18-2003, 09:08 PM
I think what causes a lot of confusion with MD is the values that you have to use to get good results.

The example given by fastfinger:

Spring 5000(How stiff the cloth is)
Subsurface 5000(How stretchy it is-the velocity of stretching)


What do these values actually mean? Using percentages may be a better idea, but allowing the user to enter more than 100%. This would also bring it more in line with how most of the other systems in Lightwave work.

DigiLusionist
06-18-2003, 10:15 PM
Two years ago, I posted something to this effect:

Have a collision system based on the direction of a polygon's surface normal. As the polygon normal collides with the surface normal of another polygon, the polygons' points orient appropriately, and deform more accurately.

Is this too computationally-intensive to implement nowadays, compared to a points-focused physics program? Or is this already being done?

If the computation was based on poly orientation, we could surface our polys in the Surface Editor, and from there jump into the Object Properties Panel to select qualitative descriptor settings, such as, "bouncy," or "squishy," or "frozen," or pillowy." I'm a verbal kind of thinker, so these would be nice for me.

Though, something more "materials" oriented may work better for a 3D program: such as "Rubber," or Metal - Aluminum," or "Flesh."

Joviex
06-18-2003, 11:31 PM
Originally posted by DigiLusionist
Two years ago, I posted something to this effect:

Have a collision system based on the direction of a polygon's surface normal. As the polygon normal collides with the surface normal of another polygon, the polygons' points orient appropriately, and deform more accurately.



Computationally that would be very fast, however, it would have huge errors in a lot of cases.

There are tons of metrics one can imploy to trade off calc time/accuracy. I would really like LW's system , whatever, whenever it may come about, to offer the kind of flexibilty that Maya has in collision solutions.

Something along the lines of a slider for faster or more accurate solving, and the ability to change the potential solver system (Runge-Kutta, Improved Euler, etc...)


the Object Properties Panel to select qualitative descriptor settings, such as, "bouncy," or "squishy," or "frozen," or pillowy." I'm a verbal kind of thinker, so these would be nice for me.

Though, something more "materials" oriented may work better for a 3D program: such as "Rubber," or Metal - Aluminum," or "Flesh."

I definately think the new system should include a more languafied way of selecting materials and/or properties.

Spring, Stretch, etc... should mean just that. Currently MD uses these terms in a basterdized way and I think this causes the most amount of workflow issues with people just getting into using it.

E_Moelzer
06-19-2003, 12:10 AM
I would use an OBB- tree- based system starting from the entire object and going down to edges and points.
Edges are a must IMHO. Points can pass through, but edges could not.
CU
Elmar

Mike Pauza
06-19-2003, 12:12 AM
Elmar:

What do you mean?




amorano:

I hear what your saying as far as algorithm go, but a special form of the "verlet" algorithm is probably a better bet since it tend to "start to converge" very quickly (i.e. inherently stable). I agree about settings being a nightmare. BTW...I checked my PM's this morning and emailed you. :)



DigiLusionist:

I'm not familiar with efficient collision detection schemes, so I can't really tell you if that would help speed things up. Sorry. I do know that in games, collision detection is the real bottleneck and they use all sorts of trick to squeeze out as much performance as they can...like testing interobject penetration using bounding cubes first before they do the intensive tests, test for collisionds using geometry simplifications, and sometimes (like with particles - particle collisions) they even presort objects based on thier location to eliminate the need for some interpenetration checks altogether. I don't know how much people have used normal vectors or how usefull they are. There are some documented algorithms that seem to work well.

The key to making good use of dynamics though is to make sure collision response is as accurate as possible...in that area I have some interesting ideas, and using poly normals is very important!!!




DarkLight:

What if a user could select the material (rubber, steel, wood, etc) they want to simulate, and either use the default values for that material, or use the default values as a starting point? What about being able to control inital parameters using a slider "between two different materials"? That could give you a quick & easy way to get the behavior you want. How about the ability to create your own materials presets?

Now in MD, a preset might work OK for one model but not others...when I say "materials", I mean parameters (and code) that are smart enough to adapt themselves to the current model so it works correctly...so "hiding" the parameters from the users unless they want them is maybe a good idea.

What do you guys think?




pixelmonk:

Motion Drive may very well rock as Proton said, but I would be suprised. Who knows what will happen?




fastfinger:

Lots of people seem to want better cloth sim (and hair sim). Hopefully that will happen. More on that later.




x:

Sounds very interesting. I'm guessing the new crop of dynamics will have to be figured out pretty well before people want a more unified system though. :)




DEMO - VERSION 2

The new demo is comming along...hopefully it will be available in a few days. This one is interactive, much faster, and in 3D!

-Mike

DarkLight
06-19-2003, 12:37 AM
Mike,

I think sliders between "preset" materials would be ok, as with hiding a lot of the values from the users to simplify the interface. I just think that when you create these materials you need some kind of guideline for what the values should be. Try to remove the guesswork of "lets try 3000 for this value and see if it works" type of thinking.

The way game engines tend to do collision detection is not really applicable to a collision simulation. Games engines usually cheat using tricks and approximations to get the results they need. They trade accuracy with speed and they only need to provide the illusion of proper collisions. But saying that, some of the techniques they use are great and can be easily used as guides for developing more accurate systems.

p.s. Looking forward to seeing the next demo :bounce:

Cman
06-19-2003, 01:17 AM
Yeah, but a game type fast approximation might be good in some instances - if only for previz if nothing else. The main thing being to make it real-time.
An accuracy slider...
What if it worked like LOD, so the further from camera the less accurate and faster collisions calculate?

If he could get some standard for materials reaction using say, a 1 meter cube object, then he could adapt those numbers as the bounding box get's larger or smaller - so presets will actually be usable between a 1-meter and 4-meter character.

Just a thought/idea.

DigiLusionist
06-19-2003, 01:55 AM
I think the physics tool should definitely make use of weight mapping. That way, we can weight specific points on an object and based on this, the dynamics package would apply physics to it in a way we would expect.

DigiLusionist
06-19-2003, 01:57 AM
Oh, and by weight, I mean that a point with 10% weighting would jiggle or be pliable, compared to a point with 100% weighting, which would be rigid and solid.

Something like that... A way of painting on the material (metal, stone, flesh, etc) on an object.

HowardM
06-19-2003, 02:35 AM
:):buttrock:
hehe really, im no physics progammer like you guys, just an artist....but (and I have no clue how smart you really are guys so please dont take this wrong) why cant NT just hire some Wiz that they find at Siggraph and pay him to do it right?...or is that you Mike?
:)

Isnt LWs development really about how much money they are putting into it?

anyway, you all hit it on the head:

1. Sliders, no more entering #s with my left hand just so I can click the next one with my mouse, why no up and down arrow action!? ...ungh
2. Realistic presets that actually work with any object!
3. Realtime feedback, with sliders for quality/accuracy to speed up tests!

...doesnt all this require a total rewrite of MD? and if so, is it that hard, and why hasnt it happened for the past few years?
oh yeah, can we PLEASE see PFX and MD seamlessly merged!?

...while were at it, make EVERYTHING in LW seamlessly integrated...even if someone makes a plugin?!
I mean honestly...the fact that I CANNOT enlarge the MD window to see all variables at once, and have to repeatedly scroll for no reason, reminds me of the good old Amiga days....garageware!
:annoyed: ...and MD2000 isnt even a 3rd party plugin anymore!

again, I guess its all about the benjamins!
:hmm:

oh well at least it seems like someone is finally listening to us about all this, so thanks Mike and whoever else is listening! :)

sorry for the long rant, but its needed after hours of PFX and MD use! :)

Joviex
06-19-2003, 03:35 AM
Originally posted by Mike Pauza
I hear what your saying as far as algorithm go, but a special form of the "verlet" algorithm is probably a better bet since it tend to "start to converge" very quickly (i.e. inherently stable). I agree about settings being a nightmare. BTW...I checked my PM's this morning and emailed you. :)

-Mike

The only problem with a verlet style integration is square root approximation. Right off the bat you have used only a 1st order Taylor-expansion or an equivalent Newton-Raphson iteration for only a few steps.

That is fine if you aren't looking for accuracy. I was thinking along the lines of having the user able to pick (or maybe the computer decide based on a slider) what is more important for the current sim.

No need for the user to remember that Kutta integration might take longer and not really look different than verlet, so long as it is as fast as need be.

Man, just thinking of how bad ass LW would be with only a physics addition, makes my head spin (ok, bad pun).

Something else we/I have always wanted to throw in was scripted control of particles. We had/have some psuedo working code of this using LUA inside of LW, but it is a major hack.

I think if the entire particle system was re-written to handle correct particle-particle collisions and expanded to include per particle (PP for all the Maya folks) control, soft body and hard body dynamics become almost a freebie.

I almost love to make pictures as program, or is that the other way around?

Cman
06-19-2003, 03:36 AM
HowardM is teetering on the edge of rambling rage!
Whoa dude - take a deep breath. :)

edit-
Amorano, you and Mike should hook up and make it happen!
I'm sure we'd all chip in with cash money! (ie, sell the plug...)
Hopefully low dollar, don't wanna pay for Impact all over again!

pelos
06-19-2003, 04:20 AM
for now, the only thing is to develop tricks!! jaja
unfurunality MD is what we have, and is not like maya that have 2 programs (default and syflex) Max that have for rope, cloth, etc.. and exactly dont know how work xsi
and why md2000 is still the same and newtek havent do anything? atleast add the preset,

Arte
06-19-2003, 12:15 PM
Originally posted by Mike Pauza
[B
x:

Sounds very interesting. I'm guessing the new crop of dynamics will have to be figured out pretty well before people want a more unified system though. :)

-Mike [/B]

Lol.

That sounds funny from one point but on another it sounds rather scary.

The dynamics are implementation independant right? As in I could throw in your dynamics engine into a system that allowed for such a facility with ease?

BTW if I read Elmar correctly he is saying pretty much the same thing I am but in more detail on how after implementation, it could work and also showing exactly how powerful such a system would allow Lw to become.


X

anieves
06-19-2003, 02:16 PM
Originally posted by Cman
Yeah, but a game type fast approximation might be good in some instances - if only for previz if nothing else. The main thing being to make it real-time.
An accuracy slider...
What if it worked like LOD, so the further from camera the less accurate and faster collisions calculate?

If he could get some standard for materials reaction using say, a 1 meter cube object, then he could adapt those numbers as the bounding box get's larger or smaller - so presets will actually be usable between a 1-meter and 4-meter character.

Just a thought/idea.

Hey Cman, that's pretty much what I was asking with the presets thing. How to make presets work the same way on diferent models. Your idea sounds good.

hrgiger
06-19-2003, 03:06 PM
I started this poll several months back:

http://vbulletin.newtek.com/showthread.php?s=&threadid=916

Chuck said they were watching the poll with interest and as you can see, improved softbody dynamics were and still is number one on the list. I would hope that means that improved softbodies is in the works for 8.

Mike Pauza
06-19-2003, 05:08 PM
HI GUYS! THE NEW DEMO IS READY IF YOU WANT IT!!!


It's interactive...dos-like input, but it works!
It's in 3D...the lighting is bad, but it now has real perspective!
It's much faster...still not optimized, but pretty darn quick!


This demo drops a cube into a plane. You can control cube stiffness, viscosity, aerodynamic damping, gravity, and a few other simulation parameters. The simulation can "be broken", but is relatively stable (because of my spring model and integration scheme), and hopefully sets the stage for creating similar demos using large arrays of these cubes acting in unison for some very interesting behavior.

The demo is 1.4MB. I emailed a copy to everyone who got the last one. If you didn't get a copy or you would like to sign up for "my mailing list", email me at:

sharonpauza@aol.com



BTW. I'll try and respond to all the new posts tonight. Thanks, you guys (and gals?) rock. :)

Mike Pauza
06-19-2003, 05:32 PM
BTW:

This simulation model does not yet account for surface friction...for now just imagine it's sliding on ice.

Also, the cube will loose some kinetic energy when it hits the plane so it's potential to bounce back up into the air is fairly limited. This comes from the fact that vertices (which contain the mass and thus some of the energy) hitting the ground are constrained to instantly stop thier motion normal to the ground. This unfortunate side effect will lessen dramatically when simming an object using arrays of cubes.

-Mike

pelos
06-19-2003, 08:24 PM
some thing about the preset is relative, because you can still manipulate the gravity and the wind, and the style of the wind,
maybe adding a readme like inside LW7 that give the refraccion of the materials, or the pixel formate for tv etc...

Mike Pauza
06-19-2003, 08:42 PM
Looks like my new email account is not working. If you need to contact me please mail me at my old account:

sharonpauza@aol.com

Mike Pauza
06-20-2003, 07:49 AM
KNOWN DEMO2 PROBLEMS:

Damping Problems...just an input problem I hope.
Friction...it's unanamous, everyone hates the frictionless plain!




DarkLight, Cman, DigiLusionist, and anieves:

I don't think the user will have to create parameter settings from scratch (unless he wants to), and I think collision detection will be very fast. I'm starting to think more and more that the new paradigm will be to forget simming the geometry altogether, but rather "rig" it with a physics based control structure. "Dynamic bones" could be big!




HowardM:

After a couple of years struggling to become a great LightWave artist (only to have my butt kicked) I decided to get back into dynamics. That's where "I think" I can make a difference.

Don't thank me (yet)...the thanks goes to you guys for steering me in the right direction. :)




amorano:

I know RK is more accurate, and you know RK is more accurate, but like you said, the user doesn't care how mathematically precise the thing converges...just how good it looks and how fast it is. Plus, the velocity form of the Verlet is much simpler to code...hehe. Honestly though, I use Verlet for just about everything and don't really have a good feel for when another method would be superior.

Particles...Woah Boy. You want to tackle CFD, heat transfer, and acoustics while we're at it? Just joking. Yeah p-p based simulation (using the Lennard-Jones potential...or something similiar) should be easy to set up. The trick would be to come up with an efficient position sorting routine to fix the N-Squared problem, and possibly some "particle modeling/animation tools" to create surfaces like water, air bubbles, etc...HV's don't really cut it. BTW, have you thought about streamline based particle animation? The user would set up a vector field (hopefully with the aid of some "modeling tools") and have the particles flow through that. That might be a quick and dirty alternative to simming with millions of particles.

Email me some time dude.




x:

What about assigning the "material" in surface editor, but tweaking the parameters in a sim control window?




hrgiger:

Improved Soft Body Dynamics is the #1 choice? That's awesome!

Arte
06-20-2003, 12:07 PM
Originally posted by Mike Pauza
x:

What about assigning the "material" in surface editor, but tweaking the parameters in a sim control window?



Hi Mike.

That's pretty much what I expect to happen anyway in a properly developed system.

A sim control window could handle things like accuracy as well as a personal favourite of mine. Overlap.

How many times have you placed something and not noticed it is slightly penetrating another object.

BTW, you may be seeing yet another issue for a unified system when you brought up particles. Shame it's not my type of math though as I have no idea what calculations are really taking place. Any links for some follow up reading?

BTW if you want to see some of what is realistic using Object type models the KOSH papers by Dave Haynie should be quite easy to find.

X

E_Moelzer
06-20-2003, 02:35 PM
OBB- trees are trees of Oriented Bounding Boxes.
Imagine an object defined by bounded boxes. In case of a character, you would have a big one for the entire object, then one for the head, one for the torso, one for each limb (there are algorythms that can create the OBB- trees automatically). This is getting more and more precise. In the end there is a bounding box for every edge and every vertex in the object.
I. e: You start with a bounding box around the entire object.
If no colision occurs between that box and another bounding box, you can break, if it there is a colision you go deeper into the tree (getting more precise) and check again. Again, if there is no colision happening, you can break, if there is one, go deeper etc...
The precision can be defined by how deep you go into the tree and you can get some colision- offset by making the OBBs a bit larger.
Its just an idea, I read about on gamasutra.com a few years ago.
Things like these can be used for colision- detection or visibility- prediction.
CU
Elmar

DarkLight
06-20-2003, 02:54 PM
There's a resource guide on gamasutra that may help.

Physics Resource Guide 2003 (http://www.gamasutra.com/resource_guide/20030121/)

E_Moelzer
06-20-2003, 03:07 PM
Here is one article on OBBs and collision:http://www.gamasutra.com/features/20000330/bobic_pfv.htm
Not sure if you can make any use of it, but maybe it helps...
CU
Elmar

Mike Pauza
06-20-2003, 11:20 PM
x:

Don't have a great source for particle sim on-line. Here's a decent one:
http://www.gamasutra.com/features/20000623/vanderburg_pfv.htm
Computer Simulation Using Particles (by Hockney & Eastwood) is probably definative theoretical text.

Minimzing overlap might be hard with the algorithm I'm thinking of. Hopefully that will work itself out.




E_Moelzer and DarkLight:

I have had those articles sitting on my hard for some time now, but haven't read them yet. I guess I need to.

Mike Pauza
06-20-2003, 11:29 PM
DEMO 3

BTW, hopefully I can have Demo 3 ready by the end of next week. Demo 3 will fix the current bugs and feature some realtime sims of cube arrays...hopefully I'll be able to get some really sweet bending, tapering, jiggling, wave propagation, etc. I'm open for suggestions what you would want to see...jello jiggling, a bouncing/rolling tire, bouncy balls, twisting/bending rods, etc.

-Mike

Cman
06-20-2003, 11:49 PM
I want to see you continue to develop that puppy! :)
Do you believe you will be able to convert this stuff into realtime deformations inside LW?
I know it's a dumb question, but do you see this hooking in?

Zithen
06-21-2003, 12:01 AM
Originally posted by Mike Pauza
I don't think the user will have to create parameter settings from scratch (unless he wants to), and I think collision detection will be very fast. I'm starting to think more and more that the new paradigm will be to forget simming the geometry altogether, but rather "rig" it with a physics based control structure. "Dynamic bones" could be big!
I do think polygonal dynamics are important. Like I want to use bones to move the skin of the face and have the skin move dynamically. In order to do that, the bones would have to influence the soft body object.

But I like the idea of using dynamics with hierarchies. Basically you'd have dynamics applied to the Heading, Pitch and Bank angles/channels as if their axis were dynamic springs. You could set the compress maximum angle and stretch maximum angle...like min/max values for the range of motion allowed for that joint. The keyframed motion could be a force in the dynamics and you could have a parameter that sets the strength of that keyframed force with the dynamics of the hierarchy. Then maybe assign collision spheres or elipses around the bones or objects in the hierarchy so they'll collide with each other, though not totally accurately of course.

Mike Pauza
06-21-2003, 08:39 PM
Cman:

Yes. Deformation of objects using small arrays of dynamic bones will be realtime.




Zithen:

Yes. A very simple system of dynamic bones would be great for character animation.




BTW...got the damping input problem fixed last night. Maybe I can add surface friction tonight...I'm holding off on real collision detection in general for now...for the plain in my demo, collision is trivially simple.

Celshader
06-21-2003, 10:07 PM
Originally posted by HowardM
the fact that I CANNOT enlarge the MD window to see all variables at once, and have to repeatedly scroll for no reason, reminds me of the good old Amiga days....garageware!

Activate the "Hide" checkbox to show only those settings that have been altered from their default values. It helps reduce clutter and scrolling for me -- I rarely use all of the settings at once.

I agree that scrolling can be a pain, though.

Mike Pauza
06-22-2003, 03:10 AM
For all you guys and gals around LA, Jennifer (Celshader) is giving a talk tomorrow on Motion Designer:

http://vbulletin.newtek.com/showthread.php?s=&threadid=6597

adrencg
06-22-2003, 04:19 PM
Originally posted by Mike Pauza
For all you guys and gals around LA, Jennifer (Celshader) is giving a talk tomorrow on Motion Designer:

http://vbulletin.newtek.com/showthread.php?s=&threadid=6597

can someone at that meeting maybe tape it and post it as WMV or something. Then we all could benefit from her knowledge.

Mike

Mike Pauza
06-22-2003, 06:16 PM
Howdy Yall.

Version 2.2 is done...I have fixed the damping problem and added friction. It looks much better now. Instead of spamming you guys on the "mailing list" with every little update, I'll probably send out just the major ones unless you email and tell me otherwise. This thread has been very productive IMO, but it seems to be winding down. If it dies, I'll start a new one when I'm farther along. In the near future things should start to get interesting.

Thanks guys. There's little doubt that LightWave's community is by far the most generous and enthusiastic out there.

-Mike Pauza

HowardM
06-26-2003, 05:29 PM
Here something we need - Error detection!
Nothing worse than waiting a long time for MD to calculate and to see things get out of wack, polys flying all over...
what if the new software checked for errors before the calculation is fully made, and would tell you if you needed to retweak a setting? too hard?

anyways, definitely would like to see all parameters (spring, hold, etc) animatable!

Mike Pauza
06-26-2003, 07:28 PM
DEMO3:

The good news is that I'm going to do it in LScript, the bad news is that I have to learn LScript first...so it will probably be a few weeks or more before it's ready to show (work stinks).




HowardM:

Hopefully, error propagation will pretty much just be a function of the timestep/number of calculations per frame. Automatic timestep sizing could probably be done so that the sim is relatively accurate, but it would probably be very kludgy (like MD currently is). It's not that hard to watch the total energy of the sim to see if things are exploding, but setting the timestep for collision detection can be tricky...imagine how small your timestep would have to be to detect a bullet colliding with a piece of paper. It would be kind of cool though to have the code run the sim for you a number of times using progressively smaller (halfing) timesteps so that you can get a feel (by comparing the runs) for how much better the next level of accuracy will be and how long you'll have to wait for it.

pelos
06-26-2003, 07:43 PM
something i saw in a demo of xsi, is the calculation, of dynamics, are very fast, i dont know how much, but in the demo where impresive!

Joviex
06-26-2003, 08:03 PM
Originally posted by Mike Pauza
DEMO3:

The good news is that I'm going to do it in LScript, the bad news is that I have to learn LScript first...so it will probably be a few weeks or more before it's ready to show (work stinks).



Just a heads up on that, LScript, even compiled, is orders of magnitude slower than anything else.

In doing the kaboom port which was all lscript, we noticed a 40x increase when done in unoptimized C. That is very scary.

Just so you don't go pulling out any hair, and end up bald like me.

Zithen
06-26-2003, 09:12 PM
Yeah, it would be cool if it was not in Lscript.

How about an adaptive collision detection where it automatically increases the timestep depending on how close objects are. I think next limit's "RealFlow" does that.

Cman
06-26-2003, 09:41 PM
You know more than me, but LScript is probably a bad idea. LScript has many limitations that would suggest you not use it - it often breaks scripts with each update because you never know what commands you used might get bugs, many functions and commands available through the SDK are still hidden from LScript, and it's MUCH slower than a compiled plugin (See Amorano's above story), etc etc.

I strongly recommend you go through the SDK.

Mike Pauza
06-27-2003, 04:54 PM
LScript:

If I want to code this stuff quickly and by myself, I'll need to do it in LScript. I might have some help though. :)




amorano:

40X slower huh? That's pretty bad. BTW, what's kaboom?




Zithen:

Varying the "collision detection timestep" might work pretty well. If objects are close together (like you said), small, or moving very quickly, then the timestep could be decreased. Maybe have a "max time step" that the code can decrease if it thinks it needs too. The "springs timestep" could be independent of the "collision detection timestep" (which is the real bottleneck).




Cman:

I want to use the SDK as soon as possible. Hopefully that's soon.




-Mike

Mike Pauza
06-27-2003, 05:00 PM
I'm trying to simulate a rubber tire using 120 of my cube primitives connected together (see pic). I'm thinking that with just plainer collision detection this should run at a decent frame rate.

The black lines indicate the structural geometry which the sim will be based on, but do you guys have any idea's on how represent and control the surface. I'm using the outer vertices of the structural geometry to create a SubPatch surface in this pic, but notice how the visible geometry is not an accurate approximation of the structural geometry...would some sort of offset work to make the SubPaches match up? What about using splines? What about using bones located on the vertices to control another mesh entirely?

-Mike

Joviex
06-27-2003, 07:32 PM
Originally posted by Mike Pauza
LScript:

If I want to code this stuff quickly and by myself, I'll need to do it in LScript. I might have some help though. :)

amorano:

40X slower huh? That's pretty bad. BTW, what's kaboom?



Yes, easily 40x slower. If you are good at picking up new code styles/languages I recommend you start with the SDK and don't waste time with Lscript. JMHO.

Kaboom was originally an explosion Lscript written by Neil Nafis.
www.nafii.com (http://www.nafii.com)

He asked me to rewrite some of the ideas with additions. It ended up as a rigid body solution with external forces being scripted via LUA.

Mike Pauza
06-27-2003, 08:18 PM
amorano:

Kaboom looks cool.

I was holding off on adding plasticity and fracture to my cube model, but after seeing that script I'm wondering if it would be as hard as I had originally thought. Hmm.

Joviex
06-27-2003, 08:23 PM
Originally posted by Mike Pauza
amorano:

Kaboom looks cool.

I was holding off on adding plasticity and fracture to my cube model, but after seeing that script I'm wondering if it would be as hard as I had originally thought. Hmm.

Actually its not :)

The fracturing is obviously done modeller side with that script. I do long for the days when LW will support geometry creation and editing in Layout though.

The fracture process is slightly different for volumes, but it is as straightforward. Booleans with recursive error metrics until it works 100%.

The only drawbacks to the kaboom script originally were porting (he wrote some of the motion for layout with visual basic) and speed. The actual cracking process he used with Lscript was excrutiatingly slow.

Mike Pauza
06-27-2003, 10:51 PM
amorano:

Well If geometry can't be created on the fly in Layout I guess some "extra geometry" could be loaded up and hidden until needed for fracture...that seems like a really poor way to do it though.

Celshader
06-28-2003, 12:43 AM
Originally posted by Mike Pauza
I'm trying to simulate a rubber tire using 120 of my cube primitives connected together (see pic)....do you guys have any idea's on how represent and control the surface.

What do you want this tire to do?

Joviex
06-28-2003, 04:11 AM
Originally posted by Mike Pauza
amorano:

Well If geometry can't be created on the fly in Layout I guess some "extra geometry" could be loaded up and hidden until needed for fracture...that seems like a really poor way to do it though.

Indeed. What we did was bypass multiple layer objects with the plugin. We basically cracked and tagged pieces with a Kaboom_xxx convention, then in layout searched for those pieces to be used in the simulation and collision purposes.

It worked out ok, since the object didn't need to have 100's of layers of small pieces, but it was a pain to do, and I had to use a dispalcement plugin, a hacked global master plugin and a generic plugin (that makes 3 ) in order to perform the sim. Not very friendly, but it worked.

Mike Pauza
06-28-2003, 07:52 AM
Celshader:

I have code to simulate one cube colliding with a plain, but not a bunch of them or in LW yet, but...I'm fairly confident I can get the current mesh to smoothly exibit large deformations, pressure wave propagation, realistic friction, etc (ie a jello tire..hehe). My real concern is how to use that "geometrically light simulation mesh" to precisely control an ordinary high resolution tire geometry.




amorano:

Fracture is cool (so's Kaboom), but probably unrealistic for me right now.

Zithen
06-28-2003, 08:07 AM
Here's a paper that may assist.

http://graphics.stanford.edu/papers/cloth-sig02/

It would be great to be able to do realistic cloth simulation. Star Wars II had great cloth simulation going on.
Further down the line, to have realistic turbulence from air would be ideal for cloth simulation, so we can have cloth flowing and flapping in the wind.

Mike Pauza
06-28-2003, 08:21 AM
Zithen: WOW.

HowardM
06-28-2003, 08:29 AM
but Zithen, thats already been done in MD! - http://forums.newtek.com/discus/messages/2/27478.html?
MD is GREAT once it works, its just very very hard to get things right...it doesnt need a total rewrite, just a rewrite of the interface!! well...ok a more integrated rewrite would be nice...with all our feature requests added of course! :)

Zithen
06-28-2003, 09:50 AM
I'm afraid we can't achieve that level of detail in the folds and wrinkles as you see in that paper with any real quality or in a reasonable amount of time with MD. We're referring to the efficiency of the underlying code...not just doing a simple animation.
MD isn't very robust. The paper presents a way to deal with collisions more accurately and efficiently.
The paper also talks about a collision aware subdivision surfaces scheme, which is what Mike was seeming to look for.
In my opinion, a whole new dynamics engine is in order. Hopefully we'll have that soon.

Celshader
06-28-2003, 09:14 PM
Originally posted by Mike Pauza
My real concern is how to use that "geometrically light simulation mesh" to precisely control an ordinary high resolution tire geometry.

If you can capture an MDD file of this deformation using MD_Scan, use MD_MetaPlug to "playback" the MDD of the low-res mesh onto the high-res tire.

:shrug:

Cman
06-28-2003, 09:28 PM
Originally posted by Celshader
If you can capture an MDD file of this deformation using MD_Scan, use MD_MetaPlug to "playback" the MDD of the low-res mesh onto the high-res tire.

:shrug:

But he's trying to write a plugin that will basically automate all of that and make realtime dynamics in LW.

Mike Pauza
06-30-2003, 07:56 AM
HowardM:

Your last comments made me pull my hair out in frustration until I realized you have some common misconceptions that need to be addressed. :)

Let me say first and foremost that huge engineering companies have spent billions developing various types of physics simulation softwares. Seldom are they perfectly accurate, but many packages day in and day out produce results that are amazingly close to measurable reality (see the PhysicsBasedPhysics.gif attachment). They are so good in fact that they make MD and physics capabilities from other 3D vendors look like utter garbage IMO.

In the recent past, the 3D industry (which is tiny compared to even one of the major engineering firms) tried to making animating complex natural phenomena easy by integrating some "college physics" into thier existing toolsets...sounds like the smart way to go about it doesn't it? Well the problem with that has been twofold. Firstly, the animation industry doesn't seem to understand much about physics and engineering (why would graphics gurus want too anyway?). But the main problem is that GEOMETRY FOR GRAPHICS IS COMPLETLY DIFFERENT THAN GEOMETRY FOR SIMULATION!!! Trying to use "regular 3D geometry" in a physics simulation is flat out mathematically incorrect...OOPS. Let me repeat the fact that "modeling for simulation" is very much like "modeling for animation"...looking good just sitting there does not mean it will deform correctly.

The mistake is unfortunate, but now is the time to make up for it by adapting what other industries have learned to our own. Maya still has crappy soft body dynamics (like the rest of us), but since thier beginnings were rooted in scientific visualization (Wavefront's Advanced Visualizer, Explorer, etc.) they have realized more quickly than the rest of us that physics based engineering apps are prototypes to the indutry's future. They have developed decent hard body dynamics, and are currently developing some very impressive fluid simulation abilities (by adapting known fluid simulation practices to 3D animation). I'm not a Maya fan by any means, but we need to embrace the future before someone else runs away with it. Soft Body dynamics is the logical first step for us IMO.

BTW, if you do some research on ILM you'll see they are actually the undisputed leaders in physics based animation.




Zithen:

Thanks for the article link. I now have a handful that just blow me away.




Celshader:

Thanks for the suggestion Jennifer (really), but as Cman said this is snowballing into a something hopefully head and shoulders above MD...maybe when the code is farther along some of you MD gurus would be willing to take a look?

freerider
06-30-2003, 03:49 PM
I just had to make a post and say what a great job I think your doing Mike. I'm following your progress with great interrest. I have a fair bit of programming skills, but the physics of it is beyond me. Good luck , and please keep us updated :)

HowardM
06-30-2003, 04:21 PM
Yes Mike thanks for everything!
But what did I say? :) hehe, I dont think for $2000 LW should have or needs 100% realistic HD/SD...we can leave that up to ILM and MIT....what we all know is it needs is to be a hell of alot more user friendly...it works fine for FX and Animation as it is...again, especially for $2000.

I would be the happiest guy if NT just made PFX and MD/HD/SD one coherent piece within LW...including Envelopes and Gradients that all work alike...sheesh where the hell is the Particle Age tab in the gradient for Birthrate of an emitter?!?!!? know what I mean? Honeslty, why do some gradients only have Distance to blah blah, while others have Particle Age, Weight, Speed, etc?!
oyyy.
Monday Morn!
:(

Mike Pauza
06-30-2003, 04:41 PM
HowardM:

Yeah, this doesn't need to be rocket science for the user, but it does need to be kinda based on rocket science internally for it to work properly. Image what you could do with a simple to set up version of MD that just works. :drool:

Mike Pauza
07-01-2003, 03:43 PM
GOOD NEWS:

I got some LightWave SDK programming help, so it looks like the next demo will be a LightWave Plug-In. Hooray. Don't expect it for another month or two, but this one should have a little usability.

-Mike

Cman
07-01-2003, 06:15 PM
Ooh schweet! Looking forward to it!

E_Moelzer
07-01-2003, 07:31 PM
Hey Mike, check your private messages pls.
CU
Elmar

Mike Pauza
07-01-2003, 07:33 PM
I'll send everyone on the existing mailing list a copy when it comes out. If you want one email me at:

mike@3dpiranha.com



BTW, amorano is going to do the SDK coding. Hopefully we'll come up with something special. :)

colkai
07-01-2003, 08:39 PM
Much goodness !!! ;)

CGTalk Moderation
01-15-2006, 11:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.