We've been working hard on getting the new 3d API off the ground. First up: probably most of what is in core right now will have to be revamped.
So my suggestion is that instead of improving the core, let's try and focus our time at coming up with a more future-proof version. If you want to follow and contribute to the 3d API there's a new branch for it on github: new3dapi. Of course, nothing is "stable" on the branch - but let's try and keep it clean and compiling.
Here'a run-down on current status:
Most of my time is currently invested in creating a functional FBX converter that will work independently of Libgdx. The FBX converter is heavily based off the work gameplay3d has done. We've wrapped their classes and added some additional features on top. The output of the FBX converter is a clean, and easy to read JSON format. You can have a look at the specifications here (still WIP): https://docs.google.com/document/d/1nz- ... eU69g/edit
The idea is that the asset workflow will be something like this: modeller -> obj/fbx/dae file -> converter -> json (binary or text) -> libgdx json loader. Because the converter is written in C++ we can distribute an executable without any dependencies.
The fbx converter currently supports:
- Support for Mesh Parts (basically a list of indices affected by a specific material)
- Multiple UV channels
- All the standard stuff (normals, various primitive types, etc.)
- Nodes can have children
- Nodes can have meshparts or bones attached to them
- Nodes contain the material -> meshpart relationship, so each meshpart can have a separate material id.
- Basic material types: Phong & Lambert
- Standard material attributes: Diffuse, Ambient, Emissive, Spec & Shininess
- Holds a list of textures
- Textures support UV translation & UV scaling
So, static model requirements are all there. Only big thing missing is Skinning & Animation information.
This is the loader that we use on the Libgdx side. It currently only reads basic mesh & material information. We're working on getting this to a renderable state and on par with the converter features.
The idea is that the loader takes the json format and produces a StillModel, SkeletonModel or a KeyframedModel from it. The KeyframedModel would be sampled at load time to produce a memory heavier version, but better performing.
Personally, I'd like this loader to become the go-to loader and we deprecate the other loaders in favour of a streamlined asset pipeline via the FBX converter. It'd make the core code lean & easy to maintain. Plus the json format is easy to work with. We obviously want the loader to support both a binary as well as a text version of the format.
What do you guys think?
As a general note: We're planning on making the new 3d API focused on OpenGL ES 2.0. Moving forward it makes a lot of sense and I'd say that anyone wanting to make a a serious 3d game is going to use shaders anyway. Anyone got any objections?
To make all of the above work with Libgdx we will need to revamp quite a few things in the process. The model class will need to be overhauled to support hierarchy. We also need to come up with a new Material system. Would love to hear your guys' ideas on how we should best design those classes.
Another aspect kalle_h has worked on quite a bit is the Renderer system. The idea is to make something similar in approach to SpriteBatch. Basically you throw any Model class (with assigned materials) at the Renderer and the Renderer will take care of the sorting, and optimising the render pipeline. The Renderer will also include goodies like a Light system.
The idea is that ModelRenderer is an interface that is implemented in a default renderer we supply. However, anyone is free to add their own implementation of the ModelRenderer to suit their needs & opimisations. It'll allow for easy swap-out depending on the needs, without having to rework the entire render code.
There's a lot of work already done towards a default renderer (PrototypeRenderer), but we'll have to go over it again once we've added all the new features.
Finishing thoughts: Let's get a discussion started with ideas & comments on where we want to take this baby. Ultimately it'd be fantastic we have a solution that's as easy to work with as Box2d & SpriteBatch using our ModelRenderer & Bullet.