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

John Carlson yottzumm at gmail.com
Mon Nov 25 23:40:58 PST 2024 

Note that I can probably do this in __init__.py if allowed.

On Tue, Nov 26, 2024 at 1:37 AM John Carlson <yottzumm at gmail.com> wrote:

> AFAIK, if I don’t change any settings, in the old version of Blender
> import,  One would not get a model with +Y up.  When I specify +Z up, +Y
> forward the model lies down, is in the proper X3D space—but +Z is up with
> respect to the viewer in Blender.  So I change the Viewpoint by hitting
> Number Pad 7, and everything looks kosher, except for the floor.  So I
> erase the standard floor and add my own floor grid object in the X-Z plane.
>   Then I delete the new floor on export.
>
> Will this work for everyone?
>
> Thanks!
>
> John
>
>
> 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/20241126/f69afea0/attachment-0001.html>

More information about the x3d-public mailing list