dForce need to be replaced with XPBD based simulation system.
butaixianran
Posts: 161
Check following video for the power of XPBD based cloth simulation:
Marvelous Designer already has it for years.
Cinema 4D has it from version S26 in 2022.
Blender says they plan to have this in 2023-2024.
Why every other 3D tools want it? Becasue XPBD based simulation is too fast, and too easy to use. Also there is no explosion issue.
A 5 hours' simulation task for the old cloth simulation system, can be done with XPBD in about 5 minutes, and still comes with a good result.
XPBD is a whole generation for cloth simulation, like PBR and ray tracing for rendering.
For those who tried XPBD based cloth simulation, won't even touch any old cloth simulation system any more.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
More natural and realistic draping, no over-stretching, accurate multi-objects collision, softbody sim, real-time sim, no poke-thru, and high performance, etc... Hopefully Daz is not falling behind and can realize them all one day...
maybe someone could add it to Carrara too
What is this? If it's existing code with a suitable license then all you need is to add the Daz Studio SDK.
It seemed that a couple of German guys developed an extended position-based dynamical algorithm years ago that could enable even more advanced simulation results with fast speed, and it's much better than force or impulse based dynamics. I ever tried the simulation in C4D 2023 by following a tutorial and the result was impressive though there had to be a few complex setup. Not sure if it could be licensed, but if Daz could get and implement it to its SDK, the simulation in DAZ would be a whole new world! That'll be fairly fairly amazingly great!
I was saying a third party could use the SDL to add it to Daz Studio, if it was in a suitable form. If not (not published in a form that can be used as code, or at least a finished algorithm free of patent liabilities, for example) then even Daz probably couldn't do anything.
Really? That's all you need to do, huh? "Add the DAZ Studio SDK". You make it sound so easy.
And who knows, maybe it is, until you hit the first fundamental problem for which there is no, or completely insufficient documentation in the SDK, Google returns nothing useful, the SDK forums either say nothing about it or a similar question gets 0 replies because no one knows, the devs ignore you, and you give up in frustration after trying every single permutation of what the correct implementation could possibly be, given what you can observe.
I'll repeat what I've been saying for over four years now: We should all be screaming for better documentation, in our own interest, so that the number of enterprising nerds that could actually implement something like this is maximized, and they have the greatest probability of success.
We didn't need a G9, we needed documentation of what's already there.
Oh, I know less about development... But frankly speaking, as a pure user of Daz, at least I myself have been expecting a brand new Daz for years, with enduring hope from many perspectives: software framework, functionalities, sim engine, performance, documentation so on so forth but not a G9 of course~
Agree with TheMysteryIsThePoint on documentation. Daz could use way better documentation. I have had all sorts of thoughts about automating a bunch of processes, like auto positioning the left hand on a rifle given the right hand position. But without documentation it is just too difficult for a serious hobbyist like me. I am hugely impressed with the Devs who can create stuff in the absence of documentation. Sickleyield must be a wizard. Us mere mortals could really use the help.
PS. The bone structure on G9 suggests that Daz is pointing to tighter integration with Unreal 5. I applaud that effort even if I am bummed that I have gone all in on G8.
Ok, I'm glad people still care. And here is some information about XPBD.
First of all, it's actually not a new thing. Open source XPBD projects have been build at least 6 years before. And Blender community has discussed XPBD since 2018.
There are tons of open source XPBD projects on github with MIT license. Daz team should check them. This system can be done as a Daz C++ plugin.
Above posts talk about Daz's script document. Actually, that document is not that bad. API is all there, with some important examples. Also this forum keeps replying all those questions about writing a script. The bad part is Daz's C++ plugin's document. That's why there are so many Daz scripts, but barely any C++ plugins.
About how XPBD works, it treats mesh as a collection of particles. All of its parameters are about particles.
For example, the distance of particles. Less distance means more particle on a mesh and simulation will be slower, but with better result. The same about gravity. A part with more particles on a mesh, will be heavier than a part with less particles on that mesh. So, it's not just as simple as build a plugin. People need to think simulation in another way and have meshes designed for XPBD. Luckily, most clothes are done with MD, which is already based on XPBD. So, clothes won't be an issue. But other meshes, may need to adjust for XPBD.
Like I mentioned, XPBD is a whole new generation.
But the scripting is much the same API as the plugins, with looser constraints on things like typing of course and with soem features lacking. But the script docs and samples should provide a solid grounding for SDK development, and judging by the change log both are documented together (though teh need to maintain API compatibility means we don't yet have an SDK with the new features available in script, adn so don't get the updated documents either).
I'm pretty sure we have more scripts than plug-ins because they are easier - no extra tools needed, no worries about linking the right libraries, easily iterated, cross-patform and so on. I've certainly written and released far more scripts for DS than I have applications, and all of those that saw the light of day were written in a compiled Basic.
No. This may seem to be the case because a lot of the function names are the same, but the Scripting documentation is generally useless for SDK development because Scripting hides many details that the SDK programmer can't avoid. Some classes, like DzQuat actually behave differently. Go to the SDK forums and see the flared tempers about this.
And, C++ is a complex language. As I've said many, many times before, much of the documentation that is even there at all is of the form "void setFoo( Foo* ) - Sets the Foo" which does nothing more than state the incredibly obvious, and does nothing to tell a prograammer what he really needs to know, things like who now owns the Foo object just passed in? Is it deep copied or by reference? Do I have to free it myself? Does it matter if I new'ed it or malloc'ed it? Is it thread safe? Does it throw exceptions? Does it truly work the same for all of Foo's subclasses? This is totally insufficient.
It is not helpful when, for whatever reasons, we invent reasons for why things are really not as bad as they seem, when there are so many people that actually use the SDK saying that it is totally insufficient. The chance for getting better documentation is maximized when we all report things objectively how they actually are, not as how we may imploy logic to guess at how they ought to be. Has anyone ever read where an SDK developer wrote that the documentation is anything other than useless? That is the reality and no amount of dressing will make it easier to write tools. Please excuse my tone, if it needs excusing, but this kind of rationalization is harmful because it distorts the reality of the situation: Scripting documentation does not help at all with SDK development.
In order to maximize the number of great tools available for DAZ Studio is to make it easier to do so. Right now, even the simplest things are way too difficult to figure out and to be sure that they are implement correctly.
I think you need to check the definition of "objectively" if you use that tone in making your reports.
The primary property of objectivity is that objective assertions remain true, independent of the tone in which they are expressed, c.f. subjectivity.
If my tone shifts, it's because I often see posts that minimize the problem and its importance, citing examples that are simply not true. That is as frustrating as it is inexplicable.
Please, we just need better SDK documentation, not uninformed and false reasons why we don't. I do not understand why that should be in any way controversial, or be something that everyone who uses DAZ Studio would not support without qualification. The end result will be more cool stuff for people to use for which DAZ didn't have to expend any resources at all, right? That's what we all want, isn't it?
I like the phrase @jsdaz_5811013940 used: "serious hobbyist"... I am sure I am not alone in that I have no lack of ability or passion for DAZ Studio, but these things are not my full-time job, I also have a family, and so my time to dedicate to developing tools for our community is extremely limited. I don't have time to reverse engineer every single simple thing that should have been fully explained in the documentation. Again, look in the SDK forums and count how many naive, bright-eyed users pop in for the first time, ask an inportant and reasonable question about something cool they described (and would be really useful), get 0 responses, and are never heard from again. Now imagine a DAZ Studio that had all of those things. The difference between those scenarios is proper documentation so that serious hobbyists can fully engage.
Richard, like everyone, I am extremely grateful for your contributions across every single aspect of DAZ Studio. The people you've guided to solutions over the years, myself included, are inumerable. But in this one regard, I feel that you could be a stronger proponent of this important cause, and that is what I am imploring you to become. Not as a personal favor for me, but for everyone. I don't want to argue, or to upset or offend anyone, I just want help in somehow improving the documentation. I believe that the first step to resolving the problem is not explaining, with counterfactual examples, that there really is no problem.
Cloth sim with pressure is needed, if this does that it would be cool. I made this comforter with Marvellous Designer, pins and draging the cloth around to "fold" it. You set negative pressure to the topside and positive to the bottom (depends on the normal direction). It's still the best cloth sim I've ever seen. Real-time performance and being able to drag the cloth around with that kind of time constraint is neccessary. I believe recent ZBrush versions now have this kind of cloth sim too.
I think dForce could really do with some kind of validation layer though, to alert the user to potential problems (start pose self-intersections, for example). You know, things likely to make it explode, which it seems to do a little too easily.
The bad part of Daz's C++ plugin's document is not the API part, is the quick start part.
The SDK document is very old and asks us to install very old version of Visual Studio. Many developers won't do that, they just want to use latest development tools. If a developer's other projects can work with latest dev tools, they won't install an old version just for Daz. So, if Daz' SDK can not work with VS 2022 and no document about how to make it work, they just left.
As I searched in forum, SDK doesn't work with VS 2019 or later any more. And no tutorial about how to make it work with VS 2022. I won't install VS 2010 just for Daz, so like other developers, I just left.
Since VS 2022 won't work, I think Daz need a new quick start document for SDK dev, based on VS Code 2023+thrid part c++ compiler, step by step for windows. It doesn't need to be added into SDK_Document.zip file. It can be just a post and set to top at SDK dev forum.
Let's not talk too much about this here. This topic should be in SDK dev forum. But I think you get the point.
I wonder what VWD Cloth and Hair uses?
My friend Philemo made a Daz Studio (and a Carrara) bridge for that using the SDK
It's fast and does soft-body. Powerful and easy to use too. I use it every day, but also enjoy using dForce
This is VWD in Carrara - cloth only. The hair is Carrara's dynamic hair
It's so easy to use, in this demonstration I was converting conforming clothing into props and letting VWD Cloth and Hair do the rest
I ever bought VWD but it cannot be run in current DAZ versions and the authors stopped the development and update long time ago....
I run it every day. What do you mean?
EDIT: it does require a plugin by Philemo - the DS bridge
If I remembered correctly, I was not able to use it starting from 4.16 where I encountered DAZ crash, VWD hung up there with no response, etc. Then I totally gave it up after lots of tries...
I cannot either, it crashes sending back to DAZ studio but there was an updated version I believe Dartanbeck is using you need to buy again
I am using V.2
I have V.1 but have never tried it
I bougth it, VWD V2.2, on the Christmas Day of 2019 ~ You still can run it well in Daz 4.2x ?
This year marks my 41st year of programming, a lot of which was in C++, yet it took me nearly a week to get the SDK installed, setup and working about 4-5 years ago. I managed to figure out most (not all) of what I needed and it was such a painful process I just stick to DAZ Script now, which gives me Mac compatibility for "free". Anything I can't do in DAZ Script is just not worth doing and there are at least a dozen great ideas on the shelf because of this.
A better system than DForce would be a GOD send imo.
Wow, 41 years!
I just started to learn DAZ script. It seems it's a right choice and direction as per what you mentioned above! I ever learnt Pascal in college many many years ago but have nearly zero knowledge & exp. in C++. The only development software I ever used is Delphi.
I wrote a DAZ script several months ago by self learning, to switch cameras in Viewport with a shortcut key which is very useful though the coding might be poor
I noticed in a comment elsewhere VWD cloth changes topology. That's very bad in software that relies heavily on morphs. I would typically run a sim then export the meshes to make morphs at various points in the anim rather than keeping the entire sim on the timeline all the time. If you can't do that with whatever cloth impl there is, it rules out a lot of use cases.
There has been an update to use CMake, probably after you went through that. It does, I am told, include step-by-step instructions though I have never managed to get around to installing a working development environment.
Did you maybe move locations of things around, perhaps? I don't get it.
I have my main VWD install folder in the root of a drive. I even make custom settings for soft-body. It just works.