Scene Graph
Like GLScene, FMX is based on a scene-graph, and more precisely a variant with roots and concepts from the ancient 3DStudio (DOS era), you can see cut down versions of them in FMX: the Camera/Target approach and the Dummy being the most obvious. Similar concepts exist in other scene graphs, but typically with different terminology and slightly different (cf. Ogre, Blender, OSG…).
The FMX scene-graph was however simplified/crippled in several ways:
- the primary design-time orientation is absolute angles, that’s problematic because rotations aren’t commutative in 3D space, and there are such things as gimbal lock to cause trouble. If relative rotations are practical beyond simple demos, for real world use, absolute angles are not, you need well defined orientation, which means vectors (ie. matrix) or quaternions.
- the camera model has been over-simplified, leaving out such key aspects as field of view, depth of view and near plane bias. While the first two are key for obvious reasons, the near plane bias is just as important. Because of the maths behind the depth buffer, it is the single most governing factor to numerical accuracy of the depth buffer (and minimize artifacts known as Z-fighting).
- the scene graph is rendered hierarchically (see below).
The absolute angles orientation existed in GLScene from very early on, and over the years, grew to become a major source of frustration for users, ending up with tutorials dedicated to explaining why they were frustrating, and why you should move away from them.
Unless you’re an airman or accustomed to working in a roll/pitch/turn environment, rotations in 3D just won’t always behave as you expect they should. It was kind of a let down to see this mistake repeatedso prominently in FMX.
The hierarchical scene graph rendering was actually GLScene’s original approach, it’s one that feels quite simple and natural, but it also grew over the years to be a factor holding back the library, and had to be worked/hacked around in different ways. Once again, it was a disappointment to see that FMX was based on GLScene’s old approach.
A better solution is to separate the rendering from the scene graph, this is useful and even required in various scenarios:
- required to render semi-transparent objects, all techniques for handling opacity require a non-pure -hierarchical rendering
- facilitates handling of visibility culling, ie. not rendering what isn’t visible, because it’s off-camera, beyond the field of view, occluded by opaque objects, etc.
- required for deferred shading and other multi-pass approaches (either for shading, shadow volume, etc.)
As a consequence, FireMonkey can’t even render scene graphs containing semi-transparent objects correctly if you don’t manually order them… That’s a major letdown.
Next: Materials and Textures.
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.