This post was actually written sometime ago, alas XE2 Update 1 didn’t change much.
I’ve been looking at FireMonkey 3D side, by that I mean strictly the 3D side, not the UI components, or the 2D. Here are some observations, most born from maintaining and developing 3D software in C++ and later with GLScene, and with an eye to eventually porting some of GLScene code to FireMonkey (after all, most of GLScene’s code is actually linear algebra stuff, mesh manipulations, file format imports, etc. and not OpenGL-specific).
Note that everything below is fixable, most of it quite trivially, but Embarcadero has to lead by baking it into the framework, in the core classes & components. If they don’t and you implement it yourself, you’ll end up having to duplicate huge portions of the framework. Such a duplication will be a PITA when they realize they need it in the framework, and implement it… in a fashion that will likely be incompatible with yours.
Also note that implementing some of these will require either interface-breaking changes, still possible now IMHO, as FMX is still young, or hacks/workarounds later on (what happened with GLScene, might as well avoid that if they can).
Scope
FireMonkey is officially pitched at “Business” 3D (as opposed to 3D games), which isn’t that far from what GLScene is used for, as even if GLScene is used for gaming purpose, its bread and butter was as much business as it was gaming (cf. the galleries here and here).
Assuming we’re restricting the scope to real-time rendering engines, what differentiates a game engine for a 3D engine? In terms of pure functionality and capability, there is little specific, Unreal Engine f.i. encompasses a broad range of visualization and UI applications, the most differentiating factor is what the engine processes:
- A 3D game engine typically sits at the end of an assets tool-chain, and handles “ready to use” meshes, textures, shaders and other assets. The tool-chain is supposed to pre-compile and prepare everything, so that the game engine only has to deal with the rendering and interactivity.
- A business 3D engine on the other end sits at a higher level, it has to handle raw assets, which come out of simulations, data crunching, image libraries, etc. and do what’s needed to render them in robust, quality fashion, while handling gracefully a variety of situations and corner cases.
In the case of FireMonkey, target platforms are mobile devices, iPad and business machine GPUs: all these are rather low-end hardware, in terms of capability, performance and available memory. In other words, FMX can’t rely on having a powerful GPU with plenty of super-fast video RAM, but rather has to deal with paltry integrated chipsets which share RAM with the CPU.
Next: Scene Graph.
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.