Daz 3D Introduces dForce Physics Engine

1252628303141

Comments

  • y3kmany3kman Posts: 765
    Has anyone managed to overcome exploding garments yet, trying a genesis coat on gen3 (ok a bit of stretch there) but the sleeves explode even when I turn off the simulation on the sleeves.

    Which coat?

    The age of the clothes doesn't tell you the success rate of the sim. I have success with old clothes by simply adding the dforce modifier with no additional weight node and surface settings. Some of the dForce-ready clothes sold at the store still explode if you put your character in certain poses. Geometry, collisions, and poses factor in to the sim.

  • y3kman said:
    Has anyone managed to overcome exploding garments yet, trying a genesis coat on gen3 (ok a bit of stretch there) but the sleeves explode even when I turn off the simulation on the sleeves.

    Which coat?

    The age of the clothes doesn't tell you the success rate of the sim. I have success with old clothes by simply adding the dforce modifier with no additional weight node and surface settings. Some of the dForce-ready clothes sold at the store still explode if you put your character in certain poses. Geometry, collisions, and poses factor in to the sim.

    It's the coat from this bundle https://www.daz3d.com/ms-magic-for-genesis-female
  • carrie58 said:

    Anyone know what's going on here? I have a G3F figure which uses Cayman Studios V4 legacy UV mappings for G3F. The skirt drapes ok, but does not collide with the hip and leg somehow, which results almost in a breach of modesty for the poor girl. Delete the all legacy surfaces, which I think are implemented as LIEs (?), and the skirt draps just fine, as expected. I've tried selecting the legacy items and adding a 'static surface' modifier - makes no difference. This happens with a range of clothing, not just this, so it's clearly some sort of systemic issue with this legacy UV mapping approach... The figure and skirt positions and all settings are identical for both these simulations - the *only* difference is that I deleted the Cayman legacy items in the latter drape - and it works fine... 

    CaymanStudio Legacy UV's use geografts and it was said somewhere there is a issue when using geografts .......

    Yes, this is said to be fixed in a later build but you mightt ry switching to the Geometry Editor or Node Weightmap Paintbrush tool while draping (it may look funny as it shows the hidden geometry, but you can switch to another tool to render).

    Thanks. There is a workaround, at least in this case, which is simply to delete the geografts, do the drape, then restore the figure from a previous save (or maybe even with 'undo' - haven't tried that). It works, just a bit clunky. They are only for UV mapping, so the shape is identical.

    Better workaround: Select the weight map painting tool before you run your sim.

  • Hanabi said:
    carrie58 said:

    Anyone know what's going on here? I have a G3F figure which uses Cayman Studios V4 legacy UV mappings for G3F. The skirt drapes ok, but does not collide with the hip and leg somehow, which results almost in a breach of modesty for the poor girl. Delete the all legacy surfaces, which I think are implemented as LIEs (?), and the skirt draps just fine, as expected. I've tried selecting the legacy items and adding a 'static surface' modifier - makes no difference. This happens with a range of clothing, not just this, so it's clearly some sort of systemic issue with this legacy UV mapping approach... The figure and skirt positions and all settings are identical for both these simulations - the *only* difference is that I deleted the Cayman legacy items in the latter drape - and it works fine... 

    CaymanStudio Legacy UV's use geografts and it was said somewhere there is a issue when using geografts .......

    Yes, this is said to be fixed in a later build but you mightt ry switching to the Geometry Editor or Node Weightmap Paintbrush tool while draping (it may look funny as it shows the hidden geometry, but you can switch to another tool to render).

    Thanks. There is a workaround, at least in this case, which is simply to delete the geografts, do the drape, then restore the figure from a previous save (or maybe even with 'undo' - haven't tried that). It works, just a bit clunky. They are only for UV mapping, so the shape is identical.

    Better workaround: Select the weight map painting tool before you run your sim.

    You can also select the geograft and exclude it from the simulation.

  • I'm able to get dforce to work when I use clothes for Genesis 3 on a Genesis 8 character, but it does not work when I try to use clothes for G3 on a G3 character.  What am I doing wrong??

  • HeraHera Posts: 1,955

    I managed to get it to work and simulate a few primitives, creating tablecloths and such things, but my first try at outfit was unsucessful. I tried the Artemis Moon dress for G3F and added a modifier dynamic surface which was all tat worked, and it simulated something all right, but when the simulation was done nothing had happened with the dress, it looked more or less just like before.

    And I don't see anything that lets me modify parts of the dress, save for the regular old functions already in the dress. This dress has long sleeves which are most of the time useless because they conform to the arms not to the gravity and thus they are levitating. I had wanted to see if there was a way to fix these.  

     

  • Hanabi said:
    carrie58 said:

    Anyone know what's going on here? I have a G3F figure which uses Cayman Studios V4 legacy UV mappings for G3F. The skirt drapes ok, but does not collide with the hip and leg somehow, which results almost in a breach of modesty for the poor girl. Delete the all legacy surfaces, which I think are implemented as LIEs (?), and the skirt draps just fine, as expected. I've tried selecting the legacy items and adding a 'static surface' modifier - makes no difference. This happens with a range of clothing, not just this, so it's clearly some sort of systemic issue with this legacy UV mapping approach... The figure and skirt positions and all settings are identical for both these simulations - the *only* difference is that I deleted the Cayman legacy items in the latter drape - and it works fine... 

    CaymanStudio Legacy UV's use geografts and it was said somewhere there is a issue when using geografts .......

    Yes, this is said to be fixed in a later build but you mightt ry switching to the Geometry Editor or Node Weightmap Paintbrush tool while draping (it may look funny as it shows the hidden geometry, but you can switch to another tool to render).

    Thanks. There is a workaround, at least in this case, which is simply to delete the geografts, do the drape, then restore the figure from a previous save (or maybe even with 'undo' - haven't tried that). It works, just a bit clunky. They are only for UV mapping, so the shape is identical.

    Better workaround: Select the weight map painting tool before you run your sim.

    You can also select the geograft and exclude it from the simulation.

    Sorry, did I miss this somewhere? How can I select the geograft and exclude it from the simulation?

  • DaWaterRatDaWaterRat Posts: 2,882
    Hera said:

    I managed to get it to work and simulate a few primitives, creating tablecloths and such things, but my first try at outfit was unsucessful. I tried the Artemis Moon dress for G3F and added a modifier dynamic surface which was all tat worked, and it simulated something all right, but when the simulation was done nothing had happened with the dress, it looked more or less just like before.

    And I don't see anything that lets me modify parts of the dress, save for the regular old functions already in the dress. This dress has long sleeves which are most of the time useless because they conform to the arms not to the gravity and thus they are levitating. I had wanted to see if there was a way to fix these.  

     

    Simple thing to check that I've slipped on myself - Check if it was Dynamic Surface or Dynamic Surface Add On - the latter acts a bit different.  I just tested the Artemis Moon outfit myself, and the results are not TOS compliant, because the buckles aren't welded to the dress itself ;D

  • I'm able to get dforce to work when I use clothes for Genesis 3 on a Genesis 8 character, but it does not work when I try to use clothes for G3 on a G3 character.  What am I doing wrong??

    I posted this before and don't seem to get an answer...

  • DaWaterRatDaWaterRat Posts: 2,882

    I'm able to get dforce to work when I use clothes for Genesis 3 on a Genesis 8 character, but it does not work when I try to use clothes for G3 on a G3 character.  What am I doing wrong??

    I posted this before and don't seem to get an answer...

    Can you give more information?  There's not enough there to figure out what to tell you.  Of the top of my head, there's no reason why G3 clothing should work on G8 but not on G3

    What clothes are you using, what are your simulation surface settings... um...

  • L'AdairL'Adair Posts: 9,479

    I'm able to get dforce to work when I use clothes for Genesis 3 on a Genesis 8 character, but it does not work when I try to use clothes for G3 on a G3 character.  What am I doing wrong??

    I posted this before and don't seem to get an answer...

    Can you give more information?  There's not enough there to figure out what to tell you.  Of the top of my head, there's no reason why G3 clothing should work on G8 but not on G3

    What clothes are you using, what are your simulation surface settings... um...

    As DaWaterRat suggests, it could be product specific. I'm working on a series of renders using G3F, and some of the more extreme characters for G3F, with the Summer Flirt outfit. I'm only draping the "sweater" though.

  • davidcaputokeenedavidcaputokeene Posts: 131
    edited November 2017
    marble said:

    I've just looked at the release announcement and they talk about OpenCL using the GPU or CPU so I'm interested to know if the GPU would help with sim speed - I have a GeForce GTX 1070.

    It's either/or - you pick which device to use in the Advanced tab of the Simulation Settings pane. CPU does need the Intel OpenCL driver (which, reprotedly, works on AMD CPUs too).

     

    I do not seem to have any other option than NVIDIA in the simulation Advanced engine tab. I have all the option appearing though in Render Settings. Is there some action or procedure that I'm missing?

    There's no real relationship between the list of devices in Render Settings for Iray (CPU and GPUs with CUDA) and that in Simulatin Settings(OpenCL devices). AMD GPUs wil appear in Simulation Settings but not in Redner Settings, CPUs will always appear in Render Settings but require a driver that is not isntalled by default to appear in Simulation Settings. There is a link to the Intel CPU driver in the dForce Start Here thread linked above.

    I use the link to get Intel OpenCL runtime and get " HD Graphics driver is installed.Uninstall it before running OpenCL runtime for Intel Core etc." I uninstalled Intel HD graphics driver from 'remove applications' (it did not appear in device manager under display adaptors - only NVIDIA  GeForce GTX 960 shows there. - but still get the error 'HD graphics driver must be uninstalled. etc'  What am I missing please.

    Post edited by davidcaputokeene on
  • marble said:

    I've just looked at the release announcement and they talk about OpenCL using the GPU or CPU so I'm interested to know if the GPU would help with sim speed - I have a GeForce GTX 1070.

    It's either/or - you pick which device to use in the Advanced tab of the Simulation Settings pane. CPU does need the Intel OpenCL driver (which, reprotedly, works on AMD CPUs too).

     

    I do not seem to have any other option than NVIDIA in the simulation Advanced engine tab. I have all the option appearing though in Render Settings. Is there some action or procedure that I'm missing?

    There's no real relationship between the list of devices in Render Settings for Iray (CPU and GPUs with CUDA) and that in Simulatin Settings(OpenCL devices). AMD GPUs wil appear in Simulation Settings but not in Redner Settings, CPUs will always appear in Render Settings but require a driver that is not isntalled by default to appear in Simulation Settings. There is a link to the Intel CPU driver in the dForce Start Here thread linked above.

    I use the link to get Intel OpenCL runtime and get " HD Graphics driver is installed.Uninstall it before running OpenCL runtime for Intel Core etc." I uninstalled Intel HD graphics driver from 'remove applications' (it did not appear in device manager under display adaptors - only NVIDIA  GeForce GTX 960 shows there. - but still get the error 'HD graphics driver must be uninstalled. etc'  What am I missing please.

    I don't know, it sounds like a possible conflict between the two Intel drivers - though if so it's odd that the previous Intel GOU driver wasn't available to DS.

  • marble said:

    I've just looked at the release announcement and they talk about OpenCL using the GPU or CPU so I'm interested to know if the GPU would help with sim speed - I have a GeForce GTX 1070.

    It's either/or - you pick which device to use in the Advanced tab of the Simulation Settings pane. CPU does need the Intel OpenCL driver (which, reprotedly, works on AMD CPUs too).

     

    I do not seem to have any other option than NVIDIA in the simulation Advanced engine tab. I have all the option appearing though in Render Settings. Is there some action or procedure that I'm missing?

    There's no real relationship between the list of devices in Render Settings for Iray (CPU and GPUs with CUDA) and that in Simulatin Settings(OpenCL devices). AMD GPUs wil appear in Simulation Settings but not in Redner Settings, CPUs will always appear in Render Settings but require a driver that is not isntalled by default to appear in Simulation Settings. There is a link to the Intel CPU driver in the dForce Start Here thread linked above.

    I use the link to get Intel OpenCL runtime and get " HD Graphics driver is installed.Uninstall it before running OpenCL runtime for Intel Core etc." I uninstalled Intel HD graphics driver from 'remove applications' (it did not appear in device manager under display adaptors - only NVIDIA  GeForce GTX 960 shows there. - but still get the error 'HD graphics driver must be uninstalled. etc'  What am I missing please.

    I don't know, it sounds like a possible conflict between the two Intel drivers - though if so it's odd that the previous Intel GOU driver wasn't available to DS.

    Problem solved running DDD clean uninstall on Intel drivers. Apologies for bother.

  • Question, and I apologize if this has been covered already.

    It appears that Dynamic Surface objects tend to "fall" towards bigger objects, rather than "down." Is this correct?

    I am basing this observation on a primitive cube that I added the Dynamic Surface to (to simulate a sheet). With a small object below it. I left everything at the defaults and let it simulate. The "cloth" acted as if it was being acted on from the left by an invisible wind. Then shot off into the sky.

    After a little more experimentation, I decided to put a primitive sphere below the small object. Now the "sheet" dropped down towards the smaller object like I initially expected it to.

    Is this a correct observation of mine? Or do I have a different issue going on here?

  • Question, and I apologize if this has been covered already.

    It appears that Dynamic Surface objects tend to "fall" towards bigger objects, rather than "down." Is this correct?

    I am basing this observation on a primitive cube that I added the Dynamic Surface to (to simulate a sheet). With a small object below it. I left everything at the defaults and let it simulate. The "cloth" acted as if it was being acted on from the left by an invisible wind. Then shot off into the sky.

    After a little more experimentation, I decided to put a primitive sphere below the small object. Now the "sheet" dropped down towards the smaller object like I initially expected it to.

    Is this a correct observation of mine? Or do I have a different issue going on here?

    Thatbsounds odd, and doesn't match my experience. Are you sure you didn't have a wind node in the scene?

  • Jason GalterioJason Galterio Posts: 2,562
    edited November 2017

    Question, and I apologize if this has been covered already.

    It appears that Dynamic Surface objects tend to "fall" towards bigger objects, rather than "down." Is this correct?

    I am basing this observation on a primitive cube that I added the Dynamic Surface to (to simulate a sheet). With a small object below it. I left everything at the defaults and let it simulate. The "cloth" acted as if it was being acted on from the left by an invisible wind. Then shot off into the sky.

    After a little more experimentation, I decided to put a primitive sphere below the small object. Now the "sheet" dropped down towards the smaller object like I initially expected it to.

    Is this a correct observation of mine? Or do I have a different issue going on here?

    Thatbsounds odd, and doesn't match my experience. Are you sure you didn't have a wind node in the scene?

    Positive. I have been having odd results like that on a number of scenes... Which made me strip things down to see what might be going on. These are the steps I went through, with more detail.

    1. New scene.
    ​2. Create Primitive Cube. Size: 1M, Divisions: 20.
    ​3. Increase the cube's YTranslate to 100, lifting it off the ground.
    4. Reduce the cube's Y Scale to 1% to appear like a sheet.
    ​5. Edit > Object > Geometry > Add Dforce: Dynamic Surface.
    ​6. Create Primitive Plane.Size: 200M, Divisions: 50.
    ​7. Change Plane's Diffuse to Green for contrast.
    8. Checked Simulation settings and Surface settings. Made sure all of them were default.

    ​9. Ran Simulate. Cube goes upwards, away from Plane. 

    I then did these steps, which worked the last time:
    10. Cleared Simulation.
    ​12. Added Primitive Sphere.Diameter: 1M, Segments: 100, Sides: 100.
    ​13. Changed Sphere Diffuse to Red for contrast.
    14. Reduced the sphere's Y Translate to -75 so that it is peeking through the plane.
    ​15. Ran simulation.

    At this point, during my last experiments, the cube dropped to the plane. This time it is still going upwards. So I am experimenting to see what I can change to get the right behavior to occur.

    Adding that I cut the simulation early, after only a few seconds, for that screen capture. If I let it run any further, then the cube shoots off into the stratosphere.

    I did notice that I have a GeForce driver update I can install, so I am downloading that right now. I generally don't update unless I am experiencing errors. I don't think that this should make a difference, since it does work properly in some instances.

    I also should try rebooting as well. I noticed yesterday that there was odd behavior if I did too many simulations without a reboot. Possibly a memory leak?

    ADDING:

    Downloaded and updated drivers. Rebooted. Loaded the previous scene and ran simulate. Still flying up into the air. Grrr.

    Stage 1.jpg
    858 x 761 - 69K
    Stage 2.jpg
    858 x 761 - 71K
    Post edited by Jason Galterio on
  • Jason GalterioJason Galterio Posts: 2,562
    edited November 2017

    It appears that the issue I am having is specific to primitives.

    I tried a couple of different things with no luck.
    ...moving the sphere closer to the cube.
    ​...increasing the size of the sphere.
    ​No luck.

    I deleted the sphere and added a table, thinking that maybe it was the "weight" of the object. Possibly a more complex object would exhibit more gravity. No luck.

    I deleted the cube and added a rug from the same set as the table. I applied the Dforce modifier. Ran the simulation. Now it is working.

    It is curious that the rug interacts properly with the Plane. I expected it to have issues there.

    I merged the modified scene with the original scene, restoring the cube and sphere primitives. I was curious what would happen then.

    The rug continued to fall and interact properly. The box continued to float up into space.

    I then deleted the table and ran the simulation again. This time the rug passes through the sphere, but still interacts with the plane.

    Which is really odd. Since I would have expected it to interact with the sphere now.

    Stage 2-1.jpg
    870 x 758 - 78K
    Stage 2-2.jpg
    870 x 758 - 84K
    Stage 2-3.jpg
    870 x 758 - 73K
    Post edited by Jason Galterio on
  • Jason GalterioJason Galterio Posts: 2,562
    edited November 2017

    Last experiment. I wanted to see how the rug would interact with other primitives to trouble shoot the situation. So I arranged one of each.

    I then ran the simulation and was again surprised to find that the rug interacted with all of the other primitives, except the sphere. At the very least I expected the cube to be ignored.

    Stage 3-1.jpg
    870 x 758 - 72K
    Stage 3-2.jpg
    870 x 758 - 82K
    Post edited by Jason Galterio on
  • PhilWPhilW Posts: 5,144

    I am guessing that the primitive sphere in Daz Studio is a geometrically defined object (ie, it is defined by a centre point and a radius) and therefore does not have vertices and polygons as such. And as that is what dForce needs to be able to calcaulte the interactions, that is why it is ignoring the sphere and not the other objects.

  • Your plane isn't terally as plane - its edges have cery dense geometry, each loop separated by 0.5mm. I suspect its the interaction of those tightly packed loops that is driving the odd behaviour.

  • Oso3DOso3D Posts: 14,957

    The sphere actually does have a mesh, but it's incredibly uneven and I find that can do weird things with dynamic stuff.

    I've found it useful to make retopo spheres with more even meshes for draping and other purposes.

  • Jason GalterioJason Galterio Posts: 2,562
    edited November 2017

    I think I get what you're all referring to...

    The original "sheet" I was using was a smooshed Cube. The vertical faces of that cube still has as much geometry as the flat horizontal faces (the top and bottom.of the "sheet"). All that geometry is smashed into a tiny area causing the calculations to go haywire.

    I can sort of confirm this as I tried the "sheet" using a plane. That descended properly and draped as expected.

    I also was able to get the sphere to interact properly by increasing the sides to it. I would have thought that 100 sides would be sufficient, but apparently not.

    Post edited by Jason Galterio on
  • Richard HaseltineRichard Haseltine Posts: 99,293
    edited November 2017

    I just did a test, made two cubes in modo - both 1m on a side, one with 20 vertical divisions and one with 2 (horizontal divisions are 20). Loaded them in DS and treated them as you treated the primitive (squishing and moving up). As you can see, the 20 division cube has flown off while the two division cube draped (with a bit of ugliness).

    The difference divisions make.JPG
    852 x 926 - 63K
    Post edited by Richard Haseltine on
  • I just did a test, made two cubes in modo - both 1m one a side, one with 20 vertical divisions ans one with 2. Loaded them in DS and treated them as you treated the primitive (squishing and moving up). As you can see, the 20 division cube has flown off while the two division plane draped (with a bit of ugliness).

    Interesting. Thanks for trying that...  Can I impose on you to try one more experiment?

    I am not sure if this is even possible, but can you create a cube where the sides have very few divisions and the top and bottom are more detailed?

    I am curious if that would make the "fly away" behavior disappear.

  • I'm not sure what you mean - tesselate the top and bottom but lose not only the horizontal but also the vertical divisions on the sides? I'm pretty sure that would fail, dForce wants quads or triangles but if that is what you mean the sides would become ngons with up to forty vertices.

  • Sort of. Apologize for my layman speak but it's been many many years since I've modelled.

    What I was trying to describe is a cube where the sides are made up of simple planes. The top and bottom would be more subdivided. Though I imagine that would create issues with the "welding" along the top and bottom edges?

  • Jason GalterioJason Galterio Posts: 2,562
    edited November 2017

    All my experiments and images might seem like crazy, irrelevent nonsense, so I thought I would show what I was trying to do...

    This is a TerraDome 3 landscape with a narrow plane draped dynamically down it. It's a very crude example of where I was experimenting; in this case to create a waterfall...  But equally useful for creating paths or tree lines, etc.

    Waterfall.jpg
    700 x 560 - 464K
    Post edited by Jason Galterio on
  • Sort of. Apologize for my layman speak but it's been many many years since I've modelled.

    What I was trying to describe is a cube where the sides are made up of simple planes. The top and bottom would be more subdivided. Though I imagine that would create issues with the "welding" along the top and bottom edges?

    Yes, either welding if the sides had only the corner vertices or it would create a huge ngon whch would ber likely to cause draping issues of its own.

  • ChoholeChohole Posts: 33,604

    Your plane isn't terally as plane - its edges have cery dense geometry, each loop separated by 0.5mm. I suspect its the interaction of those tightly packed loops that is driving the odd behaviour.

    heh      love this explanation


    If the vertical edges on the sides of the squished cube are shorter than the Collision Offset for the surface that those edges participate in, the collision/repulsion iterations are going to move the second-order neighbors away from each other (and generate a certain amount of force/energy), in order to satisfy the specified offset. On the subsequent sim iteration, the engine is going to attempt to resolve the edge length of those (now stretched) edges and generate a certain amount/direction velocity. The subsequent collision/repulsion iterations are going to repeat their previous task... so on and so forth. All of that built up energy must go somewhere... so off it flies.

     

Sign In or Register to comment.