Its doesn’t generate a crash dump file or a crash auto save. Here is the file that gives the above error: OpFlow_ParticlesV1.toe (60.5 KB)
I also checked with this file below and same issue. All the files work fine in the latest production build. So it appears old files with GLSL Compute Shaders cannot be opened in Alpha 6 but the Cache TOP error was a bit weird. WeightedVoronoiStippling.toe (7.7 KB)
I am on a Windows 11, Nvidia Studio Driver v572.83. Thought I would point it out incase there is a backward compatibility issue that is not known, or some script in the shader needs to be altered for it to work.
Hello @somil.m
Thank you for reporting the problem. It appears that the GLSL Multi TOP and Atomic variables may also be contributing to the crashes. We will look into this.
Raising this issue here again, while it technically works, I am only getting ~1fps with this on the latest experimental 30770, while with 2023.11880 it runs at 60fps.
The performance monitor is showing a bottleneck at: /project1/optical_flow_particles_compute/filter_points/random_remap/express1 and /express2 that take about 670ms each.
I’m using the files linked above. Windows 11, Nvidia studio drivers 580.97 on a laptop woth a 4090.
It appears that the cooking dependencies in recent versions differ from those in previous releases.
In the experimental build, both /project1/optical_flow_particles_compute/filter_points/random_remap/express1 and /project1/optical_flow_particles_compute/filter_points/random_remap/express2 are being cooked every frame.
As you mentioned, this is what’s causing the major slowdown.
At this point, it’s unclear what the correct cooking dependencies should be, or what the expected behavior is.
For now, locking /project1/optical_flow_particles_compute/filter_points/null1 should ensures that express1 and express2 are not cooked every frame.
The bug seems to be with the Null CHOP, /project1/optical_flow_particles_compute/filter_points/info1 referencing width & height going into a Null CHOP set to selective is causing issues. The work around is replacing the Info CHOP with a Constant CHOP with channels resx, resy and expressions op(‘in1_velocity’).width, op(‘in1_velocity’).heigh. You do not need a selective Null CHOP as the width and height are not time dependent.
Hope this helps and I’ll let you know when the bug is sorted.
