Obi roadmap

[josemendez]

With the release of 5.0, we've designed things in a way that allows us to completely decouple simulation data (blueprints) from the simulation engine (solver+updater). This also resulted in better backwards compatibility for future versions, as changes in the way data is processed or laid out in memory at runtime will not necessarily affect the way data is stored in serialized form. The resulting workflows are also much simpler, imho.

This is not an arbitrary decision. Our plan moving forwards is to introduce interchangeable simulation engines: One of them will be the current native library, but we have another two in mind:

- A high-performance C# implementation based on Jobs + Burst. Expect not much difference in performance with the current engine, as we already use multithreading and SIMD internally. However, this will allow to support all platforms, and to include the full engine source code with the asset.

- A compute-shader based engine. Expect a huge increase in performance, but also quite some limitations in functionality.

This won't happen overnight, but we have already paved the way. Personally I'm very excited with the road ahead .

Let me know your thoughts on this!

[StudioTatsu]

Outstanding news. Definitely looking forward to the full source version, mainly because it will allow us to integrate it into our pipeline directly.
I've been using Obi products alongside my own alternative solutions and the biggest challenge is streamlining the pipeline workflow.

Great work!

[jp715]

Hi, I was just wondering if there were any plans to make Obi 5.0 compatible with Unity 2018.x?

[josemendez]

Hi, I was just wondering if there were any plans to make Obi 5.0 compatible with Unity 2018.x?

It's unfortunately impossible . The whole development of 5.0 was sparkled by the need to support 2019, and adapt to the massive changes that Unity is undergoing in many aspects. 4.1 supports up to 2019.0 (included), and 5.0 supports 2019.2 and up.

[jp715]

It's unfortunately impossible . The whole development of 5.0 was sparkled by the need to support 2019, and adapt to the massive changes that Unity is undergoing in many aspects. 4.1 supports up to 2019.0 (included), and 5.0 supports 2019.2 and up.

Thanks for the reply! Sorry to be contradictory but I just wanted to let you know, I ended up trying out Obi 5.0 in Unity 2018.4.9 in the meantime, and although there were some compiler errors at first, it seems to be working okay? 

I initially got some errors about references to non-existent assemblies, but I just deleted the 4 assembly references from Assets/Obi/Scripts/Obi.asmdef. I also had an issue where particles in the blueprint editor were being highlighted but not selected, but restarting Unity seemed to resolve that. 

All of the example scenes still don't open, but I tried out a plain cloth with fixed corners like in one of your tutorials, and a skinned cloth, and both seem to be working. I took some screenshots of the compiler errors if any of those might be helpful.

I am, however, getting some performance spikes that I asked about in a different post (http://obi.virtualmethodstudio.com/forum...p?tid=1518). Do you think they might be caused by using Unity 2018?

[VincentFTS]

Hi,

you said here that Obi 5.0 will support Unity 2018.0 and up, I’m waiting for it ever since !
I’ve got issues with ObiRope 4 and I postponed all ropes related stuff, waiting for Obi 5.
Any chance that it can support Unity 2018.3 ? At least for ropes ?

Vincent

[josemendez]

Hi,

you said here that Obi 5.0 will support Unity 2018.0 and up, I’m waiting for it ever since !
I’ve got issues with ObiRope 4 and I postponed all ropes related stuff, waiting for Obi 5.
Any chance that it can support Unity 2018.3 ? At least for ropes ?

Vincent

HI Vincent,

Obi 5.0 only supports 2019.2 and up. Originally support for 2018 was planned, but differences in Unity versions made it apparent that we either needed to stay on 2018.x forever, or at some point upgrade to 2019. Quoting myself in this very thread:

It's unfortunately impossible. The whole development of 5.0 was sparkled by the need to support 2019, and adapt to the massive changes that Unity is undergoing in many aspects. 4.1 supports up to 2019.0 (included), and 5.0 supports 2019.2 and up.

kind regards,

[KnotANumber]

Hi!
First I want to say that I picked up Obi Rope recently and it's been such a breeze to use. Well done!
The compute shader thing you mentioned seems interesting. I was curious as to what the scope of the limitations in functionalities will be. I understand that this is still in development and that this might not yet be fully cleared, but is there anything you can share regarding the functionalities that will be limited by this alternative simulation engine?

Thanks in advance, and good job to you and your team for this great asset!

[josemendez]

Hi!
First I want to say that I picked up Obi Rope recently and it's been such a breeze to use. Well done!
The compute shader thing you mentioned seems interesting. I was curious as to what the scope of the limitations in functionalities will be. I understand that this is still in development and that this might not yet be fully cleared, but is there anything you can share regarding the functionalities that will be limited by this alternative simulation engine?

The compute-based backend is still WIP, but many basic features have already been implemented.

Its biggest limitations stem from the fact that bringing simulation data from the GPU back to the CPU is extremely costly. It can be done asynchronously (let the GPU know that you need the data, continue running things in the CPU, get the data a few frames later) but this introduces latency. So two-way rigidbody interaction is probably out the window, since you need data from the GPU, and you need it the same frame it's been produced. Also, many things you'd be able to do in CPU-based backends will be harder or outright impossible to do in the compute backend. So it will be mostly aimed at pure eye-candy, simulations where you don't need to retrieve data every frame for gameplay reasons.

You can see it in action here (in the context of fluids/cloth, though):
https://www.youtube.com/watch?v=7w2D2rYEk1M
https://www.youtube.com/watch?v=BQzZzQMl7x8

Thanks in advance, and good job to you and your team for this great asset!

Though I do get help with forum/webpage maintenance, it's just me 95% of the time . Thanks!

[whack]

The compute-based backend is still WIP, but many basic features have already been implemented.

Its biggest limitations stem from the fact that bringing simulation data from the GPU back to the CPU is extremely costly. It can be done asynchronously (let the GPU know that you need the data, continue running things in the CPU, get the data a few frames later) but this introduces latency. So two-way rigidbody interaction is probably out the window, since you need data from the GPU, and you need it the same frame it's been produced. Also, many things you'd be able to do in CPU-based backends will be harder or outright impossible to do in the compute backend. So it will be mostly aimed at pure eye-candy, simulations where you don't need to retrieve data every frame for gameplay reasons.

You can see it in action here (in the context of fluids/cloth, though):
https://www.youtube.com/watch?v=7w2D2rYEk1M
https://www.youtube.com/watch?v=BQzZzQMl7x8


Though I do get help with forum/webpage maintenance, it's just me 95% of the time . Thanks!

That second one reminds me of an old Sony ad: https://www.youtube.com/watch?v=0_bx8bnCoiU

If I remember correctly, the Xbox 360 was the first consumer machine to have shared addressable memory, which gave it rather ridiculous cpu-gpu bandwidth for its time. It's a shame that architecture never took off.

Still, not to add more to your plate, but the gpu backend would be a pretty cool feature.