(24-09-2026, 02:23 PM)Skotty Wrote: There are actually 2 reasons (combined) for the blueprint resolution to be at maximum. 1) I'm a new user. 2) It's the default value. I've already learned you can reduce the resolution, but I was still running under the assumption that 1 was a sensible starting point since it was the default.
Sorry, didn't mean to sound patronizing or anything. If I did, please accept my apologies.
1 is a sensible starting point indeed, however for a very long/thin rope the amount of particles that result from full resolution becomes excessive. More particles/constraints means not only a performance hit, but that the simulation becomes more difficult for the solver to solve to acceptable accuracy. So for longer ropes, 0.5 is a better starting point: coverage is still good enough that you won't often need surface collisions (see below) but low enough that a moderate amount of substeps gets you in the ballpark of a good result.
(24-09-2026, 02:23 PM)Skotty Wrote: This particular rope needs collisions and can be manipulated by the player by moving the plug (movement done by rigidbody forces), so it might need higher resolution than other ropes, but I should be able to drop the resolution if I'm careful to ensure particles can't get too far apart for collisions to start failing.
You could use surface collisions if you need to tune resolution way down.
(24-09-2026, 02:23 PM)Skotty Wrote: I'll run some more tests based on your feedback. It wouldn't be terribly easy to share this specific scene as it's part of a full game with multiple scenes (and while the test rope itself is not being loaded, there is currently no shortcut to the scene without loading a save game), but it's actually a good idea for me to try setting the same rope up in a separate sandbox scene to see what changes (if anything) in that case. If I see similar behavior in the sandbox, then that would be a lot easier to send you for review. If I see different behavior, then I have more exploring to do looking at differences between the sandbox and the game. It might be another day or two until I have the time to make the adjustments and run new tests, but I'll report back when I get there.
Sure, a sandbox scene that reproduces something similar would also be fine. Let me know once you have it ready.
27-09-2026, 04:45 AM (This post was last modified: 27-09-2026, 07:38 PM by Skotty.)
(24-09-2026, 07:25 PM)josemendez Wrote: Sorry, didn't mean to sound patronizing or anything. If I did, please accept my apologies.
You didn't. I was just being cheeky.
I set up a standalone scene, though I don't have it demonstrating the behavior yet. I also duplicated the scene with the behavior and am currently making changes to it to try to narrow down where the problem is.
One point of interest. I removed my compliance script and just set all the compliances to 0 for testing. In one test, I moved the red plug up so it would fall further at the beginning of the scene. When I do that, sometimes the rope will attach in the spot where the plug was at scene start even though the plug has fallen. See attached screenshot -- this was upon starting scene. So it seems like some of the time physics gets going before Obi can fully set itself up. I would guess this is closely related to the violent rope reactions on startup. However, it's not going to be due to rigidbody movement because I was also seeing the violent rope reaction with the rigidbody set kinematic where it doesn't move. I still think this points to something with the size of the scene, either a slow first frame or something else about the volume of other activity in the scene. I will try to mock this in the standalone test scene if I can. I'm still working on it.
EDIT: Note -- The plug looks like it is hovering above the ground because it still has an oversized box collider here.
EDIT2: Not necessarily related, but on my standalone test scene, on one scene load this happened (I have it set up where I can just press L and it reloads the same scene again, so I press L, watch what happens, press L again, watch, press L again... this just happened once after like pressing L 10 times):
InvalidOperationException: The previously scheduled job BurstPinConstraintsBatch:UpdatePinsJob reads from the UNKNOWN_OBJECT_TYPE UpdatePinsJob.shapes. You must call JobHandle.Complete() on the job BurstPinConstraintsBatch:UpdatePinsJob, before you can deallocate the UNKNOWN_OBJECT_TYPE safely.
Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.CheckDeallocateAndThrow (Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle handle) (at <cacc1b48a79f4e06850e7b9af174af54>:0)
Obi.ObiNativeList`1[T].Dispose (System.Boolean disposing) (at Assets/Obi/Scripts/Common/DataStructures/NativeList/ObiNativeList.cs:143)
Obi.ObiNativeList`1[T].Dispose () (at Assets/Obi/Scripts/Common/DataStructures/NativeList/ObiNativeList.cs:151)
Obi.ObiColliderWorld.Destroy () (at Assets/Obi/Scripts/Common/Collisions/ObiColliderWorld.cs:203)
Obi.ObiColliderWorld.DestroyIfUnused () (at Assets/Obi/Scripts/Common/Collisions/ObiColliderWorld.cs:232)
Obi.ObiColliderWorld.DestroyColliderData (Obi.ObiColliderHandle handle) (at Assets/Obi/Scripts/Common/Collisions/ObiColliderWorld.cs:435)
Obi.ObiColliderWorld.DestroyCollider (Obi.ObiColliderHandle handle) (at Assets/Obi/Scripts/Common/Collisions/ObiColliderWorld.cs:340)
Obi.ObiColliderBase.RemoveCollider () (at Assets/Obi/Scripts/Common/Collisions/ObiColliderBase.cs:171)
Obi.ObiColliderBase.OnDisable () (at Assets/Obi/Scripts/Common/Collisions/ObiColliderBase.cs:223)
I'm calling that one an Editor glitch given how many stops and starts I did plus lots of scene reloads while in the Editor, but thought you would want to see it anyway just in case.
I started tracking time in milliseconds between Update calls on the main game thread in both the standalone test scene and the full game game controller script.
On the full game, I was seeing very strong correlation between how long it would take on first frame and whether or not I saw the rope go wacky.
These tests were run through the Unity editor (I suppose I should do a full build test as well, but haven't yet). Numbers are milliseconds for the first 5 Update cycles. Most of the time, the shorter first time is upon a second load of the same scene, which for whatever reason, runs faster if scene has already been loaded before.
I tried to simulate this on my standalone test scene, but I'm not recreating it there yet. Maybe still another unknown in play.
One current suspicion is that I have a script I put in all of my scenes that are not the game starting scene that is primarily just to make development easier. What it will do is if you press play without having the starting scene loaded, the script will recognize you started from a scene that isn't the starting scene and load the starting scene. It's not especially cleanly implemented as it isn't configured to run first so a few things might start trying to do stuff in a scene missing it's do-not-destroy-on-load group possibly throwing a few errors before the scene load happens for the starting scene. Normally the only negative consequence is a few random errors in the log. But, maybe there are some static Obi resources or something that are being negatively affected by this. I did a bunch of tests starting play with the starting scene loaded vs starting play with some other scene loaded. So far it seems like while I have the plug drop / attach issue in both cases, I might only be seeing the rope launch happening when starting play without the starting scene loaded.
So, assuming the starting scene is Scene A, the sequence looks like this:
Scenario 1: Start on Scene B -> script quickly loads Scene A -> through menu, load Scene B -> frequent rope launch
Scenario 2: Start on Scene A -> through menu, load Scene B -> rare if any rope launch (need to do more test samples to be sure if it's just rare or never happens)
Maybe there is something left over from Obi starting to initialize in Scenario 1 that impacts startup when the scene is then loaded from the menu.
But in both cases, I still have the rope attachments occasionally in the wrong place. Still don't know if that is same, related, or unrelated issue.
EDIT395: Tried setting up the Scenario 1 in the standalone test scene but so far not recreating the problem. This is maddening. Instead of just a trimmed down test scene in the full game, I think I will try to duplicate the entire project and then start hacking and slashing stuff out of the duplicated project. At some point, I *HAVE* to eventually reach a point where the source of the problem becomes apparent as the standalone test scene and duplicated game converge on each other. Maybe there's a project setting or something having an effect. I may also be able to finally just trim down the duplicate of the full game to a point where I can share it for review if I can't duplicate the issue in the the standalone test scene.
My patience for debugging these issues is waning. I might take a break from it for awhile. But I will summarize the current findings here.
There are 2 issues which may or may not be related. Both ares specific to dynamic particle attachments.
Issue 1) Rope not always attaching to the correct place on the rigidbody.
Issue 2) Rope acting as is impacted by massive force on scene start.
Issue 1 observations:
This manifests when rigidbody is set in scene above ground such that it will fall on scene start. Rigidbody appears to fall partially or all the way to ground before obi attachment fully initializes, resulting in rope being attached above the rigidbody where it would have been before it fell. Rope has approximately 110 particles. Resolution 0.5. Tested with steps set at 4, 8, and 12; problem persisted in each case.
Issue has not yet been successfully replicated in standalone scene. It is assumed problem is related to startup lag on first 1 to 3 frames, but so far simulating lag in standalone scene has been unsuccessful in recreating problem. Other contributing factors may yet be unidentified.
Issue 1 mitigation strategy:
Set Obi attached rigidbodies as kinematic in the scene. If not loading from save file, use script to set isKinematic = false on Obi attached rigidbodies after about 3 frames. If loading from save file, there may be issues restoring rope state if rigidbody was in motion when saved. My persistence system restores the linear and angular velocity of rigidbodies on load, and it is unclear if this will cause additional issues with Obi start up. More testing is still required.
Issue 2 observations:
This may only manifest in the Unity Editor if a script abruptly switches away from a scene with Obi on startup and then returns to that scene again later. Under those circumstances, it only occurs part of the time. When it occurs, the rope will shoot across the play area as if affected by some massive force, dragging the rigidbody with it, and potentially lodging one or more particles through or under nearby colliders, locking the rope to the penetrated collider. This only happens when attachment is set dynamic, and will still happen if rigidbody is set kinematic (in which case the rigidbody stays stationary but the rope still launches itself across play area before snapping back or getting locked in a wall or floor collider).
Issue has not yet been successfully replicated in standalone scene.
Issue 2 mitigation strategy:
Adding compliance to the attachment can stop the behavior, but doing so causes undesirable elastic effect. Attempted starting with compliance and then dynamically removing that compliance after several frames, but this appears to cause attachment point to move down to where it was hanging due to the initial compliance sag. There is not any effective mitigation strategy identified so far. However, if this issue is truly limited to Editor behavior with rapid initial scene change, then it will only cause a developer inconvenience and should not need mitigation for a production build.
29-09-2026, 05:28 AM (This post was last modified: 29-09-2026, 05:56 AM by Skotty.)
One final wrinkle. Rope save and reload when rope and attached rigidbody are in motion. Re-attachment is not perfect, either because of how save or load is implemented I presume. Wondering if this can be tweaked.
Precondition
--------------
I ensured the rope was correctly attached to the rigidbody on initial first scene start (where no state is restored). Then menu is brought up while rigidbody is still falling to the ground so that it is in motion.
Save
------
Menu is brought up, time scale is set to 0 by bringing up menu. Save operation saves list of Vector4 with the actor solver positions as recently recommended in the separate save thread. Save operation also saves state of attached rigidbody.
Code:
List<Vector4> ropePositions = new List<Vector4>();
for (int i = 0; i < actor.solverIndices.count; i++)
{
int j = actor.solverIndices[i];
ropePositions.Add(actor.solver.positions[j]);
}
Load
------
Menu is brought up. Scene is selected for load. sceneLoaded event is used to restore most scene state, including state of attached rigidbody (which includes position and rotation). Rope positions are also loaded, but restoring rope positions is deferred until OnBlueprintLoaded event occurs. Then solver positions are restored.
Rope Position State (Obi Solver at 200, 100, 195):
Code:
First particle position:
{"x":8.095662117004395,"y":-0.8791969418525696,"z":-3.304687738418579,"w":0.0}
Obi Solver: 200, 100, 195
Net position (to 4 decimal places):
208.0957, 99.1208, 191.6953
Result
-------
Almost works, but attachment point is slightly off. To see this, in Start() I set the rigidbody isKinematic=true so that it won't move and I don't restore linear or angular velocity. Then see screenshot to see how rigidbody and rope re-initialized.
I could probably set up a standalone example of this one. I'm guessing a timing issue here. Maybe I'm catching the rope and rigidbody on save at a point where they are not in sync. I could try saving the rigidbody position relative to what the rope particle position is for the first particle in the chain (so instead of saving rigidbody position from rigibody position, add relative offset to particle position, which for example in the case of Y axis, relative offset would be zero, and I would save rigidbody Y position as 99.1208).
29-09-2026, 07:09 AM (This post was last modified: 29-09-2026, 07:17 AM by josemendez.)
(29-09-2026, 05:28 AM)Skotty Wrote: One final wrinkle. Rope save and reload when rope and attached rigidbody are in motion. Re-attachment is not perfect, either because of how save or load is implemented I presume.
Depends on what your interpolation settings are, what your solver synchronization mode is, and when you're saving the data.
Interpolation:
If rigidbody interpolation is enabled, transform.position and rigidbody.position will *not* be the same in general. The rigidbody will physically be at rigidbody.position, but visually will be rendered at transform.position (which lags around 1 frame behind rigidbody.position). Same for rigidbody rotation. You mention you store "rigidbody state", but don't specify how.
Exact same thing for Obi: if solver interpolation is enabled, solver.positions and solver.renderablePositions will not be the same, same difference as above.
Solver synchronization
There's 3 synchronization modes in Obi (see: https://obi.virtualmethodstudio.com/manu...eloop.html):
- By default asynchronous mode is used, which overlaps simulating frame N with rendering frame N-1. Takes place in the solver's LateUpdate().
- Fixed mode, which simulates frame N and then renders it, as a single step regardless of how many FixedUpdate() calls are there. Takes place in the solver's LateUpdate().
- Synchronous mode, which simulates frame N as multiple separate steps (one per FixedUpdate call) and then renders it. This offers the best sychronization with rigidbodies. Takes place in the solver's FixedUpdate().
So on top of the latency introduced by synchronization, your choice of mode and the moment during the frame where you save the data may introduce additional latency.
My guesses are that you're storing transform.position instead of rigidbody.position, you're using interpolation for the solver but not the rigidbody or vice-versa, you're using async mode and not accounting for the one frame of latency, or you're using fixed mode and saving data when the rigidbody has been simulated but the rope hasn't yet. Any combination of these would cause slight off positions when saving/storing data.
29-09-2026, 05:23 PM (This post was last modified: 30-09-2026, 02:18 AM by Skotty.)
(29-09-2026, 07:09 AM)josemendez Wrote: Depends on what your interpolation settings are, what your solver synchronization mode is, and when you're saving the data.
Interpolation:
If rigidbody interpolation is enabled, transform.position and rigidbody.position will *not* be the same in general. The rigidbody will physically be at rigidbody.position, but visually will be rendered at transform.position (which lags around 1 frame behind rigidbody.position). Same for rigidbody rotation. You mention you store "rigidbody state", but don't specify how.
Exact same thing for Obi: if solver interpolation is enabled, solver.positions and solver.renderablePositions will not be the same, same difference as above.
Solver synchronization
There's 3 synchronization modes in Obi (see: https://obi.virtualmethodstudio.com/manu...eloop.html):
- By default asynchronous mode is used, which overlaps simulating frame N with rendering frame N-1. Takes place in the solver's LateUpdate().
- Fixed mode, which simulates frame N and then renders it, as a single step regardless of how many FixedUpdate() calls are there. Takes place in the solver's LateUpdate().
- Synchronous mode, which simulates frame N as multiple separate steps (one per FixedUpdate call) and then renders it. This offers the best sychronization with rigidbodies. Takes place in the solver's FixedUpdate().
So on top of the latency introduced by synchronization, your choice of mode and the moment during the frame where you save the data may introduce additional latency.
My guesses are that you're storing transform.position instead of rigidbody.position, you're using interpolation for the solver but not the rigidbody or vice-versa, you're using async mode and not accounting for the one frame of latency, or you're using fixed mode and saving data when the rigidbody has been simulated but the rope hasn't yet. Any combination of these would cause slight off positions when saving/storing data.
kind regards,
Thank you for the reply. I've been working with Unity for a year and half now and never realized the rigidbody had it's own position. So yes, I was storing transform position. I'll explore using rigidbody position and see how that affects things. I would guess, for a rigidbody, I should save and restore both transform position and rigidbody position, though I'll have to investigate to be sure.
I've always left synchronization mode as default without interpolation.
EDIT: After some research, I'm finding some conflicting information, but I'm not convinced I need to (or even should) save rigidbody position. Nevertheless, I tried just saving/restoring rigidbody position without saving/restoring transform position, and got undesirable results. I tried saving and restoring both but that seemed to just replicate the original behavior.
EDIT2: I experimented with setting rigidbody position using particle position as a reference but it doesn't seem to be directly translatable. I tried using transform.TransformPoint on the particle position but that looked wrong. Then I thought maybe the particle positions are world space but offsets from solver object, but that didn't quite work right either (though it seemed oddly close). I tried a lot of variations without success. I think what I might try next is a variation of the snap() code on this page https://obi.virtualmethodstudio.com/manu...ments.html to try to reconnect the rigidbody on load.
EDIT3: If I use Synchronized Fixed the attachment attaches in the correct place on load, but then the rope acts funky. I can't seem to figure out how to properly account for delay in the other modes.
30-09-2026, 07:37 AM (This post was last modified: 30-09-2026, 07:42 AM by Skotty.)
After an amazing amount of pain mixed with various mistakes along the way, I think I finally have a persistence solution that works for my apparently Obi-unfriendly environment.
On first load of scene (not loading from state), I use my previously noted mitigation strategy of holding the rigidbody in place for 3 frames before letting it go. On the 3rd frame, before letting it go, I store the offset of the rigidbody (in solver local space) from the particle at the end of the rope. I then use this as a baseline for restoring state later. When game is saved, I save the offset rather than the rigidbody position. When game is loaded, after blueprint is loaded and rope state is restored, I then set the rigidbody transform position using the particle position and offset and converting solver local space to world space. And this works for me.
The rope freak outs continue to appear to be limited to the developer scenario that has the rapid scene switch. As long as that holds true, I'm not going to worry about it. I just have to make sure to load the starting scene first before starting play in the editor if I want to test a scene with Obi ropes so it doesn't go bananas on me.
This works with mode set to asynchronous. I'm not using any interpolation. No compliance is necessary on the attachments to avoid rope turbulence with this approach.
02-10-2026, 08:26 PM (This post was last modified: 02-10-2026, 09:53 PM by Skotty.)
Well, I thought I had it working, but after additional testing, it is not.
To clarify how I was attempting to reposition the attached rigidbody on state restore, it was actually a bit more complicated than I explained. What I was doing was building a coordinate space with origin at the endpoint particle and direction vector defined by the endpoint particle and the particle next to it. Then saving the local position in that coordinate space for the world position of the plug. But alas, this doesn't seem to be working either.
I do have a plan to greatly simplify what I'm doing. It involves editing the mesh and moving the mesh origin to the exact center of the mesh (or I could put it basically where I want the attach point to be). This particular mesh was originally set up with an offset origin. Reason being, since the plug and receptical go together, by keeping them both with the same origin, when the plug is childed to the receptical, child position (0, 0, 0) perfectly aligns the plug with receptical. But that convenience is not nearly as important at this point as simplifying the Obi scenario. So I'm going to move the origin of the plug mesh to basically the center of the plug so that the plug can just be positioned precisely on top of the particle at the exact same coordinate. That will reduce flexibility of the design but greatly simplify what needs to be done to restore state. If I still have positioning problems after that, I can at least rule out mistakes related to offset positioning.
EDIT: It looks like this solution will work. I've updated the mesh to center the origin where the attachment is, and I've done a number of save and load tests and so far it seems to be working well. I now just restore the rigidbody plug to right where the last particle position is. In the next day or two I'll post a YouTube link of the final play sequence which you might be interested in seeing.
