Closed voxelias closed 2 years ago
Is there any reason we don't make this a formal system defintition? I think it would be useful in more than one place as we already need a similar fix to the light binding system. Otherwise if a car with lights moved the lights would be trailing the mesh.
I also use this binding system (that really should be load) for a few of my storage buffers because they are used in multiple shaders. Having a formal pre-render stage would be a good place to put any buffers that need loading after standard updates and before any renders.
I would keep bind
at the place where it is now, adding a new RunLevel
for the pre-rendering stage is possible though. Any naming suggestions? Must be a verb. At this moment only load
comes to my mind.
We could call it pre_render
to really make it clear when it is fired. Or maybe prepare
as in prepare for render
pre_render
sounds best for ne
IMAO pre_render
is missleading. When something is prerendered, it means it is rendered already. While we speak about really a preparation for rendering.
With the same success we can add a system with high priority at rendering stage BTW
This sequence gives sense and seems logical for me.
For you don't? Maybe it is worth to rename the Standard RunLevel as well.
I think we should try not to worry to much about the name. Let's just go with load. As long as it's well documented.
I think perhaps I could rework the shader example to load the uniform in this stage. That would help make it clear what it's intended for too.
I do wonder about putting compute here though. I think compute would imply compute shader. Which you would want to fire after the uniforms and storage buffers are loaded but before render.
I feel that compute should be for the compute shader:
Standard: Load and update the world Load: Prepare buffers with worlds last state Compute: Gpu alterations to the buffers, clipping etc render: Using the buffers from cpu or altered by compute to render the scene
Alternatively the render stage could be renamed to combine compute as part of it. I was reading aboue metaI and found our that read that the order of compute/render are handled by the device so if a compute shader binds a texure as write and the render as read of the same texture buffer the device should schedule the compute before the render stage (and ensure it finishes)
We can do some research. I personally like standard
much more than compute
.
UE calls that tick
.
Unity calls that update
.
I think it can look somehow like this:
I am not sure about load
.
Another way is the priority. What about to set priority by some customizable enum where you can define execution order?
Another way is the priority. What about to set priority by some customizable enum where you can define execution order?
There is already the Priority::Custom(u32)
that allows to put a system at any place of specific RunLevel.
Ok, here is the final call:
/// Defines when and how often a system should run.
#[derive(Debug, Eq, PartialEq)]
pub enum RunLevel {
/// One time execution on application startup
Startup,
/// Execution on the beginning of each frame
Bind,
/// Execution on every frame for most of the calculations and updates (Default)
Update,
/// Execution on every frame to load data to GPU buffers right before rendering
Load,
/// Execution on every frame to submit compute passes
Compute,
/// Execution on every frame to submit rendering passes
Render,
/// Execution everytime after a frame was rendered
Release,
/// One-time execution after window resizing
Resize,
}
That looks good for me :)
bind
system toload
to change the run level