Previous: Textures and Materials.
Cadencing and Animations
When doing animations, be it a simple following of a spline path or simulations, you need to refresh the display periodically, after having all the scene elements updated.
Typically that involves a so called “game timer”, which triggers at a fixed frequency (usually that of the display, or a fraction of it), along with a frame stepping/progression logic that can handle frame skipping (so that you don’t end up having the UI lag the user when the hardware can’t keep up). You also need a time reference, preferably global and not looping.
Well, FMX only has an embryo of such an architecture, and it is not pervasive. Also the cross-platform time reference (TPlatform.GetTick) returns a single precision floating-point value that can loop… double ouch. Might as well take the opportunity of a new framework to Do It Right.
In GLScene, cadencing wasn’t in initially, and adding it after the fact took time, especially to make it pervasive, pity FMX didn’t build it right into the framework.
Conclusion
All the above points are fixable, but they’re also fundamental missing aspects for doing 3D with FireMonkey, if you don’t want to replicate huge portions of the framework (cf. the COLLADA Viewer sample).
They mean that if you want to achieve anything beyond a few poorly texture objects, you’ll need to design and write a lot of custom code rather than rely on the framework… with obvious implications of obsolescence and compatibility issues whenever FMX finally gets the features in standard.
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.