Help Obi 7 Questions

[MEPETAMINALS]

Hi, I've been heavily using Obi (cloth and rope) for several years now in the development of Following Seas. I'm quite happy with it overall, with really the biggest issue coming down to performance. Typically about 30-50% of total profiler load goes into the system -- which has been acceptable, but definitely reduces the number of runnable systems for users.

I've been looking into Obi 7, as performance seems to be a major focus, and have also split into a separate project branch to test it out -- but have a couple questions if you don't mind.

I'm struggling with the removal of Proxies -- are there any plans for a similar system, or revisions to the decimation? I like the automatic decimation, but I find that there isn't near the control that was available with proxies. For example, my cloth meshes rely on specific groups for attachment points, like the rays of a battened sail, or the corners where ropes would attach. Decimation on my more detailed meshes often causes these points to be far off from where they should be, or causes topology lines to become very wobbly due to merging inconsistently up and down when parallel lines of vertices are present. It would be nice to exclude vertex groups from decimation, or have a method of ensuring the shape of the mesh isn't overly affected.

I didn't see any method for controlling this, do you have any suggestions?

Secondly, it seems that ambient force zones have been removed -- is it preferred to have a wind force zone follow affected objects around, or to set wind directly through the solver?

I've attached a beautifully rendered version of my struggle with blueprints. The left indicates the result gained via the Obi 6 method, with the red dots representing vertices on the simplified mesh. The central black line is a group used for particle attachment, and the red corner is a point were a rope would attach.

On the right is a somewhat dramatized example of what I'm encountering through decimation.

   

[josemendez]

Hi!

Decimation doesn’t replace the old proxies system - it’s more of an addition to it. The replacement for proxies is the new cloth rendering and skinning system, which is a simpler, more performant and streamlined encarnation of proxies: https://obi.virtualmethodstudio.com/manu...modes.html

ObiClothRenderer now takes an ObiCloth as input and will bind that object’s mesh to the cloth, same as proxies did. *Any* mesh can be bound to an ObiCloth actor, it may be the same used to generate the cloth blueprint or may be an entirely different one. The ObiCloth and the ObiClothRenderer do not need to be on the same object, in fact you can have multiple meshes bound to the same cloth.

For the common use case of low-poly mesh for cloth blueprint & high-poly mesh for rendering, you can still use entirely hand-crafted meshes as you used to with proxies. However, decimation comes in handy when you only have a high-poly mesh and want a quick, automatic low-poly version of it to generate the cloth blueprint. This doesn’t stop you from using a custom low-poly mesh with carefully designed topology.

Secondly, it seems that ambient force zones have been removed -- is it preferred to have a wind force zone follow affected objects around, or to set wind directly through the solver?

Setting global wind in the solver is more efficient, as it skips the need to determine whether object  particles are inside the force zone or not - it simply affects all particles. This is the equivalent of the old ambient force zone.

Let me know if you need further help,

kind regards

[MEPETAMINALS]

Hi!

Decimation doesn’t replace the old proxies system - it’s more of an addition to it. The replacement for proxies is the new cloth rendering and skinning system, which is a simpler, more performant and streamlined encarnation of proxies: https://obi.virtualmethodstudio.com/manu...modes.html

ObiClothRenderer now takes an ObiCloth as input and will bind that object’s mesh to the cloth, same as proxies did. *Any* mesh can be bound to an ObiCloth actor, it may be the same used to generate the cloth blueprint or may be an entirely different one. The ObiCloth and the ObiClothRenderer do not need to be on the same object, in fact you can have multiple meshes bound to the same cloth.

For the common use case of low-poly mesh for cloth blueprint & high-poly mesh for rendering, you can still use entirely hand-crafted meshes as you used to with proxies. However, decimation comes in handy when you only have a high-poly mesh and want a quick, automatic low-poly version of it to generate the cloth blueprint. This doesn’t stop you from using a custom low-poly mesh with carefully designed topology.


Setting global wind in the solver is more efficient, as it skips the need to determine whether object  particles are inside the force zone or not - it simply affects all particles. This is the equivalent of the old ambient force zone.

Let me know if you need further help,

kind regards

Thank you for the thorough reply -- that answers my question. I saw the triangle skinmaps disappear on upgrade, and missed the functionality in the renderer. Very helpful.

[MEPETAMINALS]

Follow up question...

I've taken the plunge so to speak, and updated to Obi 7. 

After making some adjustments to get my own scripts working with the changed elements of Obi, I'm getting roughly similar performance in the editor using Burst for Obi 6x, and GPU for Obi 7.

However, in the build the Obi 7 version loses around 60fps, (I have a powerful system, so it's still getting ~100fps, but the same setup with 6 gave me 160-170) I notice that all Obi cloth objects are rendering with super low res textures as well in build. (In editor play mode they appear normal). I've attached script debugging, but no errors or debug warnings regarding Obi are generated.

Are there any changes that need to be made to the player/quality/build settings?

First image is from editor playmode, second is from build, with no changes made between them, and the same quality settings. Note the particle attachment being significantly off of the expected position as well. I'm assuming this is something to do with my build configuration, as this only occurs in builds using Obi 7, but not sure what to look for.

[Edit -- some of this seems to relate to the scene containing Obi scripts being loaded additively, i.e. issues seem more prominent when loading a scene from a menu vs loaded the scene directly.]

   

   

[josemendez]

Follow up question...

I've taken the plunge so to speak, and updated to Obi 7. 

After making some adjustments to get my own scripts working with the changed elements of Obi, I'm getting roughly similar performance in the editor using Burst for Obi 6x, and GPU for Obi 7.

However, in the build the Obi 7 version loses around 60fps, (I have a powerful system, so it's still getting ~100fps, but the same setup with 6 gave me 160-170)

Use Unity’s profiler. It’s the only way to determine why the build is slower. If you need help interpreting profiling data, you can export the profiling session and I’ll be glad to take a look at it.

Note however that GPU simulation isn’t always faster than CPU simulation. In fact, for relatively small workloads it’s often slower since it has more overhead - data must be copied back and forth between the CPU and the GPU, and individual GPU cores are slower than CPU cores so if your scene doesn’t have good parallelism opportunities, using the GPU is counterproductive. Also, your GPU is often already busy with rendering so depending on how graphically heavy your game is it may not be a good idea to put additional burden on it. See: https://obi.virtualmethodstudio.com/manu...kends.html

I notice that all Obi cloth objects are rendering with super low res textures as well in build. (In editor play mode they appear normal). I've attached script debugging, but no errors or debug warnings regarding Obi are generated.

Are there any changes that need to be made to the player/quality/build settings?

All Obi does is move mesh vertices around. It doesn’t modify textures, shaders, materials or quality settings. Not sure why textures would be lower quality on your build, to be honest.

Note the particle attachment being significantly off of the expected position as well. I'm assuming this is something to do with my build configuration, as this only occurs in builds using Obi 7, but not sure what to look for.

If you’re using Obi’s asynchronous solver mode, keep in mind this causes a 1-frame delay between simulation and rendering. I’d try synchronous or synchronous fixed instead (synchronous fixed is the equivalent to Obi 6’s ObiFixedUpdater). The manual has an in-depth explanation of all synchronization modes and how they relate to Unity’s physics update loop:
https://obi.virtualmethodstudio.com/manu...eloop.html

[MEPETAMINALS]

Use Unity’s profiler. It’s the only way to determine why the build is slower. If you need help interpreting profiling data, you can export the profiling session and I’ll be glad to take a look at it.

Note however that GPU simulation isn’t always faster than CPU simulation. In fact, for relatively small workloads it’s often slower since it has more overhead - data must be copied back and forth between the CPU and the GPU, and individual GPU cores are slower than CPU cores so if your scene doesn’t have good parallelism opportunities, using the GPU is counterproductive. Also, your GPU is often already busy with rendering so depending on how graphically heavy your game is it may not be a good idea to put additional burden on it. See: https://obi.virtualmethodstudio.com/manu...kends.html


All Obi does is move mesh vertices around. It doesn’t modify textures, shaders, materials or quality settings. Not sure why textures would be lower quality on your build, to be honest.


If you’re using Obi’s asynchronous solver mode, keep in mind this causes a 1-frame delay between simulation and rendering. I’d try synchronous or synchronous fixed instead (synchronous fixed is the equivalent to Obi 6’s ObiFixedUpdater). The manual has an in-depth explanation of all synchronization modes and how they relate to Unity’s physics update loop:
https://obi.virtualmethodstudio.com/manu...eloop.html

Thank you for the in depth responses. Much appreciated.