Physics Obi Particle Based Physics (Cloth, Rope, Fluid) thread

Yup. But how would we use Obi fluid, and could it work with any other water solution?

I don't mean for that to be a question to answer now, but maybe something to think about as you work on it.

Maybe one practical application for games would be ... water attacks that splash realistically?

 

Can the water push other rigidbodies away or float them?

 

I am not sure that long term it would make much sense converting it from c sharp to c++ if you are looking for performance. If you want more performance you would be better off multithreading it my guess is if you are seeing such large performance differences between c sharp and c++ it is probably something to do with garbage collection or a memory leak. There is no reason that a multithreaded c sharp version should be much slower than c++ single threaded. Either that or you are compiling it with mono rather than the newer compiler.

Long term c++ is a dead end for multithreading because it is unmanaged by the compiler and so can't be optimised for multithreading. c sharp is slightly slower in single threading because it is a managed language but far more efficient for multithreading because it is a managed language.

Also it you switch it to a c++ plugin that will probably mean that you will need a different dll for each platform and some platforms such as the game consoles will reject the code as they only allow managed code to run on them.

There is nothing wrong in making a c++ version as well as c sharp if you want but long term if you want the highest performance you would probably want to run it on the gpu so a compute shader or opencl version would make more sense.

Long term I would be less interested in a plugin that was written in c++ because it would mean I couldn't easily convert it to the different platforms that Unity supports and would find it harder to use as I wouldn't be able to see the source or make any changes to it.

On the other hand a gpu accelerated soft body physics engine is something that unity is crying out for. Also if you look at unity's roadmap they are intending to convert compute shaders for all supported platforms automatically so unlike c++ long term they will be accepted on all platforms.

If I were you I would build it to be multithreaded in c sharp first and then convert it to use compute shaders at a latter date.

 

Yes, that's some of the benefits of having a unified system

 

That makes no sense. Why should anything properly written in c++ be slower than a C# version?

 

Hi Ian, thank you for your PoV!

I don´t know what unmanaged/managed code has to do with multithreading. Threads are threads, if anything they will run faster in unmanaged code because they are closer to the hardware. Managed code is code compiled for and executed by the CLR (in the case of C#) instead of the OS directly. Just this is enough reason for worse performance because of all the additional checks that must be done by the CLR at runtime and the automatic memory management, and while it is safer, it is by no means faster.

Unmanaged code on the other hand, relies on the programmer's ability to not F*** it up. Which of course is riskier but if you know what you're doing there should be no problem at all. Plus, it can run in any platform you can compile it for, (which in the case of C++, is nearly everything) and there are some aggressive optimizations that the compiler can do for certain target platforms that can´t be done in managed code.

It would of course run faster on the GPU, but there are two reasons that throw me back: There are quite some platforms that don´t support compute shaders (nor CUDA or OpenCL, for that matter) and it is harder to try out new things and experiment when writing code for the GPU.

So for the time being I´ll stick with C++. In my tests, the single threaded C++ version is roughly 2 times faster than the multithreaded C# version using 4 threads (which is already out, btw). There are no memory leaks in the C# version -as far as I know it is impossible to have a leak in purely managed code, by definition- and the garbage collection stays quite low with no sudden peaks. I´ve even detected non-negligible performance differences between a "foreach" loop and a plain "for" loop in C# when using generic lists (I´m talking about a millisecond difference!) so that alone is a showstopper for me. I come from a C/asm background so syntactic sugar that has such high impact in performance turns me off...

 

Zeblote it is because in the future c sharp would be able to use the newer il2cpp compiler while direct c++ code can't. Because cpus have pretty much stopped getting faster the whole industry is moving to multithreaded stuff to try and gain extra performance. The issue with multithreaded stuff is that unless those threads are managed ie the os will be the one determining and managing threading control and memory usage you could easily make a program that would take down the whole cpu or certainly the OS at least. C++ is an unmanaged language meaning that the compiler can't guarantee to the operating system that something written in it can't stall a cpu you can make a direct reference to memory for example. As a result for years any program compiled in c++ will be run on a virtualised thread by the operating system and isolated so that it can't take down the operating system if it has issues. The issue is that there is a performance penalty when you try and multithread with those virtualised threads to guarantee thread safety at the os level.

Managed languages like c sharp are better for multithreading but slower at single threaded stuff because this managment has a performance penalty.

il2cpp stands for intermediate language to c++ . Basically it can take a managed language and convert it into c++ in the compiler. Although c++ is unmanaged because it has been initially fed a managed language such as c sharp because the compiler is the one generating the c++ code that controls threads it can guarantee it is thread safe and let the os run it with less management.

In short it will then compile code that has the benefits of both a managed and unmanaged language to get the maximum performance possible from any thread running under os level on the cpu.

Looking at how unity compiles as default at the moment it looks like it still uses mono on most platforms rather than il2cpp so certainly in the short term c sharp will be slower. Long term il2cpp and gpu compute looks like the best bet for ultimate performance though.

 

That is interesting stuff Ian, hadn´t heard about il2cpp before. However the whole converting C# to C++ stuff seems a bit of a hack to me. It will make it easier and faster to write safe C++ code which is great, but nothing stops you from writing safe C++ yourself. Anyway, I don´t want to start yet another C# vs C++ argument here so... let's just hope the Unity guys give some more love to C#. Last time I checked they were using .NET 2.0 which is getting old, specially with all the new threading features in 4.5.

Edit: btw I think you´re talking user threads vs kernel threads. C++11 received support for multithreading (in C++98 you had to rely on the OS's support for threads), which if I´m correct means you have all the benefits of portable and -relatively- safe multithreading in an unmanaged language.

 

il2cpp won't make your code faster than c++ though. If anything, it'll be slower because il2cpp adds a ton of proxy methods that won't all get optimized away. It's meant to be faster than C#, not to take on native code! (Though it probably comes close)

And no one is going to run c++ programs in a VM, that makes no sense. They're supposed to be as low level as possible.

 

Arkano22 the conversion of one programming language to another by a compiler is nothing new. Even if you pass in a C++ program at the very least it will convert it to assembler first and then to machine byte code in the compilation process. It has always been common for a compiler to convert down from high level languages to lower ones. For maximum performance usually you target the highest level language you can get away with that has a compiler that can compile lower more efficiently than a human can.

Even c++ is a relatively high level language its just that it has a compiler that can convert into c and assembler by a compiler on average better than a human can write assembler.

Both il2cpp and unmanaged computer shader systems like directx12 are fairly new and aren't perfect yet but according to unity's roadmap they are the direction they are going in and they certainly look like they have performance gains long term.

The programming language you choose isn't really the issue though it is what platforms that choice of language will allow you to run anything produced on.

I am guessing if you are going to use c++ then you are going to have to compile and link a native dll to use it in unity which would pretty much limit you to only computers. Consoles and mobiles would no longer work unless you compiled dlls for those platforms. I'm pretty sure some of them have restrictions on dll usage too meaning even if you could do it the platform holders would reject it.

For example unity rushed out il2cpp support for iphone because the mono compiler no longer compiled code that meets apples requirements going forward. Likewise unity is trying to use il2cpp with webgl now that most browsers have blocked native code plugins.

At the very least take your code and check you can convert it from c++ to c sharp and then compile it with the il2cpp compiler in visual studio to check the performance difference to see if it is worth the effort.

I guess since c++ and c sharp are fairly similar at least it wouldn't be to hard to convert the code at a latter date but if the performance difference between il2cpp and c++ is alot then I would be surprised.

I think unity themselves published some benchmarks they ran to show why they were switching to it and they compared it to both mono and pure c++ you might want to look it up.

 

Hi Ian, I know languages are usually parsed and compiled into other languages, I´ve written compilers myself (and hated it btw). But my point is that C++ (or C for that matter) is, at least for me, a good equilibrium between control and ease to use. Converting C# to C++ is like working in a rose garden using thick leather gloves. You won´t get hurt, but you lose quite a lot of finesse compared to what you could do barehanded.

I don´t want to write C# and give away control to an intermediate compiler if I can write C++ directly. Being a computer engineer, I feel a bit nervous when writing code that I don´t know to a certain degree what is doing underneath, specially for performance-critical stuff. But after all, it is just a matter of taste and as you say, what platforms you are targeting.

C# is more than enough for writing games in my opinion, so it's the natural choice for a lot of tasks. But when you are trying to scrape a few cycles here and there, it just gets in the way.
Obi still has and will have lots of C# code. Only the core solver is being rewritten in C++.

 

Hi, I've been messing around with the package, here are a few things I would love to see:

1) I was wondering if you could add a mode that treats a few transforms as if they were cloth, ie I select a few transforms and tell obi that those are its cloth particles.

2) would love to be able to use maps instead of painting with the tools, its just way easier to select verts, and fine tune values in other DCC tools than using stuff in Unity.

Looking forward to the next version = ]

 

Hi Invadererik,

About 1), I thought about a way to skin a regular mesh to a cloth mesh, using its vertices as bones. Your idea seems to serve the same purpose?

2) Will surely make its way in future versions

cheers!

 

@arkano22
When you are switching to c/c++ solver please also include the full source code as i wanted to learn from it.

 

If you've played around with Shroud plugin, you build a cloth mesh that you skin to the real mesh, it works really nicely in Shroud. Negatives of Shroud vs Obi : compiled plugin, no source code, costly, have to learn somewhat buggy separate program to create cloth meshes, hooking up the different output components and text files a bit of a slow process.

So I guess it might serve the same purpose, but in my case I just want whole objects to move around linked together, I don't want the individual objects to be treated as cloth, but the few transforms to sim like cloth, I guess I can use pin constraints or I guess I could just do it with joints instead. Just seemed quicker to select some objects and drag drop them into a cloth comp, than to have to build a cloth mesh that fits, and pin the vertices and stuff, or to play with the finicky joint stuff in Unity.

some other things I've noticed ( might be specific to my scene):
* pressing that optimize button is dangerous, lots of out of index errors sometimes.
* setting virtual particles on and hitting play crashes the scene.
* threads seem to have no effect on my sim ( pretty sure my cpu has cores just sitting there )

 

Well, if all you want is to get some transforms to follow the movement of cloth vertices, you can do it if you're willing to write a small script: in LateUpdate, just set the transforms' position to the position of one of the cloth vertices. Should be really easy to accomplish.

About these three remarks you talk about, the first two seem like proper bugs. Can you specify a bit more? (maybe copy the exact index errors you're talking about).

About the third one, blame it on the (insufficient) documentation. Multithreading can only kick in if the solver mode is set to parallel. Sequential mode is not parallelizable, at least not without graph-coloring the cloth which is a task i will tackle in the future, thus it will not benefit at all from multithreading.

 

Hello Arkano,

Is there an estimate release date of the new c++ version of OBI Cloth?

 

Hi Tasmeem,

It is progressing steadily, at a good pace. I'd like to have it out in around 3 weeks, however I will not release it until it is 100% ready and everything in the new architecture falls into place. In a week or so I will release a few videos of cloth+fluid interaction.

cheers!

 

Just to get you some insight on what's taking so long, I´ve decided to release a video. Please be aware that this is NOT REALTIME. These are just stress tests to see if the density / viscosity / surface tension constraints and buoyancy effects were working correctly when using high amounts of particles. The reason i'm also working on fluids instead of focusing on cloth only is to uncover potential design flaws in the solver architecture early on.

All of these run in CPU using 2 threads, one per core. Don´t expect more than 4000 particles @ 60 fps in the final version (fluid simulation is very expensive!). Some day I´ll throw some GPGPU at the solver to increase throughput, but multiplatform support is not very good atm (blame Nvidia) so it is unlikely this will happen soon.

The fluid rendering seen in the last part of the video however, does perform in realtime and it is quite fast. So the bottleneck here is not drawing the fluid, but simulating it. Hope you guys like it.

Edit: The first two examples show inmiscible fluids (like oil and water). The following videos, despite the different particle coloring, simulate only one fluid phase.

 

Hi Arkano22,
Looking really good. Now I really started to wonder about the soft/rigid body solver of yours

I was wondering how do you handle the mesh creation after the simulation?
Is it possible to have a cached playback?
Any possibility of exporting to common particles cache formats to be used in other software? Blender for example.

Thanks

 

Thanks gurayg!

There's no mesh creation for soft/rigidbodies. The original mesh (better said, a copy) is used throughout the simulation, and deformed according to it. Particles are placed at the mesh vertices and optionally at the positions of a subdivided version of the mesh, for finer collision detection. Then a single shape matching constraint is created for all the particles in the mesh. Shape matching works by modifying particle positions each frame so that they "fit" better with a rotated (squashed/bended) version of the original shape. If the "difference" between the deformed shape and the original shape exceeds a threshold, the deformed shape becomes the new original shape. At the end of each simulation step, mesh vertices are moved to the position of their corresponding particle.

An alternative is to use distance constraints between particles, instead of a single shape matching constraint. Both options will be available, since they perform / behave differently.

In the case of fluids, there's no mesh generation either. All rendering is performed in screen space. Particle depth is rendered to a buffer, and then a curvature minimization filter is applied, which smoothes out the depth. Then eye space normals/positions are reconstructed from the surface depth values, and basic blinn/phong lighting is applied. Optionally, a "thickness" buffer is also rendered and used to approximate absorption. The method roughly follows this article: http://developer.download.nvidia.com/presentations/2010/gdc/Direct3D_Effects.pdf. The main difference is how I´m generating depth values for the surface. They use a non-separable bilateral blur as if it was separable (which imho is utter crap ), while I´m using screen space curvature flow.

Cached playback is possible, but it will not be included in the box. You have full access to particle positions however, so nothing stops you from storing them in several lists, one per frame, and then interpolating them when playing back. I´ve done this for another project, caching positions and rotations of rigid bodies and it worked really really well. The only concern here is memory consumption.

If popular demand is high, I might devise some way to cache simulations and export them in, say, alembic format.

cheers!

 

Getting closer to the release date!

Just got inter-collisions to work. Which means cloth objects can collide with other cloth objects, something that was previously impossible. Since everything in Obi is particle-based, this completes the whole interaction pipeline, and means that everything can collide with everything: cloth-rigid, cloth-cloth, rigid-fluid, soft body-cloth, soft body-fluid, etc. The beauty of it is that all collisions are handled the same way, and the whole collision detection pipeline is continuous so fast moving objects will not miss collisions.

The scene shown in the video runs in realtime, roughly 80 fps. However gravity was set 50% so that collisions were clearly seen. Notice the two soft bodies bouncing off each other at the beginning, and the cloth colliding with all of them.

 

Hi, I just bought your plugin and when I attempt to create a cloth I'm getting the following errors and the scene view goes completely black when I click on the obi object. This happens both in my own test scene as well as the examples.

Unable to find required resource at 'Editor Default Resources/Particles.mat'
UnityEditor.EditorGUIUtility:LoadRequired(String)
Obi.ObiClothEditor:CreateParticleMaterial() (at Assets/Obi/Editor/ObiClothEditor.cs:350)
Obi.ObiClothEditor:OnSceneGUI() (at Assets/Obi/Editor/ObiClothEditor.cs:358)
UnityEditor.DockArea:OnGUI()

NullReferenceException: Object reference not set to an instance of an object
Obi.ObiClothEditor.CreateParticleMaterial () (at Assets/Obi/Editor/ObiClothEditor.cs:351)
Obi.ObiClothEditor.OnSceneGUI () (at Assets/Obi/Editor/ObiClothEditor.cs:358)
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:232)
System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
UnityEditor.SceneView.CallOnSceneGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:2056)
UnityEditor.SceneView.HandleSelectionAndOnSceneGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:1405)
UnityEditor.SceneView.OnGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:1242)
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)

I tried it on unity 5.2 and 5.3

Am I doing something wrong ?

 

Not reading the documentation (just kidding, no worries). This is probably the top one question regarding Obi, and it is answered in the first few lines of the QuickstartGuide.pdf that comes with the package:

- You must move the "Obi/Gizmos" and "Obi/Editor Default Resources" folders directly under /Assets.

The reason for this admittedly cumbersome setup is that Unity expects only one folder with that name per project, and it must be directly under /Assets, no exceptions. So if you have multiple assets installed that make use of custom resources, you have to be careful when installing them.

cheers!

 

ah sorry! Thanks for the quick reply!

 

Is there a ObiCloth version of the unity function ClearTransformMotion() ?
I need to teleport an object with cloth on it but don't want the cloth to stretch across the screen.

 

Hi Baznor,

There is no direct equivalent in Obi (in the next version you'll be able to just disable ObiCloth, translate, and re-enable it), but you can do the following:

- Set world velocity scale to 0.
- Translate (teleport) the cloth.
- Wait for 1 frame.
- Set world velocity scale back to 1 (or whatever it was).

This will prevent the cloth from stretching when teleporting it.

 

Is there a more comprehensive documentation(it appears the vids might be outdated.)? I'm trying to add this to and non skinned clothing object(back of a trench coat) with only 130 verts as the cloth and it is bogging my scene waaaaay down.

 

Hi kurotatsu,

Yes, you´ve got the tutorials in Obi's website. However both these and the videos will be outdated soon with the next update, as Obi has been completely rewritten. New videos and documentation will replace them.

About your performance problems, make sure you optimize the cloth (see this). Even if only 130 vertices are simulated, the rest of your mesh vertices might be the culprit.

 

I am wondering if your liquid system could be used for blood spurts.

Basically, Spawn particles on injury, they hit a wall and run down it (leaving decals in their wake) and eventually disappear to save on performance.

Basically, can a group of the liquid particles be instantiated, and given velocity, at runtime(your current examples have them already positioned)?

A good example you could do is your particles coming out of a water hose.

 

Hey arkano22, can we tie the cloth to a skinned mesh so it transforms with blendshapes?

 

Yes, skinned mesh renderers are fully supported.

 

Yes, fluids can (will) be used as you describe. Spawning the particles is no problem at all, they can be spawned from pretty much anywhere and in any way, either at runtime or in the editor. Once particles are spawned (with a given initial position and velocity), the simulation takes over. In fact, what the cloth system does is just instantiate particles at runtime and set up constraints for them. Fluids are no different.

The new docs explain all of this pretty well (I think). They will be out really soon.

 

Hello arkano22,

Great job for the improvements of the Obi system!
I have two questions concerning this system. Will there be a shader that allow "blending" of particles so that it looks like a mass of a few hundred particles is actually made of millions of particles? Also I am wondering if it is possible to nest particles inside each other or nest a rigid body in a particle shell? For example a water balloon, or (theroethically, for next next gen animations lol) a very realistic vertebrate where bones in the form of rigidbodies would be animated to make move a soft body skin made with particles.

 

Hi Minsc,

- Yes, such shader exists, its purpose is to render particles as fluid. You can see an example of how it looks in the last simulation shown in the fluids video (a few posts up the thread). It can be used to generate reflective-refractive-absorpting materials, or regular diffuse/phong shading.

- Yes and yes. It is possible to nest particles inside each other to create water balloons, and pin particles to rigid bodies. However the practicality of it for the purposes you describe is very questionable . Don´t expect good performance at all if you simulate bones and muscle using particles for your animations...

 

Cool! well sure that's not something that would be feasible on ps4 anyway but it's cool that it is possible to nest particles it gives a lot of possibilities^^

 

Any updates on the release date?

 

Hi Tasmeem,

I´m currently ironing out some pesky bugs, updating the docs and compiling the library for all supported platforms. Win and Mac (both 32 and 64 bits) and iOS are already done, Android is on the way.

Cannot promise anything because I'd rather be late than release a buggy version, but I hope to be uploading it to the store next week.

thanks for your patience!

 

Every time I'm going to add this to my cloth I get an error that says "Your mesh is non manifold, and thus cannot be proccessed by obi:" I've tested a lot of cloth model but still same error!
Can you please help me how can I fix that?

 

I'm looking for good cloth simulations for cloth for a fighting game. mainly hanging cloth, like capes and such.

 

I replied to you via personal message, but I´ll also post it here in case it helps someone else.

In 3D modelling jargon, a "non-manifold" mesh is a degenerate mesh which could not exist in reality. That means the mesh presents one (or more) of the following issues:

- Lamina faces (faces with zero area)
- Zero-length edges.
- Orphaned edges or vertices.
- Edges shared by more than two faces <---- this one is commonly seen when a modeler wants to have two-sided surfaces and tries to make up for lack of engine understanding by generating two triangles joining the same three vertices, and flips the normal for one of them. The correct way of doing this is by just disabling backface culling in the shader, and optionally doing another shading pass with flipped normals (if you need 100% correct lighting). Obi contains a backfaces shader specifically suited for this purpose.
- Some other kind of strange/degenerate geometry.

Most modeling packages (Maya, Blender, etc) have a "mesh cleanup" tool which will try to fix these defects in your mesh automatically. However most of the time it is better to do it manually if you have any hints about where the problem might be in your mesh.

The current version of Obi refuses to turn any non-manifold geometry into cloth, because the resulting particle-based representation (and thus the simulation) can have all sorts of issues. The next update will just generate a warning trying to convince you to fix your geometry, but do it anyway.

 

Hi Chris,

If you don´t need collisions with the environment or two-way rigid body interaction (rigid bodies bouncing off the cloth and such) the standard Unity cloth can satisfy your needs. Give it a go and if it doesn't cut the cake for you, purchase Obi . It is designed for exactly that kind of stuff.

cheers!

 

Thanks, just the performance doesn't looks so good! Unity 5 cloth system is a lot more optimized

 

Yep, that's why Obi is being rewritten in C for the next update. C# just isn't performant enough. Also keep in mind that Unity cloth does far less stuff than Obi (no proper aerodynamics, no bending constraints, no two way interaction, no volume constraints, no intercollisions, etc...).

And also remember that all that stuff is toggle-able, and the amount of iterations spent in each thing is adjustable. By default Obi has everything enabled and set to medium quality, you should be able to squeeze quite a bit of performance if you fine tune it for your particular use case (eg. disable aerodynamics if you don´t use them, etc.)

 

well I need something dynamic. as it will be cloth dangling from a character.

 

Yes, but there's an important distinction to be made: Do rigid bodies around your character need to respond to the cloth movements, or is it fine if the cloth collides with them but does not exert any force on them?

If your use case is the second one, you can just use Unity's cloth. If your case is the first one, you should use Obi.

Both systems are quite dynamic and will respond well to your character's movements.

 

Hi guys, good news.

Obi 2.0 has been submitted to the Asset Store. In a few days it will be available for download. Initially it supports only 3 platforms: Windows, Mac and iOS (all three in 32/64 bit). Android and Linux will be added later. The reason for this is most of the code has been rewritten in the form of an external library, which has to be compiled for each specific platform.

Keep in mind that Obi 2.0 is not backwards-compatible with previous versions. If you are currently using Obi in a wip project, I'd recommend sticking to the old version. Use 2.0 only with new projects.

Video:

Features:

- Core solver completely rewritten in C++, and completely revamped architecture for better memory management. This results in massive performance improvements.
- Added support for intercollisions (different cloth pieces colliding with each other).
- Mass, skin radius and skin backstop can now be loaded from textures, either from the editor or programatically.
- ObiWorld has been deprecated in favour of a simpler, more efficient approach to collisions.
- Normals maps fully supported trough optional tangent space updating.
- Friction and stickiness are now applied trough particle material interactions.
- As always, bugfixes.

 

Dear Arkano!

I have a low-medium performance cpu, and a medium-high performance graphic card (and a terrible English xd). Unity's cloth simulation looks awful, but smooth with crowded scenes too, and Obi 1.7.1 looks fantastic, but it is killing my cpu with a medium populated scene. Do you think I will be able to run (after recreation, ofc) the medium populated scenes with 2.0 update?
You mentioned below one of your videos, that gpu implementation is on the roadmap, and I would like to know - does any chance it will be available this year?
I don't really have enough money for a new PC config right now, and I have a motherboard with FM2 cpu socket... You think a high-end FM2 cpu would do it, or should I save some money for a new config?

Also, thank you for your hard work, and this fantastic product!

 

@arkano22 - Is the price staying the same? Will there be any upgrade fee for users of the current version?

 

Hi VargaPD! No worries about your English, it isn´t my first language either .

I´m confident you will be able to run much bigger scenes with Obi 2.0, since the speedup i´ve measured is almost eightfold. Some of the example scenes that run for me at roughly 30 fps in 1.7.1 (for example the soft bodies one) run at +100 fps in 2.0. My CPU is a 1.8 Ghz Core i5, so nothing top-notch.

About a GPU implementation, I´m already on it. My technology of choice is OpenCL, and though I can´t give time estimates right now, I certainly hope to have it working during this year.

My advice about Obi-friendly CPUs would be: get as many cores as you can, Obi likes threads.