[x3d-public] X3D, Blender, and which way is up.
John Carlson
yottzumm at gmail.com
Mon Nov 25 08:11:57 PST 2024
Vince, typically, I run the script outside of blender. I don’t really have
a clue if it runs inside blender well.
The export function in the script takes axis up and axis forward
parameters, like X,Y, Z, -X, -Y, -Z (with quotes I think).
If someone wants to follow along in projects .blender.org, I’m yottzumm
there. Interested parties can get a link, but it’s pretty easy to figure
out.
Here’s a sample script:
https://github.com/coderextreme/X3DJSONLD/blob/master/blend/importJoe.py
(Just download this one file, and change the model and exports to suit
you—watch file names).
On Mon, Nov 25, 2024 at 8:20 AM vmarchetti at kshell.com <vmarchetti at kshell.com>
wrote:
> 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.
>
That is my understanding. What I have done is include HAnimHumanoid,
HAnimJoint and HAnimSite in getFinalMatrix(). Since no transformations are
applied to joint centers (Blender bone head and tail), the skeleton can
appear outside the mesh if there aren’t skin weights. Plus any animation
at key=0 can also affect the skeleton and skin—when weighted.
With Blender bones, there’s no matrix_world field that I know of. There’s
matrix, matrix_basis and matrix_channels. So setting these might be a
paramount thing to do.
I have not tried transforming joint centers, except for swapping and
negating Z and Y. My old import settings no longer work.
>
> 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,
>
I don’t use the UI import/export much. AFAIK, that’s all available in
Python. Take a gander at __init__.py and see if you still think nothing’s
happening, there’s a certain amount of fuckery there. For example, look
for wherever global_matrix is being used.
I hope by my explanations things will get clearer. All kinds of pictures
are on the Blender website under Issues and the Discussion. The best
solution seems to be create a fake floor in the X-Z plane, and erase the
real one.
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?
>
A fixed choice would be good, but i think swapping the up axis and the
forward axis (not in the defaults or selection) might actually work for
HAnim and animations. This is pretty much a breaking change. Recent
updates seem to make the animation uncoordinated.
I do like pinning Joe Kick on his back so he screams +Z over and over into
the air towards +Z (joking). Actually, I just move the viewpoint.
I can run with my version of the importer, but I would prefer to develop my
loader separate from any Blender work, because it’s more X3D-like and
includes X3D nodes which are passed through Blender, such that someone can
name the object appropriately and get an X3D node on output with the
correct name. (Say I wanted to create something with a Sphere tag on
export).
Ultimately the loader/exporter I’ve been working will probably be merged
into a new addon, but that’s a long ways away. It would be faster to add
HAnim to the existing exporter, and I might have a bit of code for that.
Note that I’m currently working on an armature and a skin.
>
> 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/9d3f5ac3/attachment-0001.html>
More information about the x3d-public
mailing list