Materials and Textures
This is another major roadblock, FMX is using approaches similar to the original GLScene one, that proved problematic and later had to be worked around.
The default material is very limited, and defined into the objects. A better approach (like later GLScene) would be to have them in a material library (which is to materials what an action list is to an action, it allows reuses and centralizes them). With Delphi XE2 property editors, this could have been done in a painless and convenient fashion.
The standard texture model is too limited too, not only are textures not shared (they should live in a library) they also lack basic properties. Sharing textures is key when you don’t have a lot of video memory, or when that memory is slow and not dedicated (like on an iPad, or a business PC). You also need at the very least to be able to control texture wrapping/clamping and texture filtering (mipmap generation and trilinear filtering at the very least).
The lack of mipmapping and anisotropic filtering have implications on performance and rendering quality, the lack of texture built-in texture compression support has performance implications. The COLLADA Viewer demo f.i. exhibits aliasing and pixel shimmering issues because of it.
Provision for 3D textures should also be made, those are almost useless in games, but useful in a business 3D engines (f.i. in medical visualization).
Shaders are for all practical purposes handled as if FMX was a pure game engine: you need pre-compiled shaders, you don’t have a unified cross-platform high-level shader compiler (like Cg) or generator component (writing shaders by hand gets old very fast, as it quickly becomes a combinatorial problem).
All in all, materials aren’t well supported by FMX at design-time, you’re left with having to write your own code to manage material libraries. That just isn’t what you would expect from a general purpose or business 3D engine.
Meshes
Once again, FMX goes for a limited approach similar to that of early GLScene versions: having a specific mesh object for each mesh format, and no standardized mesh format (well there is an embryo of one, but it’s too limited, and the COLLADA viewer skirts it f.i, the 3DS demo before it skirted it too). This is compounded by the scene-graph and materials limitations: the mesh object has to handle its own rendering and its own materials.
This is problematic because it means any form of advanced mesh-based algorithms have to be written against specific mesh objects. This impacts everything mesh-related from imports/exports, manipulations, optimizations, animations (skeletal animations, morphs, etc.) to rendering (extracting silhouettes, BSP, bounding boxes, occlusion etc.) to interaction (collision testing, etc.).
Next: Candencing and animations
Like you, I find it a shame it didn’t expand on the best bit of GLScene, and leave the bits that were designed for a very different GPU world behind.
Related to the gimbal lock issue, they’ve chosen to apply changes to angles relative to the current orientation, which means that if you adjust an objects orientation in the property editor, it will most likely move as you expect, but the order that you change the properties then becomes important.
If you have 2 objects + change the angles in order x,y then z for one object, you will get a different orientation if you adjust z, y and then x for the second object. i.e. it doesn’t apply the rotation angles in a fixed order from the origin.
This will mess with animations, and confuse people who are trying to line up objects.
For example, if after adjusting the angles you then try resetting the value to something like (0, 0, 0.0000001) then depending on what order you changed the properties, it may not being anywhere near the default position of (0,0,0). If you then adjust the angles to (0,0,0) it treats it as a special value + snaps back to starting position.
All this 3D stuff goes way over my head but you appear to have made a well argued case so I would endorse your view that such broad changes should be made now, before people like me start to get our feet wet.
Excellent article, Eric, and I agree with what you say above here. They need to sort this out now.
So for “real” 3D stuff we should use GlScene instead? Can it be made cross plaform then? (FMX uses OpenGl on Mac + iOS).
Or will both “projects” be merged? (“…porting some of GLScene code to FireMonkey…”)
@André
GLScene is already cross-platform and has been for a while (though FreePascal & Lazarus). There are other 3D cross-platform libraries for FreePascal for that matter.
At the moment, as far as 3D goes, FMX is just not up to scratch on any aspect IMHO, but if the correct provisions are made, it could be built upon.
Though in it’s current state, you would have to basically start from scratch sinc you can’t change the FMX source to implement those provisions, like the COLLADA Viewer sample does. And still, as the COLLAD Viewer sample shows, its performance and rendering quality are very sub-standard, not to mention that having to write shaders by hand (3 versions of each shader if you want cross-platform…) isn’t really practical.
@Dan Bartlett
Uh, the situation with angles is then worse than I thought.
Since the started from scratch with no code-base, it could have been a great opportunity to build upon modern hardware, it’s really annoying that not only they didn’t, but that they repeated mistakes and made them worse.
I take it there’s no chance Embarcadero could hire you as a consultant WRT this stuff…?
@Chris
Up to them. I’ve notified them of this already sometime ago while helping locate GLScene code in FMX so it could be replaced (for free).
There are several other major GLScene contributors, like Dan, that they could take counsel from, as well as members from the broader “Delphi 3D community” to draw upon (okay, maybe less these days than if they had started working on FMX half a decade ago… ah, so much time wasted…).
(and let it be clear, I’m not looking for a consulting job, I’m already full-time employed, I’m looking to having a solid foundation in Delphi that can be built upon)
If Embarcadero is really serious about making (3D) FireMonkey the future for Delphi, then they should really take your advice and, with your time permitting, hire yourself and the other contributors into getting the 3D stuff onto the right footing. The longer they leave it, the harder and more expensive it will be for them to fix in the future. They also run the risk that if the existing implementation stays in place, they may lose the interest of developers in using 3D FireMonkey all together.
I really hope someone in Embarcadero is taking notice of this.
I have better header for this article “Dark side of 3D in firemonkey”.
It’s just a small piece from huge list of problems with this render.