14-06-2018, 08:45 AM
(This post was last modified: 14-06-2018, 08:51 AM by josemendez.)
Hi there!
Can't reproduce this, to me it seems like there is a dummy particle at the beginning indeed. The only thing that could cause this is your rope spline having multiple control points overlapping. I'm not 100% sure about this though, if you don't mind me taking a look at your scene I could tell for sure.
Again, can't reproduce this. I assume we are talking about manually placed pin constraints (using the inspector), not added programmatically right? Note that you can add pin constraints to inactive particles using the API, and then it behaves in a similar way. Ropes have a small pool of inactive particles, used when the rope is torn or changes its length (via a cursor component). These particles can have constraints applied to them, but otherwise are completely ignored by the solver until they are activated for some reason.
Completely agree with you on this one. 3.5 is currently undergoing revision at the store, and it adds support for multiple colliders per object (among other things). It is basically a polish-oriented update, not much groundbreaking new stuff.
It's a huge asset though, with lots of functionality that spans a lot of areas (native plugins, shaders, serialization, physics, custom editors, etc), and being a one-man enterprise makes it difficult to get ground covered fast. Not that I'm not aware of the ugly spots: so-so documentation, little to no hand-holding when using the editor, very few error/warning messages, just to name a few. It's just that progress in these aspects is slow, but I assure you work is being done now that most basic stuff works. Also, upcoming Unity versions break existing things that need to be fixed or re-done, so there's many balls to juggle at once. Getting better at it, I think.
(13-06-2018, 09:08 PM)fahyc Wrote: First, there seems to be some sort of dummy particle on these ropes at the origin. Whenever I try to pin the particle at the origin of the rope, (local position 0,0,0) the particle will just not have the pin reference when I hit play. It will be back when I hit stop. I figured out that to fix this I need to simulate the rope for a few steps, select the particle at the origin end of the rope then, and then reset the rope and apply pin constraint changes to that previously selected particle.
Can't reproduce this, to me it seems like there is a dummy particle at the beginning indeed. The only thing that could cause this is your rope spline having multiple control points overlapping. I'm not 100% sure about this though, if you don't mind me taking a look at your scene I could tell for sure.
(13-06-2018, 09:08 PM)fahyc Wrote: Second, it seems like some pin constraints are just ignored by the solver. When I hit play they will still be there in the inspector, and if I check visualize the blue dotted line will connect to the correct spot on the object, but the rope just acts as if it isn't there. The pin constraint on the other end of the rope still works fine. This is one I haven't found a reliable workaround for. Sometimes creating a new rope from scratch works. I think breaking the prefab instance and then re-applying worked once for this bug as well, but it may have just been the previous bug and I know it isn't a reliable solution. Do you have any insight about what might cause this to happen?
Again, can't reproduce this. I assume we are talking about manually placed pin constraints (using the inspector), not added programmatically right? Note that you can add pin constraints to inactive particles using the API, and then it behaves in a similar way. Ropes have a small pool of inactive particles, used when the rope is torn or changes its length (via a cursor component). These particles can have constraints applied to them, but otherwise are completely ignored by the solver until they are activated for some reason.
(13-06-2018, 09:08 PM)fahyc Wrote: Finally, and this is more of a comment, I'm not a fan of your lack of error messages. For example I see in your Kanban that you have been planning to add support for multiple colliders since last October. The fact that you didn't support that was news to me when I finally stumbled on the board after hours of tinkering trying to figure out why my object was exploding and crashing unity. I'm sure you'd get a lot fewer irritable developers complaining about ease of use if the black box sometimes explained what was going wrong.
Completely agree with you on this one. 3.5 is currently undergoing revision at the store, and it adds support for multiple colliders per object (among other things). It is basically a polish-oriented update, not much groundbreaking new stuff.
It's a huge asset though, with lots of functionality that spans a lot of areas (native plugins, shaders, serialization, physics, custom editors, etc), and being a one-man enterprise makes it difficult to get ground covered fast. Not that I'm not aware of the ugly spots: so-so documentation, little to no hand-holding when using the editor, very few error/warning messages, just to name a few. It's just that progress in these aspects is slow, but I assure you work is being done now that most basic stuff works. Also, upcoming Unity versions break existing things that need to be fixed or re-done, so there's many balls to juggle at once. Getting better at it, I think.
(13-06-2018, 09:08 PM)fahyc Wrote: Oh, one more thing, when I simulate the rope in edit mode (cool feature by the way) it almost always ends up either crashing unity or freezing it after a few seconds. I can step through it without problems - just the continuous playing that seems to be the issue.Do you have the editor crash log around?