[WIP] Gfx Renderer

[ghost]

Basically from a high level command are abstracted away from the data in the rendering pipeline. Commands are matched to a Method that can work with it's data. Right now that is just based on the render target and the Command itself. I think this can expand in the future.

Users can add their own targets and their own methods to the Renderer, and in addition replace methods. This replacing could be neat for doing something like a shader toy.

Right now I have a basic flat shading pipeline, and a terribly unoptimized deferred lighting. But it should be easy to to keep adding new passes and build a library of useful ones.

Demo of it working: https://www.youtube.com/watch?v=m3Q_3behpPA

Problem areas:

• No texture support yet
• The mesh format is static, we will need something like gfx_mesh to allow for multiple formats without static types
• Resizing of buffers is incomplete
• Single threaded

[kvark]

you can use let (buffer, slice) = factory.create_vertex_buffer_with_slice(&sphere, ());

[kvark]

There is too much format! noise. I understand that we need to receive String there, but maybe we can help it by adding some constructors like amethyst_render::Draw::new("main", "main")?

[kvark]

I'd much prefer the passes to be constructed in advance, and then you'd have passes: vec![pass1, pass2] in the frame construction code. Modifying passes[i] directly can be error-prone during refactoring.

[kvark]

we could have something like this as a helper:

frame.add_target("gbuffer", amethyst_renderer::GBuffer::new(..));

[kvark]

should probably extract those dimensions from the main_color

[kvark]

the default passes could be something simpler for this example since you already have this code bound on Key1

[ghost]

Yeah, need to pull out the description of the passes into a function.

[kvark]

uh oh, ok
this is apparently what forces you to do all these R::* : Any constraints when implementing Method

[ghost]

I think I can add a magic trait that will make this prettier, one of the todos.

[kvark]

Shouldn't Pass and Framebuffer be associated types? This would reduce the mental overhead of reading the trait and improve clarity. Unless there are cases where the same struct implements methods for different passes and framebuffers.
Nitpic: framebuffer is a very GL-specific name. I'd prefer Target, which happens to match T.

[kvark]

you don't seem to have newlines at the end of the files

[kvark]

I wonder if making a trait instead of this function would allow you to remove the Pass boxing, thus stripping the need to derive from Any for passes.

[kvark]

Reminder: this PR is not to be merged, since it is targeting the wrong branch.