Currently only Builtin Pipeline Shader is available in OBI for backface. However the new URP allows to distinguish between front and back face and its working very well upto some extent but lighting is not working properly on backside of cloth in URP where we try to use URP Standard Lit with Backface option.
If we change our model add 2 side faces then it might not work in Obi Cloth Blueprint. Any idea how we can work with backfaces properly in URP or any shader or material that you can suggest us? any plans to support URP backface shader in future?
Hi, I have created a piece of cloth with 2 points on its two top corners (left and right). The goal to grab the piece of cloth corners by both hands in VR (one left and other right) and use that cloth.
I use static attachment with VR controller objects when any cloth corner is grabbed, but when any corner not grabbed i switch that corner to dynamic attachment because I want that corner to fall down due to gravity and depict natural cloth behaviour (and disconnect that controller and put attachment in kinematic so its not effect by gravity of cloth which is now using dynamic attachment)
I have noticed one thing if I'm holding one corner of cloth (for example left corner with left controller) using static attachment, and other end of the cloth (right corner) is hanging down with dynamic attachment, that end swings even if i don't move my other left corner at top. Its like some ambient air is moving it back and forth.
To summerize my cloth is moving back and forth like air is blowing it. I have check there is no ambient wind. How i can make it stay and move little? Increase mass or which settings i need to work so that it doesnt swing much
Hello, as shown in the attached picture, one clothing file is separated into several objects and meshes such as arms, neck, and torso.
I would like to apply a different blueprint file to each area, is it possible?
Based on the file in the picture, you can create and attach blueprint files to top_arm, top_waist, top_neck, and top_wrist, respectively!
There is a limit to the method of specifying the particle group within the blueprint, so I would appreciate it if you could answer if the above method is possible.
Hi, I hope you are all doing well.
I just have a few questions about FluXY. If you take the time to answer, I'd appreciate it.
I'm trying to implement the dyeing mechanic of a game called "Jelly Dye" (the app store link is down below).
My first question is, do you think that it is possible to achieve this with FluXY package?
Second question is, is there a better/easy way to achieve it?
If it is possible with FluXY, then I need help
I'm working on a container with the shape of a volume. I am increasing its size to fill the volume faster, applying torque to ensure even distribution, and gradually reducing turbulence over time to slow down its spread and eventually stop. It seems like it's kinda working but I need to do it with custom mesh. That's the point I'm having problems. Scaling the target causes unwanted shapes to appear. (a screenshot is attached). Torque is causing this I guess but It was fine when working with volume.
How can I prevent this?
Is there a better way to spread it and eventually make it look completely filled with no motion? I feel like I'm on the wrong path, I cannot fully understand spreading mechanism of this package.
Also I don't want it to dissolve or look like transparent. I need it opaque all the time.
Lastly, I was able to fix a few things in the last few hours but I cannot rotate and fill the whole object. (Screenshot with the blue effect)
Any help, advice or leading is appreciated.
Thanks in advance.
(While trying to figure things out I almost changed every single value on editor. So, if you see something strange please let me know )
There are two Obi Skinned Cloths under one Obi Solver. However, when I run the game in this state, one of them is not displayed correctly and the following Burst error occurs at the same time.
System.IndexOutOfRangeException: Index 418 is out of range of '296' Length.
This Exception was thrown from a job compiled with Burst, which has limited exception support.
0x00007ff9f51e576e (72dbf73df38f408656fe02d0f2c0200) burst_Abort_Trampoline
0x00007ff9f5152c39 (72dbf73df38f408656fe02d0f2c0200) Unity.Collections.NativeArray`1<Unity.Mathematics.float4x4>.FailOutOfRangeError (at G:/UnityProject/TestPrject_20240825/Library/PackageCache/com.unity.burst@1.8.18/.Runtime/unknown/unknown:0)
0x00007ff9f519c69c (72dbf73df38f408656fe02d0f2c0200) Unity.Jobs.IJobParallelForExtensions.ParallelForJobStruct`1<Obi.UpdateSkinJob>.Execute(ref Obi.UpdateSkinJob jobData, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, ref Unity.Jobs.LowLevel.Unsafe.JobRanges ranges, int jobIndex) -> void_1a17c9416545ae7079718413b8a5101d from UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null (at G:/UnityProject/TestPrject_20240825/Library/PackageCache/com.unity.burst@1.8.18/.Runtime/unknown/unknown:0)
0x00007ff9f519b1bd (72dbf73df38f408656fe02d0f2c0200) a03642dfa924890cc81509aac1c5d57a
0x00007ff6ef066982 (Unity) ExecuteJob
0x00007ff6ef066cf4 (Unity) ExecuteJobCopyData
0x00007ff6ef067a2f (Unity) ForwardJobForEachToManaged
0x00007ff6ef063ddd (Unity) ujob_execute_job
0x00007ff6ef062fcd (Unity) lane_guts
0x00007ff6ef065c04 (Unity) worker_thread_routine
0x00007ff6ef2931fb (Unity) Thread::RunThreadWrapper
0x00007ffab85b257d (KERNEL32) BaseThreadInitThunk
0x00007ffaba80af28 (ntdll) RtlUserThreadStart
Am I using it wrong? Is there something else causing this?
The versions are as follows.
Unity 2022.3.43f1 (URP)
Burst 1.8.18
Jobs 0.79.9-preview.7
Mathematics 1.3.2
I noticed if any of my SkinnedMeshRenderers use Obi Softbody, they do not display in Play mode or when deployed to the Apple Vision Pro device. Has anyone had any luck getting this to work?
I tried the simplest of things to ensure it wasn't something else causing the problem. I went back to the simple demo setup from 4 years ago that applied softbody to a sphere. It displays fine in the scene window, but the Game window doesn't display the sphere at all. If I remove softbody from the Sphere it displays fine. The VisionOS Unity project templates to try this out can be found here: visionOS template project here. Here is a link to the general documentation. I have tried to get this to work on both Unity 6 and various versions of 2022.3.x up to 47f1.
For those that are not aware, Polyspatial Unity libraries create rendering code that can then be used to build an Xcode project that then needs to be built to be deployed to the device. This is needed to use the AR features of Apple Vision Pro if building from Unity.
Before I get into my problem, I just wanted to say how amazing the new version of Obi is. Thank you so much for continuing to work on these tools, the new Compute solver is incredible and the new fluid surface mesher is pure magic. We've been able to vastly increase fluid particle numbers and visual fidelity while also massively improving performance. The main issues I've had are just getting any kind of colour and opacity out of liquids, but I've been able to tweak the shaders in shadergraph to solve that and add custom effects. Honestly, you've done some amazing work on these tools!
The problem:
The issue I'm having now is with the simulation speed and emitter particle speed in a game that runs under the fixed timestep. We're using a fixed timestep of 0.1666667 and all the sample scenes work perfectly fine because they all run above 60 FPS, but in our actual game scene our FPS often dips under 60. This causes the simulation to appear to run in slow motion because the Obi Solver is running 1 max step per frame.
When I increase the max steps per frame, the simulation appears to run at full speed because it's doing the extra catch-up steps when needed, the new docs pages about the simulation timesteps has been very useful in figuring that out. The issue is that in this circumstance, the Obi Emitters no longer emit a steady stream, the stream becomes broken up with gaps, where some frames produce more particles and some less.
There's also a visible gap at the point of fluid emission that gets worse with increased fixed steps per frame because the simulation has already moved the particles by the time the next render frame comes around. It seems that emitted particles don't get rendered until they've been through a full simulation cycle and at that point they aren't at the location they spawned in. I would have expected that emitted particles would be rendered immediately so that the precise emitter particle spawn spots are always filled and the fluid always appears to start solidly from the same location.
Possible cause and workaround:
I think the cause has to do with an instability in the number of fixed frames per rendered frame, where some rendered frames end up with 1 fixed frame and some have 2, or if you're below half the fixed timestep some will have 2 and some will have 3. Emitters can only emit particles in discrete quantities, so that naturally results in stuttering. The frames that have 3 fixed updates move the existing particles further and the ones with 2 fixed updates don't move them far enough to cause new particles to be emitted, so that leads to gaps.
Ultimately I do have to try to get the performance of the scene up, but the only solution I can think of for anyone below 60 FPS would be to forcibly lock the framerate to integer factors of the fixed timestep. So any frame rate under 60 would become 30 so it'd always be precisely 2 fixed steps per frame, and then anything below 30 would become 15. That's not ideal but it does stabilise the simulation speed as too few fixed update steps leads to slow simulation and inconsistent numbers of steps leads to gaps.
The alternative would be to use a script to dynamically set the max steps per frame depending on the frame rate so that it never goes too high. For example, a game running at 50FPS would have a max steps of 1 and the simulation would just appear to run slightly slowly, while at 25 FPS the game would have a max steps of 2 and again just appear to run slightly slowly. That might be preferable to locking the frame rate, it's a trade-off I might have to make.
Remaining questions:
Writing this out has helped me figure it out, but does this all sound right to you or could there be a bug with how emitters handle different numbers of fixed timesteps? Also particles emitted seem to undergo a full frame's simulation cycle before they're rendered, causing that visible gap at the point of emission if there's a lot of sim steps per frame occurring, is that something that you could change or is it not possible to render emitted particles until they've gone through a simulation step?
In version 7 of Obi the physics is dealt differently as explained by official documentation and posts on forum. Physics is deferred till the end and applied later may be multiple times like for example during a performance it will apply a larger force to get the rigidbody back to its position.
But this creates a very small problem, sometimes in unity and specially in VR when a new scene is loaded there is a slight performance hit at the start of the scene (as scene is newly loaded and it loads textures and executes Awake / Start method of all active scripts), it creates a bounciness in rope at start due to this, the ropes which should be at rest position hanging only due to gravity gets oscillations. We have tried switching it to SYNC mode but it still does not help.
Is there any way to get back somewhat similar results like version 6 where we can force that even during a performance hit it should not apply a greater force or perform multiple calls. I mean we can change it dynamically that may be at start of scene don't do this and later we can turn this on in some settings?
If this option not available right now at the moment, can anyone in team consider this as a suggestions for future versions, it will be very helpful. We use multiple Obi products in our multiple apps and this one change in version 7 is causing too much oscillations at some points, specially for gravity effected hanging ropes.
Just finished a detailed write up on fixed timestepping, in the context of physics simulations. There's not much information out there about this and misconceptions run rampant, so I decided to included this in Obi's manual to cover the basics of simulation.
)
