[x3d-public] X3D, Blender, and which way is up.

John Carlson yottzumm at gmail.com
Mon Nov 25 17:39:09 PST 2024 

I understand Blender well enough swapping forward axis with up axis did
work well.  It’s another matter to get that change into Blender.

That’s the root of how Z got changed to -Z.

On Mon, Nov 25, 2024 at 7:09 PM Joe D Williams <joedwil at earthlink.net>
wrote:

> > Would it help your work with HAnim to have a version of the
> importer/exporter prepared for which the +Z Up and +Y forward is the fixed
> choice of orientation transform, meaning no x-y-z transformation is
> performed?
>
>
>
> I don't think so. That would be an admission that we do not understand
> some detail of how to deal with Blender.
>
> The only reason I say that is,to me, the info seems wrong on the face of
> it. If I have a z forward model and I import it by telling blender it is
> zup, then I don't understand. Then if the thing looks right and edits
> right, then to export It I tell it another wrong?
>
> Joe
>
>
>
>
>
> -----Original Message-----
> From: Extensible 3D (X3D) Graphics public discussion <x3d-public at web3d.org
> >
> Sent: Nov 25, 2024 6:21 AM
> To: X3D-Public <x3d-public at web3d.org>, John Carlson <yottzumm at gmail.com>
> Cc: vmarchetti at kshell.com <vmarchetti at kshell.com>
> Subject: Re: [x3d-public] X3D, Blender, and which way is up.
>
>
> Regarding the poblem with importing HAnim and supporting animation
>
> The problem seems to be that  when Blender imports an X3D in default
> settings, it does a coordinate transformation on the mesh coordinates, and
> it is difficult to apply a corresponding correct transformation on
> geometric operators such  as the rotations that are an integral part of
> HAnim - based animation.
>
> The X3D importer/exporter allows through the UI to configure the
> transformation through the choice of Up and Forward. The choices of +Z Up
> and +Y forward  leads to the identity transformation, that is x,y,z
> coordinates are unchanged.  The can be verified  with the model at
> https://drive.google.com/file/d/1lumRBRjqoygHCw88kwzcSKS5M-KxGXLf/view?usp=drive_link ,
> it is a 3.4 MB zip file. When unzipped it has a .x3d file of a sculpture
> head, with the scalp being at the +Y extremity and the sculpture is looking
> in the +Z direction. With +Z up and +Y forward import and export these axes
> are preserved in the imported blender scene and in the re-exported x3d
> scene,
>
> Would it help your work with HAnim to have a version of the
> importer/exporter prepared for which the +Z Up and +Y forward is the fixed
> choice of orientation transform, meaning no x-y-z transformation is
> performed?
>
> Vince Marchetti
>
>
> On Nov 25, 2024, at 5:09 AM, John Carlson via x3d-public <
> x3d-public at web3d.org> wrote:
> Probably this will be ignored.  Joe makes a valid point on this one.
>
> This comment is about X3D and Blender, not glTF and Blender.  “Sorted
> out,” but look at the coordinate axes with when you load a typical
> coordinate X3D coordinate axes (with x,y,z labels) into Blender.  Then look
> at what Blender thinks in the coordinate axes gizmo (see the bulbous X,Y,Z
> coordinates with red, green, blue coloring).
>
> Nothing has changed but defaults, AFAIK, which I have been trying to
> override.
>
> What we really want is Blender’s “floor” to be in the X-Z plane.  You can
> make the “floor” as a “wall” be in the X-Z  plane by choosing the correct
> viewpoint, but try to move the gizmo slightly.  What they’ve done is put
> the “floor” grid in the X-Z plane temporarily (as a wall).  Try moving the
> gizmo and watch the “floor” flip out of the X-Z plane.
>
> It’s a marketing ploy…the Emperor has no clothes.
>
> We’d be perfectly happy if we could select which plane the Blender “floor”
> was in, with no changes to the defaults.  In python, please!
>
> If you hit Num pad 7 in Blender, you will see the typical X3D viewpoint
> with +Y up, +Z towards the viewer, and +X to the right, just like you
> learned in high school, just like OpenGL.  The only problem is the floor is
> now a wall!  Indeed, it looks a lot like the Cartesian Coordinate System we
> all learned, with the grid in the a X-Y plane.  But wait, the grid is
> supposed to be the floor, I thought…
>
> Don’t look at the model!  Look at the gizmo!  Look at them both!
>
> I don’t know what Blender was thinking making the floor so hard to
> change.  If we could shift some concrete there, that would be great!
>
> The great trick is to make the standard floor invisible and draw your own
> floor, which I haven’t done yet because I’ve been struggling with
> elasticman.  If someone does that to you, try selecting the grid.  You
> can’t select the floor grid in normal Blender.  Zorro unmasked!
>
> Where’s this is really going to hurt everyone is when we try to introduce
> animations, that’s where elasticman steps in.  We’re going to have to apply
> Blender’s ideas to our interpolators.  That means negating z…what does that
> mean for orientation interpolators?  Just negate Z there?  Really, if
> someone has an answer for this, you earn a gold star in my book!  Euler
> angles with negated z???
>
> Hopefully we can solve animations without forcing everything to default
> X3D axes (which was what I was trying to do by setting up to be forward and
> forward, up—please check my math—I’ll probably change my Blender importer
> back to that).  That’s in __init__.py and can be set on import separate
> from export.
>
> What happens when you swap -Z with Z in your animations?   What do you
> also do on export?  Have we even considered export yet?
>
> Hopefully, the underlying code is doing rotation and not scaling!
>
> I think the safest bet is loading X3D models “laying down” and moving the
> floor underneath their feet.  This will give +Y above the models head, +Z
> in front of the model, and +X to the models left.
>
> I’m not seeing importing X3D animations into blender coming to X3D soon
> until everyone gets their heads out of the sand.
>
> I heard that HAnim was built on dead people’s measurements.  If we get
> more people’s eyes on the technical details, maybe Blender won’t kill X3D.
>
> I really like that Blender uses a right hand coordinate system!
>
> Oh, I believe you can set floor *constraints* for an object.  If you can
> set the floor constraints to the fake floor, maybe that would work?
>
> I sure wish it was as easy as swapping -Z for Z.  In my dreams!
>
> Does glTF animation work in Blender?
>
> I’m sure smarter people than me have been down this path, why HAnim is not
> implemented in Blender, why animation import is disabled, etc.  I’m just a
> math dummy who thinks it’s possible, indeed, I wrote an HAnim exporter that
> mostly worked with one use case.  No one gave me any other use cases, so I
> started my own HAnim importer.
>
>
> Perhaps we should only focus on Blender exports?  Anyone?   This seems
> like a higher priority.   But then, do we expect HAnim names? How do we map
> Transforms to HAnim?  Been there, done that:
> https://github.com/coderextreme/HAnimDecoratorAssembly let me know if
> someone wants me to work on that,  but I require HAnim names for
> Transforms.  My system is limited to 32GB.  For larger skins (500000
> polys), I’ll probably have to recode in something besides Perl.  X3DJSAIL
> is likely, if it’s ready to handle the workload.
>
> Maybe moving Blender’s floor is a bit like moving the lid of a coffin?
> https://youtu.be/6o2gISJYwQU
> <https://youtu.be/6o2gISJYwQU?si=uuCoKE8W_-6NBBEp> Motel is glTF, Blender
> is Tzietel, and Lazar Wolf is X3D?  That scene was pretty terrifying as a 7
> year old.
>
> Maybe we should fork Blender?
>
> Another thing I see with importing animations is PREF_FLAT equals True
> (current). This currently wipes out intermediate transforms, and puts them
> on shapes (there’s a hierarchy of shapes with associated matrices in
> blender).  So how the heck are we supposed to animate intermediate
> Transforms if they aren’t there?  This whole thing needs to be rethought.
> We should start by looking at creating EMPTY objects as Transforms, as Joe
> said.   Then we need to think about what to do on export.  Since I just
> tripped upon a hierarchy of shapes (Thanks, Katy), this whole thing might
> need to be thought out.  Fortunately, Katy’s example exports well with
> Blender’s exporter (but I’ve not tried recently, since the -Z/Z change.
>
> If people want to get serious about HAnim and animations in Blender, and
> have mental capacity to understand the issues with PREF_FLAT, the effect of
> animating X3D files in Blender with different coordinate systems and
> import/export of animations, especially skin weights, maybe we can talk.
> I’m yottzumm on Discord and I hang out in The CGE, MSF and Khronos servers
> (friend me).  I’m also on a Blender server, but there’s probably many.
>
> Maybe we should just prioritize creating glTF and OpenUSD from X3D?
>
> John
>
> On Sun, Nov 24, 2024 at 8:11 PM Brutzman, Donald (Don) (CIV) via
> x3d-public <x3d-public at web3d.org> wrote:
>
>> Your definition sounds good to me.  Glad to hear that this is
>> consistently sorted out and implemented in recent Blender version.
>>
>> Here are X3D Tooltip hints for Viewpoint and orientation:
>>
>>    - X3D Tooltips: Viewpoint
>>    - Viewpoint provides a specific location and direction where the user
>>    may view the scene. Viewpoints are the primary way for a user to navigate
>>    within a scene, and for an author to show critical aspects of a model.
>>    Unless modified by the orientation field, the default direction for a
>>    Viewpoint to look is along the -Z axis.
>>    - https://www.web3d.org/x3d/content/X3dTooltips.html#Viewpoint
>>
>>    - X3D Tooltips: Viewpoint orientation
>>    -
>>    https://www.web3d.org/x3d/content/X3dTooltips.html#Viewpoint.orientation
>>    - *[orientation accessType inputOutput
>>    <https://www.web3d.org/x3d/content/X3dTooltips.html#accessType>, type
>>    SFRotation <https://www.web3d.org/x3d/content/X3dTooltips.html#SFRotation>
>>    CDATA <https://www.web3d.org/x3d/content/X3dTooltips.html#CDATA> "0 0 1 0"]*
>>    Rotation (axis, angle in radians) of Viewpoint, relative to default
>>    -Z axis direction in local coordinate system.
>>    *Hint:* this is orientation _change_ from default direction (0 0 -1).
>>    *Hint:* complex rotations can be accomplished axis-by-axis using
>>    parent Transforms.
>>    *Warning:* for VR/AR/MR/XR users wearing a head-mounted display
>>    (HMD), animating this field may induce motion sickness.
>>
>> Improvements always welcome.  Have fun with X3D!  🙂
>>
>> all the best, Don
>> --
>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>> brutzman at nps.edu
>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>> +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics
>> https://faculty.nps.edu/brutzman
>>
>>
>>
>> ------------------------------
>> *From:* x3d-public <x3d-public-bounces at web3d.org> on behalf of
>> vmarchetti--- via x3d-public <x3d-public at web3d.org>
>> *Sent:* Sunday, November 24, 2024 11:39 AM
>> *To:* X3D-Public <x3d-public at web3d.org>
>> *Cc:* vmarchetti at kshell.com <vmarchetti at kshell.com>
>> *Subject:* [x3d-public] X3D, Blender, and which way is up.
>>
>> I've seen that the email thread starting with the minutes of the last
>> Blender-X3D support call had a subthread about the orientation conventions
>> that glTF, Blender, and X3D use.
>>
>> I recommend Michalis' answer at
>> https://web3d.org/pipermail/x3d-public_web3d.org/2024-November/020882.html
>> .
>>
>> One confusing aspect is that not only do Blender and glTF disagree about
>> which axis is forward, they disagree about what the word "forward" means.
>>
>> For Blender, the word "forward" refers to the axis that the viewer is
>> looking along when they are viewing the front of the model.
>> The viewer is translated from the model in the -Y direction, and they are
>> looking in the +Y direction. That, +Y,  is Blender "forward"
>>
>> glTF defined "forward" by the model.Looking at the first sentence of the
>> of section 3.4 of the glTF specification.
>> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#coordinate-system-and-units
>> ,
>>
>>
>> glTF uses a right-handed coordinate system. glTF defines +Y as up, +Z as
>> forward, and -X as right; the front of a glTF asset faces +Z.
>>
>>
>>
>> glTF says the "forward" refers to the direction the asset, a.k.a. model
>> is facing and the spec shows this example picture . In Blender terminology
>> this model is oriented "-Z forward"
>>
>>
>>
>> <boombox.png>
>>
>> The X3D standard has the same orientation convention as glTF, by virtue
>> of the X3D default placement of the Viewpoint at a Z=+10 position and
>> looking in the -Z direction. That is why in Blender terminology the X3D
>> convention should be considered -Z forward. The code in the Blender
>> extensions server was changed to this default for X3D import and export on
>> Nov 4 2024 and this default is in release 2.4.0 of this Blender extension.
>>
>> Vince Marchetti
>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20241125/fff44fd9/attachment-0001.html>

More information about the x3d-public mailing list