That would make sense if i was using both update and fixedupdate. However like i said i only use fixedUpdate ( unless an internal update still occurs and has different frame rate ,so there is an issue like you said) How can achieve only with update the fixed 10msec time per frame i want?
I also have another issue i noticed (it doesnt seem to be cause of sorting). When i move the camera a bit in a specific direction the particles disappear and reappear if i move from that direction
If i move a bit to the right
And moving again more to the right they reappear
This is a gif in which i move around the particles as you will see in a frame it disappears
It’s irrelevant if you’re only using fixed update, the engine renders frames after the update loop, and fixed update is potentially called multiple times per update. I’m talking engine level fixed update and update. See that execution order link.
And you don’t do it with just a fixed update. Like I said, it’s good for physics and the like that need a fixed time step. It’s totally valid to run the particle physics in fixed update, but render them only in update. That is in fact how Unity does a bunch of internal stuff.
I’m guessing that’s using the “old” method where you have a few thousand quad meshes placed in the scene and are updating their location via the shader rather than using an explicit Draw command? The location where the game objects are placed is going out of view and being frustum culled. Since the CPU does the culling, it doesn’t know where, or even if, the GPU is moving them. That’s going back to the start of this thread and why I recommenced using DrawMeshInstancedIndirect to begin with.
This is the result of DrawMeshInstancedIndirect, so why does that happen?And i dont move them i just have initialised a position array then i pass it to a buffer in the shader. At update i call DrawMeshInstancedIndirect and the shader based on the id of the instance access a position in the structuredBuffer i passed and uses that to place the particle
This is it basically
Above is the Start and u can see the update and an init function which is called at start
Try using larger bounds?
2 Likes
It seems it gets fixed if i set the Bounds to 1000
1 Like
Yeah i guess it applied the bounds to the one quad which gets instantiated
Thank you for your help i really appreciate it you saved me from days searching. I am searching right now about sorting in compute shaders or order-independent methods. And about the fixed update you suggest setBuffers of data per 0.01 of the shader and at update draw call.
Another +1 to be able to completely disable frustum culling.
I’m writing a job to do occlusion culling and the first step is to do a manual frustum cull before doing the more complex occlusion cull, which means Unity also doing a FC is now pointless.
This is especially true since I am using jobs for the heavy lifting meaning the usual things like MeshRenderer.isVisible is a bit useless cause I will have to do those checks on the main thread.
If on the other hand I had access to a raw list of currently rendered meshes that I could throw into a job, that would be great and let me use both nicely.
I could use the CullingGroup API but that feels like a fiddly mess + data duplication.
As a side note I stumbled on this thread because I thought Unity would have a way of disabling/enabling the frustum cull in the scene view so I can sanity check what a specific camera is seeing but oh well.
1 Like
Well, the right way of doing this would be via GPU culling, or rather GPU not drawing things to begin with so have you thought about using DrawMeshInstancedIndirect?
Yup, wont make sense.
I use GPU culling for things I’m instancing with that such as grass but this occlusion culling system is for the meshes to make up the world (Minecraft-esq game) so each one is unique and cant be baked ahead of time
Not seeing why that would change anything? It is still an ideal use-case so far.
Ah ok I might have missed your point.
Each mesh is unique so I would have to call DrawMeshInstancedIndirect once for each mesh. My assumption is you were trying to say I should try to draw everything with one DrawMeshInstancedIndirect call, which is what I can do with grass etc but is impossible with unique meshes.
Are you then saying I call DrawMeshInstancedIndirect once per mesh and thus by calling it culling wont happen?
If so, interesting…
Is there going to be any extra overheads doing that? I’ve always used it with the assumption that its better for drawing lots of things in one call.
Edit:
Ah duh I’m with you now, this is what I get for trying to think when sick. I now need to change my systems to be more manual and get rid of MeshRenderers entirely. Instead I register a manual draw call using the results of my job to only submit the calls I need that frame.