Procedurally generated models

[benwiley4000]

Using components developed in #18, and distributed container classes developed in #21, render procedurally generated models in our 3D world

• [x] Create a set of children component entities which are transformed according to a procedural modeling algorithm
• [x] Order component children with like components adjacent to optimize drawing step
• [x] Expose normals for lighting?

Algorithm inspiration

[benwiley4000]

In addition to the "Algorithm inspiration" above it might also be worth looking at the Procedural Modeling section in the Angel textbook (Chapter 9).

[KNG-Scherezade]

Looked at #21. Will have to add in positioning and a span function to the TreeA class. When you get up the spacing algorithm I'll see what needs to be done and how to do it.

Currently my algorithm uses a lot of inline code that could be cleaned into a more modular and abstracted format, but I'm worried about the time loss produced by abstracting this code and adhering to "good programming principles". Seriously, CPU based generation of trees is time expensive even for something simple due to the constant rotations and translations required to generate a branched shape. I'm going to look for more optimizations, but I'm going to suggest that the loading of tree objects be done at a staggered rate of one tree per frame.

[benwiley4000]

Thanks for the update @KNG-Scherezade! Keep in mind we'll be generating the trees when we cross world tile boundaries, but not more often than that, so we can afford to run something more expensive than we would want to run every frame.

My suggestions:

1. Try to cover #18 - render some components on screen with some sort of shading so we know the pieces we're dealing with.
2. Get some form of this algorithm, however you like, into the code and commit to git.
3. Later we can make changes to optimize or organize the code - thanks to git we can always go back if we don't like a change we made. No need to feel nervous about changing code! :smile: Just remember to commit early, commit often, so it's not hard to revert a change we might regret.

P.S. Have you tested your code/run any benchmarks? I'm curious, though I seriously wouldn't worry about this right now since we can always change the code later. I think the main priority should be making something that works and is understandable to others, since it will be harder to iterate if it's hard to read!

[KNG-Scherezade]

• #18 is done as soon as I put on a shader and change the code a bit to meet what you specify. • Is up in one condensed file. •Will split the condensed into segments for readability. I ran a few worst cases and it feels as if most games do procedural generation of complex structures on other threads so they don't alter the main loop's run rate. I'll do a few more benchmarks later and post results.

[benwiley4000]

I think multi-threading isn't a bad idea. Do you think we could save that for the optimization phase?

[benwiley4000]

I basically said this already, but we might want to wait on multithreading. Given that our current tile discard/load process happens all in one frame, we'd have to change things up a lot if we wanted to make good use of multithreading for trees.

I think it's a good idea, but probably not important enough to cause the initial integration of this code to wait longer than it needs to! :smile:

[benwiley4000]

This is almost done! Once we have normals for Trees we'll be good. cc @KNG-Scherezade

[benwiley4000]

DONE!