We will be out of office from December 23th to January 7th. During this time we'll check the forums less often, we'll be back at full throttle soon. Take care, Merry Christmas!
I feel like this is a really basic question, but having issues getting it to work.
I'm working on a personal project about sailing, and using Obi cloth + rope to handle the, well, cloth and rope.
I'm having good results, but have been unable to get multiple ropes to work as desired. I can copy a rope any number of times, but editing the spline will reflect the changes to all other ropes that it was copied from. If I create a new rope with a new blueprint, it appears to work, but when running any obi particle attachments are seemingly ignored, and the rope will fall through the scene and cause everything to explode.
I'm currently working around this by altering rope lengths/positions after runtime, but this feels cumbersome -- and I'm sure I'm missing something pretty basic. Essentially I want multiple ropes that have identical blueprints/solvers, but varying lengths and positions.
Pic shows the idea. All the ropes behave identically, but have different lengths and particle attachment points, been unable to set this up pre runtime.
28-10-2022, 07:49 AM (This post was last modified: 28-10-2022, 07:49 AM by josemendez.)
(27-10-2022, 09:05 PM)MEPETAMINALS Wrote: I'm having good results, but have been unable to get multiple ropes to work as desired. I can copy a rope any number of times, but editing the spline will reflect the changes to all other ropes that it was copied from.
Hi!
Yes, this is the intended behavior: blueprints are containers for particles and constraints, that define how an actor (in this case a rope) looks. Two ropes sharing the same blueprint will be identical, if you modify one of them, all ropes sharing the same blueprint will change. Same for cloth, softbodies, etc. See:http://obi.virtualmethodstudio.com/manual/6.3/ropesetup.html
Quote:When editing a path, you're modifying the rope's blueprint. Modifications will be applied to all ropes/rods sharing the same blueprint. This can speed up the workflow a lot, but can also destroy previous work if you're not careful! If you want to use an existing blueprint as a base to create a new one, duplicate it.
(27-10-2022, 09:05 PM)MEPETAMINALS Wrote: If I create a new rope with a new blueprint, it appears to work, but when running any obi particle attachments are seemingly ignored, and the rope will fall through the scene and cause everything to explode.
Make sure that the attachments reference the new control points. Even if their names are the same, the actual particles being referenced may change if you move the control points around. In this case the attachment will be ignored and an error message will appear in the console.
If you duplicate the rope together with its attachment components and then set a new blueprint, make sure you select the new control points in the attachments, even if they keep the same names since they're still referencing the control points in the old blueprint.
(27-10-2022, 09:05 PM)MEPETAMINALS Wrote: Essentially I want multiple ropes that have identical blueprints/solvers, but varying lengths and positions.
Ropes having identical blueprints will be identical at startup. You can later change their length using cursors, but that's all that's allowed.
Keep in mind that for cloth and ropes to interact with each other, they all have to be included in the same solver. Having one solver per rope won't work in this case.
Yes, this is the intended behavior: blueprints are containers for particles and constraints, that define how an actor (in this case a rope) looks. Two ropes sharing the same blueprint will be identical, if you modify one of them, all ropes sharing the same blueprint will change. Same for cloth, softbodies, etc. See:http://obi.virtualmethodstudio.com/manual/6.3/ropesetup.html
Make sure that the attachments reference the new control points. Even if their names are the same, the actual particles being referenced may change if you move the control points around. In this case the attachment will be ignored and an error message will appear in the console.
If you duplicate the rope together with its attachment components and then set a new blueprint, make sure you select the new control points in the attachments, even if they keep the same names since they're still referencing the control points in the old blueprint.
Ropes having identical blueprints will be identical at startup. You can later change their length using cursors, but that's all that's allowed.
Keep in mind that for cloth and ropes to interact with each other, they all have to be included in the same solver. Having one solver per rope won't work in this case.
kind regards
Appreciate the response, fantastic product btw.
So if I'm understanding correctly, the proper workflow for something like this would be a single solver applied at a parent level to everything that it controls. I.e. the boat would have a single solver for all sails, ropes, flags, etc. Then each unique element would have it's own blueprint?
That must be where I went wrong, as I followed the basic tutorials separately, then combined them, so I currently have two solvers in the scene, one for the cloth, one for the rope.
(28-10-2022, 04:01 PM)MEPETAMINALS Wrote: So if I'm understanding correctly, the proper workflow for something like this would be a single solver applied at a parent level to everything that it controls. I.e. the boat would have a single solver for all sails, ropes, flags, etc. Then each unique element would have it's own blueprint?
Correct. Actors in different solvers are completely independent from each other, since each solver does not "see" what's happening in other solvers. It is only aware of the actors it is in charge of simulating. See:
Quote:Three important things to remember about solvers:
1)They can be added to any GameObject in your scene and there can be more than one solver working simultaneously in the same scene.
2)Every actor needs to have a solver up its hierarchy in order to get updated and rendered. 3)Each solver is completely independent from other solvers. Therefore, actors being updated by different solver won't interact / collide with each other. Only actors in the same solver will react to each other.
