Design the high-level drawing layer above gfx-rs

[kvark]

As we are getting settled with the scope (see #108), we should start thinking about the layer above gfx-rs. I hope to see it as a separate projects in our gfx-rs organization, where this issue is the ideas hub for the initial design.

Here is what I expect this layer to do:

• Define a concept of Material. For starters, we can just use gfx::ShaderBundle for it.
• Define a spatial system: world space, connections, and hierarchies. This would probably lock it to a particular math library (e.g. cgmath-rs)
• Define a concept of DrawList
• Automatically re-order calls inside each draw list

[photex]

Dropping some items here free association style:

• skeletal animation (supporting shaders, higher level types for the required vertex format?)
• tools to bake data (geometry, materials, textures, animation?)
• settle on an engine format for common data (and provide apis to easily load. and save?)
• primitives builders (geo-sphere, icosahedrons, cubes, grids/planes)?
• Scene graphs... scene managers, oct-tree, quad-tree? etc.
• visibility determination (start with simple frustum intersection tests perhaps set the stage for other methods)
• A spine runtime would be compelling.

These are clearly parts of multiple projects and some are pretty wishy-washy. I'm a fan of the scope of gfx right now. I don't think it should get much higher level than a graphics device abstraction. The next step is to build on top of gfx.

[ghost]

visibility determination (start with simple frustum intersection tests perhaps set the stage for other methods) Define a concept of DrawList Automatically re-order calls inside each draw list

These get my +1. They could be inter-related, creating a drawlist and culling it could be done as part of gfx-rs.

[kvark]

Found a couple of interesting links:

• SceneJS explains how the scene graph is constructed. I can see the great potential in this if different node types are abstracted away.
• Panda3D explains how split rendering into App/Cull/Draw phases that are done on separate threads.

So my basic understanding of the high layer is the following. It defines the scene graph, where materials and spatial nodes are just possible node types, there should also be means of serializing/deserializing it. The user builds this graph on his side and passes it to the layer over the task boundary. The layer does visibility culling, skeletal animations, and sorting. Maybe something else too. The final draw list is provided to our Renderer (either one by one or in some kind of groups, we'll see later), which (again) sends commands to the device over the task boundary.

Primitive buiders are a separate thing, and I think @photex and @bjz already thought about making a library about procedural generation that would cover that.

[kvark]

[kvark]

The drawlist concept is mostly defined in #209.

[kvark]

Nominating gfx_scene for this role.

[bvssvni]

I've looked over the gfx_scene source and it looks promising.

[kvark]

The ecosystem has been expanded to include gfx_pipeline, claymore_scene, and claymore_load (sub-crates of claymore). It is now as high as we could ever be:

let pipeline = gfx_pipeline::forward::Pipeline::new(...);
let scene = claymore_load::scene(...);
...
pipeline.render(&scene, ...);

Please evaluate these libraries at some time to see if they can fit the role. I'm pretty much done with the general architecture, so I'll be focusing more on the game itself, hopefully.

[kvark]

gfx_scene has been transferred

[kvark]

Closing because of the following great libraries:

• Amethyst
• GGEZ
• ThreeRS