+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Fluid (https://obi.virtualmethodstudio.com/forum/forum-3.html)
+--- Thread: Bug / Crash Frequent crash after assign the FluidPassCompute (/thread-4207.html)
Pages:
1
2
Frequent crash after assign the FluidPassCompute - spikebor - 07-05-2024
Before I add the FluidPassCompute, the Fluid only crash when I give it too small voxel size and/or too small Max Surface Chunks value.
But after adding the FluidPassCompute, I have many frequent crash (suppose not related to above fields since I've adjusted them)
Now it's likely crash when I enter or exit Play mode.
The log when crashed
Code:
D3D11: Failed to create RenderTexture (8 x 8 fmt 9 aa 1), error 0x887a0005
D3D11: Failed to create RenderTexture (8 x 8 fmt 53 aa 1), error 0x887a0005
d3d11: failed to create staging 2D texture w=64 h=64 d3dfmt=2 [887a0005]
Failed to present D3D11 swapchain due to device reset/removed.This error can happen if you draw or dispatch very expensive workloads to the GPU, which can cause Windows to detect a GPU Timeout and reset the device. (see https://docs.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery).If you believe this error is due to built-in Unity functionality, please submit a bug.This is an unrecoverable error and the editor will shut down.Also, this is the error in that is frequently shown after I added the FluidPassCompute asset.
Code:
RTHandle.Initialize should only be called once before allocating any Render Texture. This may be caused by an unreleased RTHandle resource.
Unreleased RTHandles:
_Foam
UnityEngine.Rendering.RTHandles:Initialize (int,int,bool)
Obi.ObiFluidRendererFeature:Create () (at Assets/Obi/Scripts/Fluid/Rendering/URP/ObiFluidRendererFeature.cs:27)
UnityEngine.Rendering.Universal.UniversalAdditionalCameraData:OnDestroy () (at Library/PackageCache/com.unity.render-pipelines.universal@14.0.9/Runtime/UniversalAdditionalCameraData.cs:819)Full Editor Log in the attachment.
Don't know why I can't add attachment (it rotating icon), link https://drive.google.com/file/d/18iCalYfBYzk5Da9-g9Vr5i1dE4im2HMx/view?usp=sharing
RE: Frequent crash after assign the FluidPassCompute - josemendez - 07-05-2024
Hi!
This sounds like a bug in Unity's RTHandle system, since it only happens when using transparent fluid (which is the only part of Obi that uses RTs). Since the RTHandle system is only used by SRPs, I assume you're using URP: which URP version are you using?
RE: Frequent crash after assign the FluidPassCompute - spikebor - 07-05-2024
(07-05-2024, 11:24 AM)josemendez Wrote: Hi!Hi, I'm using URP 14, Unity 2022.3.16f1
This sounds like a bug in Unity's RTHandle system, since it only happens when using transparent fluid (which is the only part of Obi that uses RTs). Since the RTHandle system is only used by SRPs, I assume you're using URP: which URP version are you using?
I haven't updated Unity for a while, is there a stable URP version that you recommend?
Another finding: the bug is less likely to happen if I gather the whole simulation into a prefab, and not include that prefab in the scene, will spawn when start the game.
RE: Frequent crash after assign the FluidPassCompute - spikebor - 10-05-2024
The issue is extremely bad since it freeze my editor so often.
Gladly I found the way around it.
It seems like you can disable all the solvers in Edit mode and they will not mess with your editor.
Can re-enable them back when enter the game.
RE: Frequent crash after assign the FluidPassCompute - spikebor - 12-05-2024
I have this bug when pack the fluid solver in a prefab and spawn them in play mode.
package: https://drive.google.com/file/d/1rEWCgX9s7hSuCtD7QhZkK9FPdOJ5zJ_9/view?usp=sharing
log: https://drive.google.com/file/d/19wXd_TA661pCWgp7dlDESsPQy_UkAiJV/view?usp=sharing
The ObiRigidbody.cs call this
Code:
private void UpdateVelocities(float stepTime)
{
// differentiate positions/orientations to get our own velocites for kinematic objects.
// also useful for animations.
if (unityRigidbody.isKinematic && stepTime > 0)The bug is easy to reproc, can disable the solver's gameobject in edit mode, then after enter play mode, enable the gameobject.
Or spawn a prefab with the fluid solver setup inside.
Somehow the system wants to have solver already on a visible gameobject on start, or else it will throw errors.
RE: Frequent crash after assign the FluidPassCompute - josemendez - 13-05-2024
(12-05-2024, 09:59 AM)spikebor Wrote: I have this bug when pack the fluid solver in a prefab and spawn them in play mode.
package: https://drive.google.com/file/d/1rEWCgX9s7hSuCtD7QhZkK9FPdOJ5zJ_9/view?usp=sharing
log: https://drive.google.com/file/d/19wXd_TA661pCWgp7dlDESsPQy_UkAiJV/view?usp=sharing
The ObiRigidbody.cs call this
and crash the Editor. In further debug, I saw that it calls in the Solver's gameobject, but the Solver's gameobject does not actually have any ObiRigidbody there.Code:private void UpdateVelocities(float stepTime)
{
// differentiate positions/orientations to get our own velocites for kinematic objects.
// also useful for animations.
if (unityRigidbody.isKinematic && stepTime > 0)
The bug is easy to reproc, can disable the solver's gameobject in edit mode, then after enter play mode, enable the gameobject.
Or spawn a prefab with the fluid solver setup inside.
Somehow the system wants to have solver already on a visible gameobject on start, or else it will throw errors.
Hi,
I'm unable to reproduce this. Tried adding a ObiSolver+ObiEmitter to a prefab, and:
- Disable the solver GameObject in editor, then enable its once in play mode.
- Instantiate the prefab at runtime.
The unity package you shared only contains a couple fluid blueprints (Spikebor/Integration/Runtime/Obi/Fluid/Data) a blend file and a couple prefabs (Spikebor/Integration/Runtime/Obi/Common/FBX). There's no scenes or scripts in its, so I've tried spawning both pool prefabs but no error takes place. Could you share a scene that reproduces this issue?
kind regards,
RE: Frequent crash after assign the FluidPassCompute - spikebor - 13-05-2024
(13-05-2024, 10:01 AM)josemendez Wrote: Hi,
I'm unable to reproduce this. Tried adding a ObiSolver+ObiEmitter to a prefab, and:
- Disable the solver GameObject in editor, then enable its once in play mode.
- Instantiate the prefab at runtime.
The unity package you shared only contains a couple fluid blueprints (Spikebor/Integration/Runtime/Obi/Fluid/Data) a blend file and a couple prefabs (Spikebor/Integration/Runtime/Obi/Common/FBX). There's no scenes or scripts in its, so I've tried spawning both pool prefabs but no error takes place. Could you share a scene that reproduces this issue?
kind regards,
Hello bro, sorry for the unprofessional report. Now I've packed a new complete package for better report.
package: https://drive.google.com/file/d/1_MhPsBkThpVSDLhTKHN6UZaYMU8PxzYb/view?usp=sharing
can also use my PipelineAsset at Assets/Spike/SpikePipelineAsset.asset, test with Unity 2022.3.16f1 and URP 14.
In this you will find :
Scene: Assets/Spike/Scenes/Test OBI.unity
When you start the game, you can have these buttons on screen.
Button Group 1:
Spawn Fluid, Spawn Ball, Spawn Dino.
This group will spawn those actors into the "masterSolver", which letting the fluid to be mixed, and fluid can collide with balls and dino.
Button Group 2:
Spawn Small Pool, Spawn Big Pool.
Those are different than Group 1 because each pool has its own Solver, not using the masterSolver.
Last button: Clear spawned: this can clear both those from Group 1 and 2, to re-test with different scenarios.
Problem with button Group 1 (ObiBone vs other actors):
The balls and fluids can interact with each other as intended. But the Dino will likely crash the Editor.
I suspect because the dino with ObiBone is using the ShapeMatching constraint, and it crash the Editor because when the fluid spawn, particles of the fluid also try to shape matching with the ObiBone of the Dino, which is very wrong. But what to do in this case? where I want the ObiBone to interact with the Fluids and Softbodies, it should share one masterSolver with those right? If the Dino has its own solver, then it will ignore the other actors.
Before going to testing Group2, pls clear them all by using the last button.
Problem with button Group 2 (Pools):
Start with spawning the SmallPool, everything will be great.
But as soon as you spawn the BigPool, or clear, and respawn BigPool a few times, you will hit the point where Editor crashes.
This part I have no idea what may cause this.
Those smallPool and bigPool prefab also can have a chance to crash the Editor when you open them. Look into the gameobject TEST in the scene with the script TestObi, it has references to those pool prefabs.
Another question about Fluid:
So each Emitter has their ObiFluidSurfaceMesher with different asset data, like for example different VoxelSize.
If my game scene make use of 5 different ObiFluidRenderingPass assets for different kind of fluids, should I add them all to the RendererFeatures list?
If I have too many of them in the list, will they affect performance? Or is there better workflow that I'm unaware of pls tell me thanks.
Best regards.
RE: Frequent crash after assign the FluidPassCompute - josemendez - 14-05-2024
Hi!
Thanks for the detailed repro! I was able to reproduce the issue following your instructions. Now working on it.
(13-05-2024, 05:33 PM)spikebor Wrote: I suspect because the dino with ObiBone is using the ShapeMatching constraint, and it crash the Editor because when the fluid spawn, particles of the fluid also try to shape matching with the ObiBone of the Dino, which is very wrong. But what to do in this case? where I want the ObiBone to interact with the Fluids and Softbodies, it should share one masterSolver with those right? If the Dino has its own solver, then it will ignore the other actors.
Shape matching constraints are only used by ObiSoftbody, and are in charge of keeping the overall shape of the softbody. They are not used by ObiBone, or dynamically added to fluids, or anything similar. The crash seems unrelated to shape matching constraints, from what I could see so far.
(13-05-2024, 05:33 PM)spikebor Wrote: So each Emitter has their ObiFluidSurfaceMesher with different asset data, like for example different VoxelSize.
If my game scene make use of 5 different ObiFluidRenderingPass assets for different kind of fluids, should I add them all to the RendererFeatures list?
If I have too many of them in the list, will they affect performance? Or is there better workflow that I'm unaware of pls tell me thanks.
FluidRenderingPasses only need to be added to a RendererFeature if they are transparent (or otherwise require to know the thickness of the fluid to calculate transmission, in case you're using a custom shader). Opaque rendering passes don't need to be added to a RendererFeature.
Having many FluidRenderingPasses may affect performance, since fluid meshing and rendering is performed once per rendering pass. This is similar to having many materials in a scene. You should aim to have as few rendering passes as possible.
kind regards,
RE: Frequent crash after assign the FluidPassCompute - josemendez - 14-05-2024
Found the cause of the crash: invalid memory access in ComputeFluidMesherSystem.cs, due to indirect command buffers of reused fluid passes not being initialized to zero.
When destroying a existing fluid mesher component and then creating it anew on the same frame, it attempts to render the new one using the old contents of the indirect buffer which points the GPU to invalid memory. This results in undefined behavior, including the possibility of a crash.
Working on a fix, a patch will be available shortly!
RE: Frequent crash after assign the FluidPassCompute - spikebor - 14-05-2024
(14-05-2024, 01:18 PM)josemendez Wrote: Found the cause of the crash: invalid memory access in ComputeFluidMesherSystem.cs, due to indirect command buffers of reused fluid passes not being initialized to zero.Thanks bro, that was fast!
When destroying a existing fluid mesher component and then creating it anew on the same frame, it attempts to render the new one using the old contents of the indirect buffer which points the GPU to invalid memory. This results in undefined behavior, including the possibility of a crash.
Working on a fix, a patch will be available shortly!