7 hours ago, Dirk Gregorius said:
I agree that you want to be able to author a rotation pivot in *tools* (e.g. scene or cutscene editors). But why do you want this for run-time?
Custom scene editors tend to aim at giving you basically a real-time "preview" of your result. "WYSIWYG" editors such as those in Unreal Engine and Unity are examples of this. You might be more used to editors in which you export your work and then run elsewhere, but the main purpose of a scene editor is to tie everything together after that step. By that point, anything your run-time does not support is something your artists can't edit in the scene editor. If you stick to tracks and expose as many properties as you can, then artists can easily continue how they are used to working and each property they can edit is one more level of expression your in-game scenes/characters can have.
Of course there is always a trade-off between features, memory, and run-time overhead, but one factor to remember before simply eliminating a property to save run-time costs is that dirty flags can allow you to skip a lot of work. If your pivots and offsets are identity (meaning they generate an identity matrix) then you can entirely skip the parts where they are combined for the final result and your cost has become simply and if(). Checking for identity can be done just when those values change, and in my 2nd post I explained a dirty system to allow this. That means a slight-bit more work when they change, but we are definitely talking about things that almost never change here. So simply handling these properties is almost free and saves you the trouble of revisiting the code 2 years later when an artist actually does want to change a pivot in real-time.
7 hours ago, Dirk Gregorius said:
Note that I am not exporting a matrix as you suggest in your post, but I collapse all tracks into three (translation, rotation, scale). Are you arguing that the pose at each frame will be noticeable different from composing the matrix from each track at run-time?
No, they are functionally the same, because I still have to decompose my matrix into exactly the same thing you get. This is why I said they are basically both baked systems with only a slight difference. This was my first engine and naturally poorly designed, so I had to decompose the matrices at run-time because I had idiotically chosen to have the matrix responsible for more than it should have been and tried to use it as the only representation of an object orientation rather than as the product of combining those properties.
So, here, I am not complaining about the overhead of decomposing as much because that was my own fault, but the fact that a matrix is a lossy representation of the orientation. Some matrices (which are perfectly valid in real games) do not decompose at all (https://computergraphics.stackexchange.com/questions/4491/detect-a-lossy-matrix-decomposition), and you also can't tell if only 1 scale has been inverted or 3. That's a real problem when you want to assign custom tracks to a single scale property etc.
7 hours ago, Dirk Gregorius said:
Run-time animation systems are usually designed for performance and memory. What you are describing seems more computational and memory expensive then it needs to be. A final pose in a game is usually a combination (blend) of many active animations in the game.
Forward kinematics, inverse kinematics, and basic blending do account for the majority of all animations, but more and more forms of dynamic animations are gaining demand, and the last thing you want is to lose a contract because your engine can't handle the demands. Note that IK automatically forces you to expose more properties than the baked values because you need constraints etc.
7 hours ago, Dirk Gregorius said:
Good looking animation is about hitting strong expressive keyposes which I do and it is what the animator ultimately is authoring. The more I think about it the less understand the benefit of what you are suggesting. What is the problem your system solves for a run-time animation system? Maybe with an example...
It's not related to accuracy at all. They both express the animation the same, until you want to start to take control of the finer details in a more dynamic way, at which point baked animations start to show cracks. If you wanted to change a pivot or offset at run-time you simply can't with a baked system.
Why would anyone do this?:
-
It's not our job to decide when and why a game might want to do this; it is our job to empower the game to be able to do it.
-
But an actual example could be where a robot gets an arm dislocated in a fight like bent metal and now starts to rotate around a slightly different point, or if you allow the player to take a part off a machine and reattach it. These are very reasonable demands these days.
My point is more about functionality, because the run-time overhead is nearly the same. It looks as though you are spending a lot of time combining a bunch of matrices to get the final result, but most of them are identity and you can if() them out of the process in virtually all cases, plus you are likely to implement a run-time track system anyway, and you will find that you are able to connect tracks to anything but rotation and scale (position is of course unchanged when stored in a matrix), which will hopefully leave you saying, "What the hell did I just do?"
All of this is coming from real-world examples. You're going to make your own scene editor no matter what so you can combine all the different elements from other tools into one, and you necessarily are going to end up with new properties that don't exist in Maya or whatever authoring tool you use.
At this timecode you can see a good example of a real-world application: https://youtu.be/_gEm_WjMy88?t=52
His left monitor is the in-house scene editor where you can see trillions of custom properties you can apply to provide game-specific adjustments that Maya (right monitor) can't (and as per today's standards it is WYSIWYG).
Here is an example of that same editor being used to adjust a more global scene: https://youtu.be/_gEm_WjMy88?t=118
And what are you going to use to animate the clouds (which are fully procedural and can't be animated in Maya)? Tracks and curves!
https://www.youtube.com/watch?v=Y_0OCZC8TVY
The color changes in the clouds, the cloud swirls, the wind, the particles, everything driven by tracks and curves.
This game is an extreme example to be bringing in here, but I ran into these exact issues very early in my first engine as soon as I wanted to animate anything beyond models. I shot myself in the foot and there is no reason anyone else needs to lose a foot over the same issue.
2 hours ago, mrMatrix said:
To sync with the game loop I need the delta time per frame like L.Spiro said, but how do I stay in sync with reading from my XML file if things get heavy and bogged down ? Do you have any next steps after your previous example? I made this XML file from reference from the TLang1991 tutorial.
Everything in that XML file (which is still not an appropriate file format for models) should be loaded into memory at load-time. Nothing here needs to be streamed in in real-time.
L. Spiro