Rendering optimization notes

[omni-viral]

Here we may put our notes and ideas about rendering optimizations.
I'll start with a few.

• Cache constant buffers. Don't update if not modified.
  With help of slide-rs/specs#291.
• Use indexed meshes to reuse vertices.
• Move to gfx_hal
• Mark static geometry.
  • Batch it. Reuse secondary command buffers. Optimize static lighting.
• Discard meshes that falls out of cameras frustum. Mesh is required to have known AABB.
  • collision-rs can help to optimize it further.

[Rhuagh]

I would do frustum culling in user space, and make it possible to use a marker component for visibility

[Rhuagh]

I would do frustum culling in user space, and make it possible to use a marker component for visibility

[Rhuagh]

pub struct Visible;

impl Component for Visible {
    type Storage = NullStorage<Visible>;
}

and use that in the join in the passes.

[Rhuagh]

pub struct Visible;

impl Component for Visible {
    type Storage = NullStorage<Visible>;
}

and use that in the join in the passes.

[Rhuagh]

Or maybe the opposite would be better, NotVisible and !NotVisible in Join, that way those that don't care about frustum culling don't need to do anything.

[Rhuagh]

Or maybe the opposite would be better, NotVisible and !NotVisible in Join, that way those that don't care about frustum culling don't need to do anything.

[omni-viral]

@Rhuagh Wouldn't it be nicer to do visibility query in renderer? Consider multicamera setup

[omni-viral]

@Rhuagh Wouldn't it be nicer to do visibility query in renderer? Consider multicamera setup

[Rhuagh]

It's a fairly expensive procedure, and something that I consider optional.

[Rhuagh]

It's a fairly expensive procedure, and something that I consider optional.

[Rhuagh]

If you have 8 meshes in total, you're gonna lose performance by doing it.

[Rhuagh]

If you have 8 meshes in total, you're gonna lose performance by doing it.

[omni-viral]

I agree on that frustum culling should be optional.
But I'm not agree about using marker components for this purpose.
It's better to query visible meshes from Camera + Transform + SpecialSortedStructure. Probably with some caching.

[omni-viral]

I agree on that frustum culling should be optional.
But I'm not agree about using marker components for this purpose.
It's better to query visible meshes from Camera + Transform + SpecialSortedStructure. Probably with some caching.

[Rhuagh]

I don't agree.

With user space culling we allow the user to come up with their own culling techniques without having to duplicate our pass code. Some users may need occlusion culling, z-culling, frustum culling, distance culling. I don't think we should add all of those culling techniques to the renderer crate, but provide systems that can do these things externally.

[Rhuagh]

I don't agree.

With user space culling we allow the user to come up with their own culling techniques without having to duplicate our pass code. Some users may need occlusion culling, z-culling, frustum culling, distance culling. I don't think we should add all of those culling techniques to the renderer crate, but provide systems that can do these things externally.

[Rhuagh]

And by putting it in user space, we also enable the user to use the visibility data for their own systems.

[Rhuagh]

And by putting it in user space, we also enable the user to use the visibility data for their own systems.

[omni-viral]

Good point. But still those culling methods results are local to camera.

[omni-viral]

Good point. But still those culling methods results are local to camera.

[Rhuagh]

Some are yes, some aren't. Distance culling for instance can be done without the full camera matrix, you only need the position of the camera (or the controller entity, which might be a different entity).

[Rhuagh]

Some are yes, some aren't. Distance culling for instance can be done without the full camera matrix, you only need the position of the camera (or the controller entity, which might be a different entity).

[omni-viral]

I mean that for another camera you have another results

[omni-viral]

I mean that for another camera you have another results

[Rhuagh]

Sure. My point is that it should be up to the user to decide what culling to use, and where, so they can reuse the results of the culling themselves if needed.

[Rhuagh]

Sure. My point is that it should be up to the user to decide what culling to use, and where, so they can reuse the results of the culling themselves if needed.

[omni-viral]

Maybe we can have Culled attached to Camera. And in this component will be bitset with bits set to meshes culled by any technique.

[omni-viral]

Maybe we can have Culled attached to Camera. And in this component will be bitset with bits set to meshes culled by any technique.

[omni-viral]

If nobody fills Culled for specific Camera then renderer will render all meshes

[omni-viral]

If nobody fills Culled for specific Camera then renderer will render all meshes

[Rhuagh]

Possibly, I'm not sure what the performance/usability difference would be.

[Rhuagh]

Possibly, I'm not sure what the performance/usability difference would be.

[Rhuagh]

But it's not a bad idea.

[Rhuagh]

But it's not a bad idea.

[omni-viral]

Difference with what approach?

[omni-viral]

Difference with what approach?

[Rhuagh]

Using components.

[Rhuagh]

Using components.

[omni-viral]

It should be close to marker component in performance. And allows multiple cameras

[omni-viral]

It should be close to marker component in performance. And allows multiple cameras

[Rhuagh]

That's a good point.

[Rhuagh]

That's a good point.

[Rhuagh]

I reordered the comment above btw, to reflect what I think is a good order to do the improvements in :)

[Rhuagh]

I reordered the comment above btw, to reflect what I think is a good order to do the improvements in :)

[omni-viral]

I agree with this order. I was writing them in the same order they were coming in my mind 😄

[omni-viral]

I agree with this order. I was writing them in the same order they were coming in my mind 😄

[omni-viral]

@Rhuagh There is already an issue about skinning. This one is about optimizations we can add into renderer.

[omni-viral]

@Rhuagh There is already an issue about skinning. This one is about optimizations we can add into renderer.

[torkleyy]

Caching should be easy soon:

slide-rs/specs#291

Look at the tracked example.

[torkleyy]

Caching should be easy soon:

slide-rs/specs#291

Look at the tracked example.