09-12-2023, 09:46 AM
(This post was last modified: 09-12-2023, 09:59 AM by josemendez.)
(08-12-2023, 11:57 AM)Christoffer Wrote: I have no idea if this is even remotely close to performant or even possible, but i know that the alternative of simulating the entire rope is not.
Especially as i am trying to use it as a cable with high stiffness (many Bending-constraint iterations).
Hi!
You should not be using iterations to impart high stiffness on the cable, using substeps is a lot more efficient. You'll get stiffer cable with far less substeps than you would using iterations. See:
http://obi.virtualmethodstudio.com/manua...gence.html
(08-12-2023, 11:57 AM)Christoffer Wrote: Result:
Every other run the original attachment works.
Every other run half the rope is attached way off and incorrectly.
You're creating and serializing a new particle group every time the game starts, then copying its particle indices to the attachment's current particle group at runtime. This is not only conceptually wrong (what's the point of using groups if you're copying particle indices individually?) but quite inefficient, a better approach in your case would be to just deal with individual particles manually (see below).
(08-12-2023, 11:57 AM)Christoffer Wrote: Seems almost as if the particle group is saved from the previous run.
It is, you're appending a new particle group to the blueprint every time the game starts and blueprints are saved to disk (since they're assets). You might want to create a temporary particle group yourself using CreateInstance. See: http://obi.virtualmethodstudio.com/manua...ments.html
Quote:If i create a new particle group on start and modify it time a new particle is added, then set that group as the attachment's particle group , the particles get attached but not to the correct transform. They just float in place as if attached to scene root.
Adding particles to an already attached group will just freeze them in place -since they stop getting their dynamic simulation updated- it will not calculate bind transforms for the new particles in the group. Groups are attached/detached as a single entity: attaching / detaching a group takes place when setting the ObiParticleAttachment's group or target, but not when adding / removing individual particles from the group. Typically you'd:
- Detach the group (set the attachment's particleGroup to null)
- Add particles to the group
- Reattach the group (set the attachment's particleGroup back)
This can quickly get expensive if you're constantly adding/removing particles from a group one by one. If your intent is to deal with individual particles and attach/detach them individually, using groups will only complicate matters. A much simpler approach is to use the particles API to deactivate dynamics simulation on specific particles (by setting their inverse mass to zero), and just override their position. This is what attachments do internally, they just abstract individual particles into "groups" to make it easier to work with and reason about multiple particles.
(08-12-2023, 11:57 AM)Christoffer Wrote: Also, any tips on getting the feeling of a cable rather than a rope, without going overboard with iterations? Cant use ObiCable as i cant change the length of it in runtime :/
Reduce your blueprint's resolution and use surface collisions to compensate for the fewer particles. This will reduce overall cost of running the simulation, allowing you to spend more substeps on it, which in turns allows the simulation to reach much higher effective stiffness.
kind regards,