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
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.
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??
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.
Sorry, did I miss this somewhere? How can I select the geograft and exclude it from the simulation?
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 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.
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?
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.
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.
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.
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.
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.
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.
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).
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?
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.
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.
heh love this explanation