Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Only render ropes
#11
It's hard to tell what might be happening without seeing the full code.

- When are you updating particle positions? (FixedUpdate(), Update(), etc)

- I assume you're storing rope.solverIndices in the synchronizedData.Indeces array? this doesn't seem like a good idea to me, as nothing guarantees the solver indices will be the same in both the "client" and the "server". Unity calls Awake() Update(), etc in an undefined order for different objects, so if the Awake() order changes in the client vs server, the ropes will be added to the solver in a different order and their indices will change. A better approach would be to work with actor indices (from 0 to number of particles in the rope) as they can't change.

- The rope renderer uses solver.rendablePositions, not solver.positions, so if the solver is disabled you will need to write positions into that array. The renderable positions might or might not be interpolated depending on the solver interpolation settings: if it's disabled, they will be the same as positions. If not, they will be interpolated from the last step and the current step positions. See:
http://obi.virtualmethodstudio.com/tutor...icles.html

Quote:If the solver's interpolation mode is set to interpolate, solver.renderablePositions will contain temporally smoothed-out positions that won´t coincide with the actual particle positions at the end of the simulation step. That's why they are called "renderable": they are only used to guarantee smooth rendering, but they aren't fed back into the simulation.
Reply
#12
(12-03-2021, 11:25 AM)josemendez Wrote: It's hard to tell what might be happening without seeing the full code.

- When are you updating particle positions? (FixedUpdate(), Update(), etc)

- I assume you're storing rope.solverIndices in the synchronizedData.Indeces array? this doesn't seem like a good idea to me, as nothing guarantees the solver indices will be the same in both the "client" and the "server". Unity calls Awake() Update(), etc in an undefined order for different objects, so if the Awake() order changes in the client vs server, the ropes will be added to the solver in a different order and their indices will change. A better approach would be to work with actor indices (from 0 to number of particles in the rope) as they can't change.

- The rope renderer uses solver.rendablePositions, not solver.positions, so if the solver is disabled you will need to write positions into that array. The renderable positions might or might not be interpolated depending on the solver interpolation settings: if it's disabled, they will be the same as positions. If not, they will be interpolated from the last step and the current step positions. See:
http://obi.virtualmethodstudio.com/tutor...icles.html

Woah thanks a lot, I got it to work! I now have rendered ropes on the client with only 0.35 ms Gran sonrisa

Here's the steps a took if anyone is trying to do the same:
- Updating particles on Update()
- I switched to actor indices, that fixed the problem where not all particles were updated.
- Setting Solver.renderablePositions instead of Solver.Positions fixed the ropes not rendering issue.
- To win performance, I no longer call Rope.Interpolate(). Instead, only set Solver.renderablePositions and call ObiPathSmoother.GenerateSmoothChunks() followed by ObiRopeExtrudedRenderer.UpdateRenderer()

Here's the final code snippet for setting the client-sided code:

Code:
for (int i = 0; i < _obiRope.solverIndices.Length; ++i)
{
    int solverIndex = _obiRope.solverIndices[i];
    _obiRope.solver.renderablePositions.SetVector3(solverIndex, synchronizedData.Positions[i]);
}

_obiPathSmoother.GenerateSmoothChunks(_obiRope, _obiPathSmoother.smoothing);
_obiRenderer.UpdateRenderer(_obiRope);
Reply