Obi Questions

[Hummy91]

Hello. I'm not currently an Obi user, however I'm very interested in a number of the available assets. Due to a few other solutions falling short that I won't name, obi seems like an all round well put together set of tools. That being said, I have some questions regarding a few of the Obi products before I commit to integrating them into our project.

Obi Fluid:

• On the asset store this tool is listed as not supporting HDRP and there are some discussions on eventually supporting HDRP though there hasn't been any mention recently. I was wondering if this is still down the road and if so, is there an expected timeline?
  

Obi Rope: 

• I'm interested in using Obi rope, however in our current project we're using a combination of ArticulationBodies and Rigidbodies. I wanted to check if ObiRope had been tested with ArticulationBodies in any manner and if there were any issues to be aware of? Due to the nature of ArticulationBodies, we do often end up using a Rigidbody as a proxy/intermediate connection in order to get ArticulationBody based objects moving around so I don't expect much contention here anyway.
  

Obi Cloth:

• The current solution we're using for cloth physics is falling short due to instantiation limitations. Our clothing system effectively streamlines the work flow for our artists by generating a prefab for each SkinnedMeshRenderer component as a standalone object/prefab. In other words, it's saved without anything else, no bone hierarchy etc. This causes the SkinnedMeshRenderer component to lose/clear it's bone references once prefabed. When these prefabs are instantiated at runtime, the system is passed a target renderer (the character for example) and the bones on prefab's SkinnedMeshRenderer are assigned and setup. This works across the board in our project but obviously introduces potential complications when dealing with additional systems that interact with the mesh.
  
  Would Obi Cloth support adding cloth physics to such prefabs and function correctly once instantiated? From the material I've seen I would assume so due to the way the particle data is cached in a file but I don't know enough about this to be certain.

Obi SoftBody:

• We're interested in making use of the soft body asset to simulate more realistic/interesting character physics. However the model we use requires a high base complexity (around ~80k triangles). Would this be a blocking issue when using ObiSoftbody? And are the particle scaling/count tools enough to finetune the performance to a reasonable state? (Tested an asset recently that had a 65k limit).
  
• When .. 'softening'? parts of the character mesh, we'd want to isolate specific parts of the character mesh where this occurs, and other areas where there is little or no softening and collision. Is this something that can be achieved/fine tuned? Based on the available video content, it appears this way but its not entirely clear and the video release dates seem to predate the latest versions by quite a bit.
  
• Furthermore, due to the particle based nature of obi soft body, how would this interact with skinned attachments like clothing? For example if the characters arm was using ObiSoftbody, would this affect the skin and therefore attached clothing would follow along? Or would this require applying ObiSoftbody to all of our skinned clothing with some synced up particle skinning data?
  
• Does ObiSoftbody play nicely with blendshapes? We use these quite extensively.
  
• What is the difference/point of ObiSoftbody's Surface and Volume modes? I understand how they differ technically, but I'm unsure what the purpose of those differences is outside of perhaps stability of the simulation and some sort of backface interactions?
  
  
  

Quite a long list of questions there, thanks for your time  

[josemendez]

Hi there!

On the asset store this tool is listed as not supporting HDRP and there are some discussions on eventually supporting HDRP though there hasn't been any mention recently. I was wondering if this is still down the road and if so, is there an expected timeline?

Yes, still on the roadmap. It should arrive during Obi 7's development cycle, that is to say within this year after Obi 7 is released. It's not possible to say an exact date since there's a lot of factors affecting development.

I'm interested in using Obi rope, however in our current project we're using a combination of ArticulationBodies and Rigidbodies. I wanted to check if ObiRope had been tested with ArticulationBodies in any manner and if there were any issues to be aware of? Due to the nature of ArticulationBodies, we do often end up using a Rigidbody as a proxy/intermediate connection in order to get ArticulationBody based objects moving around so I don't expect much contention here anyway.

Articulations are not supported by any Obi asset, only Rigidbodies are. The reason is that applying an impulse to a rigidbody from a thread other than the main thread is straightforward: store rigidbody velocities/mass/inertia tensor, and update velocities every time an impulse is applied, this can be done from a job very easily.

However applying an impulse to an articulation requires propagating the impulse trough all individual articulation bodies and also requires special treatment for each joint type. This would essentially require us re-creating the entire articulation system from scratch in HPCS, which is far from Obi's scope. Unless Unity exposes articulation data in a job-friendly way in the future, chances are support for them will never be added.

Would Obi Cloth support adding cloth physics to such prefabs and function correctly once instantiated? From the material I've seen I would assume so due to the way the particle data is cached in a file but I don't know enough about this to be certain.

Not without some additional setup after instantiating the prefab containing the cloth. A ObiCloth component by itself doesn't do anything, it needs to be part of a ObiSolver which in turn needs to be updated by a ObiUpdater component. This is required in order to take advantage of multithreading, there must be some sort of "master" component that can update multiple cloth instances in parallel.

We're interested in making use of the soft body asset to simulate more realistic/interesting character physics. However the model we use requires a high base complexity (around ~80k triangles). Would this be a blocking issue when using ObiSoftbody? And are the particle scaling/count tools enough to finetune the performance to a reasonable state? (Tested an asset recently that had a 65k limit).

Most certainly yes. Simulating 80k triangles is not doable in the CPU, and barely doable in the GPU if you intend to have anything else on screen. Only way around this is using a lower-resolution physical representation of the softbody (instead of simulating all 80k vertices) and skinning/binding the original mesh to it. Obi can do this automatically though, see:
http://obi.virtualmethodstudio.com/manua...setup.html

Also note that the 65k limit in meshes is imposed by Unity. The default format for triangle indices in Unity is 16 bit integer, which can store values  from 0 to 2^16 = 65536. If you want meshes with more vertices than than that, you need to explicitly flag them to use 32-bit indices. Otherwise Unity will automatically break them down into multiple smaller meshes. This also applies to meshes generated at runtime.

When .. 'softening'? parts of the character mesh, we'd want to isolate specific parts of the character mesh where this occurs, and other areas where there is little or no softening and collision. Is this something that can be achieved/fine tuned? Based on the available video content, it appears this way but its not entirely clear and the video release dates seem to predate the latest versions by quite a bit.

No, this isn't possible. Vertices must either be fully simulated or fully animation-driven.

Does ObiSoftbody play nicely with blendshapes? We use these quite extensively.

Not at all. You'd be hard-pressed to find any method of simulating deformable objects that works with blend shapes. The reason for this is that simulating deformable objects (cloth, softbodies) requires pre-calculating the rest state of the object (how it looks and behaves when at rest), this generally involves calculating a lot of distances and angles and takes a fair amount of time, so usually done once at edit time and stored/cached in some file (a blueprint, in Obi's case)

The problem is that blend shape deformation does not respect distances or angles between vertices: it effectively changes the rest state of the object so the precalculated data is no longer valid. Only ways around this are: A) re-calculating rest shape data every time a blend shape changes, which takes a few seconds to do so not doable in realtime B) precalculating and storing a different rest shape for each blend shape, then interpolating them at runtime, which would require a lot of storage space.

Most games usually do A), as far as the blend shape does not change at runtime. This is the case with character editors, for instance.

What is the difference/point of ObiSoftbody's Surface and Volume modes? I understand how they differ technically, but I'm unsure what the purpose of those differences is outside of perhaps stability of the simulation and some sort of backface interactions?

They simulate different things. Surface mode simulates only the surface of the object, think of a hollow rubber ball. Volume node simulates both the surface and the volume, like a solid rubber ball.

Surface mode is usually a lot cheaper (since it takes less particles to cover a surface than to fill a volume), and can be used to simulate solid objects if their volume to surface area ratio is small.

hope the answers are useful! let me know if I can be of any help.

kind regards,