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
This is an awesome tool and I'm really glad I picked it up! I love putting glowy light strings everywhere IRL, but I've spent a lot of time fighting with them in 3D. :D
And for folks who own Instancify and Alienator, this is a fun way to make some Strings of Things.
I played with it with Alienator, but got very frustrated selecting each and every light. Instancify!!!!! Yes, I have it too. I'll give that a try first next time. Thanks for the tip.
How can I keep the lights attached to the string? The rigid follow nodes are straying quite a ways away and leaving my lights hanging in space. I haven't found any settings that keep them attached.
Very cool @barbult!
I am glad you like it. And thank you for sharing the tip. That looks great!
I am not sure. I will see if I can find out anything.
@esha kindly guided me to an answer:
The thing with rigid follow nodes (RFNs) is that they move in relation to the center of the poly they are attached to. When that poly shifts, tilts or twists (which it is likely to do during the dForce sim) the center of the poly shifts, too, and does not match the original position anymore. As a result, the lights can end up either too close or too far away from the string.
The only solution (except re-positioning them manually) is to use a higher number of segments. On short polygons the shift of the center is much less noticeable. The downside is that generating and simulating the string will take longer.
I tried it and it worked fine, as far as the RFNs are concerned. I was able to replicate the issue and using more segments solved the problem. One thing I ran into, though: The lights are set to be visible in the simulation and that creates dForce explosions. For some reason that happens only with a high number of segments, and that's why I didn't catch that when I tested it before release. The strings I created were shorter and with less segments so I didn't run into this problem. Users can fix it on their end by selecting all the light globes and then going to Parameters > Display > Simulation > Visible in Simulation OFF. They can select all the RFNs, too, which makes the bulk selection easier; they don't have to pick out only the lights.
So that answers your question!
I am divided on whether to update the script to make the lights not visible to the simulation. I imagine the lights may need to be visible in some simulations. Maybe I will make a couple presets to turn that on or off.
Is the increased density also generating spring-length warnings, before the cimulation actually runs? It may be a combination of that pumping extra "energy" into the sim and the light-collisions that are causing the explosions, rather than either on its own. (I do have the set, but haven't played with it yet to test this.) If that is the case then lowering the offset value, so it is smaller than the reduced edge-length, may also be a way to stop the explosions.
Making the LightGlobes and RFNs not visible to simulation causes the lights to fall through the surfaces they should have collided with, like the ground. So, I don't think you should make them not visible to simulation by default.
Edit: Maybe not visible to simulation is not the cause of falling through the ground. Maybe it is just the rotation (spiral) around the string. The string is on the ground, but some lights are rotated fully or partially beneath the ground, even when they are visible to simulation. Maybe the combination of spiral and not visible to simulation is the worst case. More experimentation is needed, I guess.
With a higher number of segments, I am getting explosions of the string, but no spring warnings. I think the RFNs are causing the explosion with the string. If I turn off visible in simulation on just the RFNs, the explosions go away.
I turned off spiral, but I still get lights poking through the ground.
Should the scripts remember my choice of Single/Multicolor/Multicolor (Random)/Multicolor (Interpolated)? It seems to remember other settings between sessions, but it always goes back to Multicolor each time I run a script. It would be nice if all settings were remembered, so I can more easily create multiple strings with the same settings.
I think I should stop posting my experiment results. The results are too inconsistent. What helps once, doesn't work the next time.
I have found the lights can penetrate the ground even when falling from a height. Using the higher fidelity sim settings can help.
It is supposed to be remembering that. I will have to investigate.
I tried Best and Viewport and that did not help. Are there other "high fidelity" simulation settings you would suggest? Maybe the product could include some simulation settings presets, if there is a setting that works best.
Thank you!
I'm trying to understand Light Offset.
Top view. Max width string. Min width lights. No spiral on lights. String changed to Base Resolution. No simulation was done. Notice the RFNs are all centered and the lights ARE vertically aligned.
Top view. Max width string. Min width lights. No spiral on lights. String SubD 3 as set by script. No simulation was done. Notice some RFNs and lights are misplaced.
Front view render. Max width string. Min width lights. No spiral on lights. SubD 3 as set by script. No simulation was done. Notice the lights are not all aligned. Look at the large distance between the string and the lights.
Basically I mean the Subframe stuff. As far as the lights not penetrating the floor, I have had good luck with upping the Quality settings (FPS, Subframes, Iterations Per Subframe) and the Collision Iterations per subframe. I am unsure which made the biggest difference though.
When I started, the light offset was just a constant in the constants file. I struggled a LONG time with making the String Lights not explode during simulation and this is something that I thought mattered. Late in the dev process, I decided to give users the control of the light offset. Not mentioning the units was an afterthought. I have corrected the hint.
This is good information. I went with less explosions over visual fidelity (especially since most string lights will be the christmas types and won't be used for extreme closeups) and the light offset was created to address this. It is unfortunate that SubD makes the lights farther from the lights but it looks so much better for the string.