|
From: Colin G. <col...@gm...> - 2025-02-11 15:57:11
|
On Tue, 11 Feb, 2025 at 13:39:53, Fernando García Liñán via Flightgear-devel wrote:
> > GlTF knows about blender origin points, and uses them as center for
> > animations, which gets rid of the <center> (which imo was the most
> > painful part of animations).
>
> This behavior is not backwards compatible, which means that if you want to
> port your aircraft to PBR/glTF, you need to change all of your animations
> and origin points. On the flip side, it seems to be much more comfortable in
> the long run (no manual copying of the model origin to fill the <center> tag
> of the animation) and significantly reduces the size of the model XML.
Here's a summary of my very short experience with doing exactly that:
Short version is: currently, translation/rotation/etc. animations are
in global coordinates for AC3D files, but local coordinates for glTF.
So to port from AC3D to glTF, you have two choices to fix animations:
(1) Reset all origin points and transformations in blender,
so that local coordinates = global coordinates
(for the benefit of anyone as bad with blender as I am:
'right click -> set origin' and 'ctrl-A (for apply)' respectively)
(2) Set sensible origin points and transformations in blender,
and update all animations to use local coordinates
(which should mean setting trivial centers and axes)
(1) is probably quicker, (2) is the 'more confortable in the long run'
If it were about making a new model from scratch, then for sure (2)
would be way better: setting the origin in blender is much easier than
measuring it in blender and copying to the xml file.
I don't find (2) to be that bad, largely because I essentially have to
go over the entire 3D model to port to PBR anyways, and fixing these
animations is among the simplest tasks.
(But that might be to blame on the ridiculous amount of custom effects
Nikolai and I used on the Viggen, your experience might differ if you
were more reasonable!)
One big advantage of using local coordinates as glTF does right now
is the ability to have a single very complex model file (say, the entire
cockpit as one file) instead of many small files, while keeping the XML
animations sane.
I think there are a lot of advantages to this: easier to share textures,
creating ambient occlusion maps and the like, and I know Richard
advocates for it in the name of performance.
I know people who actually know how to do 3D modelling did that anyways,
and dealt with the IMO insane XML files this implied. Personally,
I wouldn't dare to do more than one panel in a single AC3D file.
Sorry for the wall of text!
Best,
Colin
|