Physics for DAZ STUDIO
Veneris
Posts: 115
How many years have to wait?
You currently have no notifications.
How many years have to wait?
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
lol I hear ya
some dude did physics 6 years ago, but apparently he abandoned the project, look at minute 3:00
When I discovered Daz a year and a half ago I was really excited about making particle dynamics and physics stuff in Carrara and then piping it into Daz. Because of course the two programs would have synergy.
siigh
Physics (both rigid and softbody) is the ONE thing that DS is really in need of......aside from up-to-date documentation.
It needs it so badly that independent developers are trying to make stop-gap and full featured physics systems to splice it into DS. I'm one of them.
Poser has it. Carrera has it. Blender has it. LOTS of other render/animation packages have it.
DS still doesn't.
The hardest part is there is no way to load a non-linear progression-based morph. All morphs are simple linear start/end progressions (per vertex). While that's fine for rigid dynamics and simple conformable objects, it is a problem for soft-body objects. DS needs a 'progression' morph type (where each vertex has set of positions(or splines) it moves through as the morph is dialed from 0 to 100%, rather than just between two positions.) This would enable generating a full animation deformation of an object for a given movement of the vertexes (as well as updating them) based on the simulation, rather than having to do object swapping or huge numbers of individual morphs. Caching vertex deltas for every keyframe would be very memory hungry. Being able to convert those as they are generated into a set of spline based progressions would enable a lot of functionality.
(now my head is trying to figure out a good programming structure to hold and utilize such a 'morph' efficiently again......)
Particles and metaforms would be wonderful too.....
If DS 5.0 has Physics, Particles and Metaforms, I'd be so happy I'd probably squee like a teenaged girl.....
(just as an example: A moderately complex scene has ~1million vertexes. Maybe half of those need simulation....lets be conservative and say a quarter. So 250k vertexes. Now for say a 10 second animation, at 30fps, is 300 frames. Thats 75 million vertex positions to cache for the whole simulation (1 per vertex per frame). That's about 225 million floats to store. Or about 900MB. Now if we instead decompose the invidual vertex positions into connected splines, at say 1 spline/second....that's 10 splines per vertex, at about 48-144 bytes per spline (depending on what kind of spline is used) which gives us about 36MB to store. That is 1/30th of the data, with very little loss of detail....though very noisy motion would be lost. Toughest part is doing the curve-fitting to get the spline parameters from the sequence of vertex positions.)
Ok, I think I understood the idea. How long will it take to see the finished system?
i'd settle for collison detection.
:)
j
I'm actually working on this. However, there are some issues to overcome with the Plugin SDK.....namely, that it isn't completely documented, and the docs we do have are out of date. And there are only a very few examples.
I've actually got a question over in the Plugin SDK discussion, that is what I'm stuck on currently. While I can generate collision volumes for simple primitives, simple props, or properly built figures.....not all figures are 'well-built'. Specifically, they have facegroups for bones that are not named the same as the bone. So until I can find a way to handle that (and selection maps aren't working how they appear they should or I'd already have a solution) I'm very limited in how I can progress. Once I can get the facegroup from the bone in all cases, I can approximate geometry (either with simple primitives, groups of primitives, convex hulls, or even full mesh) for the collision volumes.
Building up a custom DzModifier that handles what I describe above is a whole different story.....but I'm going to work on that too. Would make things easier.
I just wish we had someone from DAZ development actually reading the Scripting/Plugin sections of the forum regularly, and helping more frequently.....So many questions there that never get fully answered.....
Naw...just need to clone him a couple dozen times...
You do need to remember that the developers are already fitting quarts into pint pots by contributing in their nominally off hours. It would be nice to have someone whose principal duty in working hours was helping with these sort of questions, but it isn't something we can realistically expect and we should be very appreciative of the considerable degree of assistance we do get (especially from Rob, who not only answers a lot of forum script questions but also keeps adding samples to the documentation area to show how things work, and all of the devs who are active in the SDK forum).
Do understand....I am very grateful to Rob and the other developers who give some of their own time to helping out here. As a professional developer myself, I understand how time-consuming our jobs can be.
But it does seem a disproportionate amount of the assistance goes to the Scripting Forum, and not to the Plugin SDK forum. And when there have been mulitple threads over the years asking about the same basic things that never get answered.....Even just a "you can't do that with the SDK yet" would be helpful, since we could stop trying to find some deeply hidden and obsucre solution (not that we won't still try to find some hackish workaround...)
And if the question calls into question possibly bugged behavior with the SDK, it's kind of important....
But the single biggest help for ALL of us script/plugin developers would be for DAZ to take a development cycle or two and instead of adding big features, just fix bugs and update the documentation. The 4.5 SDK is still incomplete, sparse, and quite outdated (seeing as how the major renderer in use wasn't even available then, specifically Iray.) But I'm not holding my breath on that one......I know how far down the priority list documentation goes in most development houses......
hphoenix, a year later I've always been meaning to tell you how much of a hero you are to poor, physicsless folks like myself.
If you are still working on the problem hphoenix, please, please don't give up! Let us know how you are progressing. Do you think you can make a real physics engine for DS? With particles, fluids, wind, gravity, collision detection etc? If so, any hint as to when you might release such plugin(s)?
It occurs to me that the fact that DS itself is constantly being upgraded may mean it's difficult to get a plugin working with the latest version of DS. Believe me, there a lot of folks willing to pay for such plugin(s) and the upgrades for newer versions of DS.
Good luck.
...and let's not forget about real IK and dynamic clothing and hair. I'm working more and more in Blender, and learning how to bring my Poser/Daz items into it. At some point I hope to be able to abandon both Poser and Studio.
Dynamics to some degree come with the physics part, since the engine he's using supports it.
Hello, sorry for putting a post nearly a year later, but I totally agree that the big missing thing in DAZ Studio is the Physics of objects. I mean that the objects could have collision detection and dynamics so they would be acting like in reality and you could have more realistic renders.
For my personal point of view and taste, I do not want to have physics animation, just a physics preview to select the best moment of the physics reaction between objects and then freeze it to have a still render
You could export some of the 3D models, characters and props to other 3D software with physics, BUT then you would miss all the very good, cool and awesome shaders and special materials already available that only work inside DAZ Studio.
So it would be really good that in 2018 there could some way to have some physics collision detection between objects
Thanks
Happy new year 2018
Have you seen https://www.daz3d.com/forums/discussion/203081/dforce-start-here#latest ?
Does anyone know if Physics (including multi-object collision) is being worked on by DAZ3d for a (hopefully not too distant) future DS release? Or is it in the "pie in the sky"/"jam tomorrow" category?
The only way to guess is to keep an eye on the change log, though of course that isn't always revealing (both dForce and Iray were pretty much stealthed as far as the changelog went).
Hmmm... makes me wonder why DAZ3d play their cards so close to their chest with regards to developments in DS. Are they worried that the competition will get the drop on them if they announce they are working on Physics? Haven't they noticed that the competition already has Physics implemented? Or perhaps they are worried about getting clients expectations up and then not being able to deliver (in a reasonable time)? Or perhaps they have no intention of including Physics in DS, ever?
Personally, as a client, I would like to know where they are headed and at least some indication of when they may arrive at their target. This would make it easier to plan and make decisions on what kind of software to invest in. A "cloak and dagger" approach doesn't really work when you are behind the competition.
Considerig that dForce has been introduced as a "physics simulation engine" I'd say you're wrong on that one....
You are joking aren't you, Leana? dForce is a cloth simulation system; it is far from being a physics simulation engine, as I'm sure the developers would agree.
From the first post of the Official thread, the very first comment is
So, then I'm right, it is not yet a full physics engine, just a cloth simulation at the moment. Semantics? Maybe, but at the moment the functionality is limited.
No, you said it was **just** a cloth simulation engine and you thought someone was joking at the though that it was more than that. But we appreciate the clean up.
I don't know to call it less than a physics engine because various models haven't yet been created to take advantage of it is misleading. It is a physics simulation engine. Now DAZ 3D will add other physics simulation algorithms to it and DAZ Studio in the future but you are mistaken if you believe the physics being applied to cloth in dForce is only applicable to cloth.
If you are interested in physics in DAZ Studio then learn it because you are only going to have that much more to learn as other types is physics simulations are integrated into DAZ Studio.
Even nVidia's physics engine isn't a complete physics simulation engine by any stretch of the imagination and took a very long time for them to build and is still being debugged and expanded. If DAZ Studio's engine is not ready for you, go learn nVidia's physics engine in depth, it can only help you use DAZ Studio's more effectively.
Oh dear, Male-M3dia... note my first quote "dForce is a cloth simulation system" and second quote "just a cloth simulation at the moment". Please note in the second quote that the adverb "just" is conditional on the expression "at the moment".
nonesuch00, you are right in saying that dForce is a physics simulation. The term cloth is somewhat misleading as there is no cloth involved, rather a polygonal mesh which could represent any object. However, DAZ have said that they do not yet support the use of dForce for other applications. So currently dForce is used for cloth (or similar objects) simulation. Believe me, I'm eager to see that situation change.
me too
Fisio: Physics Simulator
https://www.youtube.com/watch?v=J1eN8J6o6rQ
Nice. Is that a product?