Introduction / Guide

[ghost]

It would be useful to have some guide on how to use and integrate this api with a project.

I have been mostly working backwards from what claymore and the beta example are doing to figure it out. It's been a bit error prone.

[kvark]

:+1: for your heroic effort. I didn't expect it to be too hard, please keep in mind the spots that took you most trouble to get.

[ghost]

Some area's I would like to highlight that gave me trouble.

• Having the example Scene in gfx_scene causes some confusion (Do I roll my own or use it)
  • This caused secondary confusion as I needed to figure out how to build my own Scene and got confused at the role of the gfx_phase might have. A phases enqueue function looks like a simple scene, but serves an completely different purpose.
• The AbstractScene trait is actually not that abstract since it required the use of the Culler. The code I ended up with is nearly identical to what is found in gfx_scene's example Scene since you need to drive the Culler in one way to make it useful.
  • This might be better as a function for now. I'm not 100% Sure.
• Figuring out what should be the World trait. I think World might be a bit general for what it actually does (supply position transforms)
• It's possible to use a generic transform, but currently only Decomposed<f32, Vector3<f32>, Quaternion<f32>> actually supplies sufficient traits to work. (I wanted to use it in the long run, but in the short term using raw Mat4 is easier, skeleton_animation just uses Mat4 so this will need to be explored again(I forget which traits were missing))
• An Entity is a struct that we must use to use gfx_scene.
  • - This should probably just be a trait
• Using Flat is unusable in gfx_pipeline, Only Forward is actively used by claymore
• The Material is supplied by gfx_pipeline I don't need my own.
• gfx_pipeline has a naming convention for attributes that must be followed.

Once all the types aligned correctly, the library works fine. The amount of code needed to directly drive gfx_scene with gfx_pipeline is only about 60. A few more to add the traits to get access to position information ect.

[kvark]

Thanks for analyzing and writing this up! Certainly a lot to implement and discuss here.

[kvark]

1. (Having the example Scene ...) I see. We need to document this better somehow.
2. (AbstractScene trait is actually ...) But actual Culler type is an implementation detail, even though it's not very nice currently, since Scene just uses Frustum culler and provides no choice. The AbstractScene main goal is reduce the "bus" communicating with the higher-level code, namely "gfx_pipeline".
3. (Figuring out what should be the World trait ...) I'm :+1: to redesign, simplify, and maybe even rename this trait. It seems to intersect with the Entity trait proposal.
4. (It's possible to use a generic transform ...) Totally, it was designed to support matrices on par with decomposed transformations. I think Euler would work out of the box instead of Quaternion. What's stopping AffineMatrix3 from being used exactly (which is the same as Matrix4)?
5. (An Entity is a struct that ...) I don't mind a trait. In fact, there was a trait in gfx_phase which I removed for simplicity. I was thinking that one could compose Entity into their own object instead of implementing a trait, since the drawing at some level just works with an iterator over entities, which is easy to get. In other words, I'm not sure if the complexity that Entity trait would add is worth it.
6. (Using Flat is unusable in gfx_pipeline ...) Oh is it? It's a recent addition. I wanted to keep this simple pipeline so that I can move Forward forward (sorry for the play of words ;))
7. (The Material is supplied ...) Right, but only IF you are using gfx_pipeline. I'd expect serious projects to roll in their own rendering pipelines (not constrained by gfx_pipeline interfaces) with their own materials.
8. (gfx_pipeline has a naming convention ...) This absolutely needs to be stressed in the docs, I agree.