Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Line Renderer expensive when solver "idle"
#1
I'm no expert on how line renderers work, but do they have to be updated every frame even if the solver is not enabled? 

The reason I'm asking is my current scene has 8 (very low particle usage ~10-30 each) ropes which solvers I toggle on and off when I need to simualte the ropes in order to save performance.
I noticed the rope line renderer takes 25% of my CPU even when the rope is not simulating while the mesh extruder does not? 

Can I hack the ObiRopeLineRenderer.UpdateRenderer() method to only update when the rope's solver is enabled or will that have unforeseen consequences? 

Right now I'm in between having bad performance when ropes are idle (using line renderer) or bad performance when they are running (using extruder).
Reply
#2
Yes they do: line renderers need to be updated whenever the rope moves, or any camera looking at them is rendered. In fact, their mesh needs to be generated and rendered once per camera.

This is because a line renderer is a triangle strip that always faces the camera currently being rendered. Even if the rope is static, the mesh triangles need to be oriented to the camera(s). If you only updated the mesh when the rope is moving or active, then rotating the camera around would break the illusion of it being a "3D" mesh.

We're working on adaptive rope decimation (the opposite of smoothing), which will be included in v5.3 (available in a couple weeks). This adaptively reduces the curve resolution depending on a user-defined curvature threshold, which can greatly reduce rendering overhead by spending resources only where needed, no matter what rope renderer you're using. Here's a quick video:

Reply
#3
(08-04-2020, 11:28 AM)josemendez Wrote: Yes they do: line renderers need to be updated whenever the rope moves, or any camera looking at them is rendered. In fact, their mesh needs to be generated and rendered once per camera.

This is because a line renderer is a triangle strip that always faces the camera currently being rendered. Even if the rope is static, the mesh triangles need to be oriented to the camera(s). If you only updated the mesh when the rope is moving or active, then rotating the camera around would break the illusion of it being a "3D" mesh.

We're working on adaptive rope decimation (the opposite of smoothing), which will be included in v5.3 (available in a couple weeks). This adaptively reduces the curve resolution depending on a user-defined curvature threshold, which can greatly reduce rendering overhead by spending resources only where needed, no matter what rope renderer you're using. Here's a quick video:


That really looks useful! Looking forward to the release! And thanks for the explanation!
Reply