3D API features and demo

[Gadgetoid]

I've rebased this and cleaned it up to use the latest and greatest SDK features- IE: asset pipeline and metadata.

TODO:

1. Change demo 3D model away from to something befitting our open license
2. Fix texture mapping- currently has a manual loop through objects/faces and samples the textures in user code - @lowfatcode might have done this somewhere in a local git repo far far away. Should probably be Object::update_textures() or similar.
3. Unbreak VS .sln ( curse you VS, curse you! ) (Note: Have done this by simply reverting to master)
4. Document how the heck to prepare .obj files and associated textures
5. "object" should be "Object" and "load_obj" should probably be Object::load for consistency with the rest of the API
6. 3d classes and types should be moved into the engine
7. Rendering is currently very custom, maybe groups should have visibility and rendering is either Object::render or Renderer::draw(surface, object)
8. Add 3d-demo to the VS .sln

[zenodante]

I’m also working on a pure C (and some inline asm) 3D engine for 32blit. In 8bit lut model with light effect and 16bit z buff. So the framebuff and z buff could fit into the 225kB framebuff area.

[Gadgetoid]

That's a good approach, the float z-buffer in this code is extremely ambitious and predictably causes the whole thing to explode in hires mode. By hacking in a 16-bit buffer (I don't have much of an idea what I'm doing here) I can make it run in hires, but the memory cost is going to be pretty high ( as you've determined ).

This is old and messy code that's really not ready for engine integration so if you have something better that would slot into the API then by all means make it a PR and we can throw this away or compare notes before Jon notices anything is up 👀

[zenodante]

You could try mine at zenodante/Basic-3d-lib2. If you copy the mesh/texture data into ram, it would be faster.

[Gadgetoid]

I wonder if any of this still works, and is still worth considering. At one point we were looking at some interesting 3D dungeon assets but it never really got anywhere and the PicoSystem isn't quite there for 3D (despite some amazing demos).

Do we draw the line at making this a 2D-only library SDK?

[Daft-Freak]

Could be a separate library? (Currently 99% of the code is in the example, seems it doesn't need to be that close to the SDK)

[ali1234]

Given the limitations of the hardware, I don't believe there is any single "right" way to do 3D, so leaving it up to external libraries seems like the way to go. For example it can be done without a depth buffer by sorting the triangles before drawing them. That is what newkind does.

[Daft-Freak]

Out of curiosity I ended up trying to run this (it crashes unless I hack out any calls to screen.text for some reason, probably memory related...).

Then ported the example to my renderer.

(https://github.com/Daft-Freak/32blit-examples/tree/3d)