[x3d-public] XML schema motionsEnabked addition; Maya converter

Thu Sep 21 17:47:40 PDT 2023

And yes, creating a good XML schema entry for HAnimHumamoid.motionsEnabled
is challenging for me, *right now*.  I’m hoping to get some help with it in
the next couple of days.

But a good Maya .ma to .x3d or .x3dv converter recommendation is higher
priority, and  I could use it this evening.  File size is 89MB.

I already went chasing down FBX to X3D converters before settling on
Blender.

What the idiot solution?  Renaming the extension?

John

On Thu, Sep 21, 2023 at 7:29 PM John Carlson <yottzumm at gmail.com> wrote:

> See the problem is, I just found a glitch in my email.
>
> motionsEnabled is part of HAnimHumanoids.  (credit to Doug Sanden)
>
> On Thu, Sep 21, 2023 at 7:21 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> I agree, write a good specification, then let the programmers have at
>> it.  I am a research prototyper and non-professional tester and pretty
>> awesome at finding glitches.
>>
>> And there are several currently outstanding in XML Schema, no
>> motionsEnabled in XML Schema. HAnimMotion joints and channels fiields are
>> MFStrings in XMLSchema, but SFString in x3d4.
>>
>> I’ve been trying to get a report out, including diffs.  These are
>> critical to generating good XML and VRML code with x3d.py.
>>
>> WS is a priority.  Can someone recommend a good Maya .ma to .x3d
>> converter before I go traipsing around the universe finding one?
>>
>> John
>>
>> On Thu, Sep 21, 2023 at 6:56 PM Brutzman, Donald (Don) (CIV) <
>> brutzman at nps.edu> wrote:
>>
>>> Negative scaling is certainly a special case and not something that has
>>> historically been supported in VRML or X3D. Thanks for careful
>>> consideration of any unexpected variations.
>>>
>>> Our design goals make it clear that we have no desire to vary from glTF
>>> in X3D 4.0. If there are any recommendations needed for authors to maximize
>>> and hopefully achieve full interoperability with glTF rendering, they are
>>> always welcome.
>>>
>>> v/r Don
>>> ------------------------------
>>> *From:* x3d-public <x3d-public-bounces at web3d.org> on behalf of Holger
>>> Seelig <holger.seelig at yahoo.de>
>>> *Sent:* Thursday, September 21, 2023 2:56:48 PM
>>> *To:* Joe D Williams <joedwil at earthlink.net>
>>> *Cc:* Andreas Plesch <andreasplesch at gmail.com>; X3D <
>>> x3d-public at web3d.org>; holger.seelig at googlemail.com <
>>> holger.seelig at googlemail.com>
>>> *Subject:* Re: [x3d-public] Negative scale and winding order
>>>
>>> Unfortunately, I can't just change something that has been implemented
>>> this way since the beginning of X_ITE's existence. The way X_ITE handles
>>> negative scaling is exactly the way it is specified in glTF, which is not
>>> bad and is implemented in CGE under the term Robust Negative Scale. Until
>>> everything is thought over, I have to agree with Andreas with his advice to
>>> just set the solid field to false, as it is the easiest way to avoid this
>>> issue.
>>>
>>> Best regards,
>>> Holger
>>>
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>>
>>> Am 21.09.2023 um 19:24 schrieb Joe D Williams <joedwil at earthlink.net>:
>>>
>>> So perhaps the question is how to apply negative scale transforms
>>> tonormals as intended by the spec.The Leif example has ccw=false and a
>>> negative scale (for z). Itappears as outside in on x_ite and outside out on
>>> view3dscene andx3dom.
>>>
>>>
>>> Of course I am interested in this because to me the X_ITE rendering is
>>> wrong, unless that is, the player is required to reverse the normals for
>>> scale z = -1.
>>> X_ITE is 'automagically' reversing the normals, so when I do the
>>> ccw=FALSE the  thing  is transparent from the front of the polygon. Of
>>> course if I use ccw=TRUE then the  other tools look like X_ITE, transparent
>>> from the front.
>>>
>>> Holger, can you please either convince the other players they are wrong,
>>> or fix yours to work like the rest. If the spec is not certain what to do
>>> about this, then please either fix the spec or X_ITE.
>>>
>>> I just want the model to show as intended and be correct, even if sort
>>> of a practical hack, so please l figure it out because I really need
>>> everyone to do the right thing on this, whatever that might be.
>>>
>>> . Thanks and Best Regards,
>>> Joe
>>>
>>>
>>> -----Original Message-----
>>> From: Joe D Williams <joedwil at earthlink.net>
>>> Sent: Sep 19, 2023 1:26 PM
>>> To: Andreas Plesch <andreasplesch at gmail.com>, X3D Graphics public
>>> mailing list <x3d-public at web3d.org>, <holger.seelig at googlemail.com>
>>> Subject: Re: [x3d-public] Negative scale and winding order
>>>
>>> While this approach is very practical, I am not sure what the
>>> spec.actually requires in this respect.
>>>
>>>
>>> I did not care, it worked and I will look more later. The following is
>>> all good. I think the players show it different because the user code is
>>> changed from what I sent.
>>>
>>>
>>> Sorry I sort of wrote this off, to both you and Holger.
>>> A good, reliable solution to this problem is needed, as learned or not
>>> from recent experience.
>>>
>>> One thing I think happened to me was seeing that common graphics
>>> authoring programs use as a 'Native' default or pre-selected +Zin with
>>> left-hand rule for axis rotations.
>>> For the Humanoid animation, we want to align ourselves in +Zout
>>> character space, so the character Front is looking out of the screen with
>>> +y up, +x to character left. In the case of x3d +Zout, the character is
>>> gaze is toward +z. In the case of +Zin, the character Front gaze is toward
>>> -z. Or, we may find the situation where the character is drawn in +Zin with
>>> gaze toward +z.
>>>
>>> For HAnim there are three main issues: skeleton and skin and animations.
>>> Well, actually these boil down into just one problem: They all have to work
>>> together. So to even consider importing stuffs drawn or animated in a
>>> different space a plan is needed. I used standard features to force display
>>> of skin because it was drawn in a different space. This almost worked
>>> everywhere.
>>>
>>> I think it should work everywhere, because the -1 for z scaling is going
>>> to operate just the same as if I had actually negated the coord points(?).
>>> Since the +Zin model with scale 1 1 1 will be seen as facing -z the
>>> character's back is toward the x3d default camera. Using scale 1 1-1
>>> operates so that the character is now facing the x3d default camera.
>>> However, just guessing, since the polygon that was drawn ccw true is now
>>> being drawn ccw false and is now transparent from its front. Changing ccw
>>> to false seemed to get the normal aimed in the right direction.
>>>
>>> Thanks for the help,
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Joe D Williams
>>> Sent: Sep 19, 2023 11:09 AM
>>> To: Andreas Plesch , X3D Graphics public mailing list
>>> Subject: Re: [x3d-public] Negative scale and winding order
>>>
>>>
>>> -----Original Message-----
>>> From: Andreas Plesch
>>> Sent: Sep 19, 2023 9:03 AM
>>> To: X3D Graphics public mailing list
>>> Subject: [x3d-public] Negative scale and winding order
>>>
>>> Holger made good points on why a negative scale in the parent
>>>
>>> transform should not affect which side of a geomet is considered
>>> facing outward and visible with solid=true.
>>>
>>> OK, I thought I tried that with no effect.
>>>
>>> While this approach is very practical, I am not sure what the spec.
>>>
>>> actually requires in this respect.
>>>
>>> I did not care, it worked and I will look more later.
>>> The following is all good. I think the players show it different because
>>> the user code is changed from what I sent.
>>>
>>> First, it does not explicitly single out the case of a negative scale.
>>>
>>> Should it ? If so, it would probably have to deal with the effective
>>> world transform.
>>>
>>>
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/rendering.html#CommonGeometryFields
>>>
>>> 'The ccw field defines the ordering of the vertex coordinates of the
>>> geometry with respect to user-given or automatically generated normal
>>> vectors used in the lighting model equations. If ccw is TRUE, the
>>> normals shall follow the right hand rule; the orientation of each
>>> normal with respect to the vertices (taken in order) shall be such
>>> that the vertices appear to be oriented in a counterclockwise order
>>> when the vertices are viewed (in the local coordinate system of the
>>> Shape) from the opposite direction as the normal. If ccw is FALSE, the
>>> normals shall be oriented in the opposite direction. If normals are
>>> not generated but are supplied using a Normal node, and the
>>> orientation of the normals does not match the setting of the ccw
>>> field, results are undefined.'
>>>
>>> has the relevant ccw field language.
>>>
>>> I think the specified process is:
>>>
>>> - Compute the outward facing normal of a triangle using the ordering
>>> of the vertices in such a way that the ordering appears
>>> counterclockwise when viewed in the opposite direction of the computed
>>> normal. This uses the local, untransformed (raw) coordinates.
>>>
>>> - invert the normal if ccw=false.
>>>
>>> - Apply the accumulated transforms to both the vertices and the
>>> computed normal. The spec. has a strict definition on how to apply a
>>> transform to vertices to transform from the child space to the parent
>>> space. For normals transformations there is a computer graphics
>>> standard approach and probably opengl based equations but the spec.
>>> itself seems to be silent.
>>>
>>> So perhaps the question is how to apply negative scale transforms to
>>> normals as intended by the spec.
>>>
>>> The Leif example has ccw=false and a negative scale (for z). It
>>> appears as outside in on x_ite and outside out on view3dscene and
>>> x3dom.
>>>
>>> A workaround is solid=false but that may not always be possible or
>>> desired.
>>> Another workaround is to not use negative scales/mirroring, eg.
>>> preprocess geometry accordingly which seems like a major limitation.
>>>
>>> -Andreas
>>>
>>> On Tue, Sep 19, 2023 at 10:37 AM wrote:
>>>
>>>
>>> Send x3d-public mailing list submissions to
>>> x3d-public at web3d.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> or, via email, send a message with subject or body 'help' to
>>> x3d-public-request at web3d.org
>>>
>>> You can reach the person managing the list at
>>> x3d-public-owner at web3d.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of x3d-public digest..."
>>>
>>>
>>> 2. Negative Scale
>>>
>>> A negative scale will not affect what is front face and what is back
>>> face. This means that a Text node with solid true, mirrored with negative
>>> scale (0 -1 0), also shows its front face to the camera. This makes it
>>> possible to create a text with solid true which has a mirrored counterpart
>>> which is a clone of the Text node.
>>>
>>> A negative scale will not turn the model inside out, it stays as it is.
>>> The main advantage is as described above: we can use solid true models in
>>> many situations where a negative scale is used without flipping inside out.
>>>
>>> This effect is achieved by detecting if there is any negative scale,
>>> which can be determined if the determinant of the scale-rotation matrix is
>>> less than zero. If this is the case, ccw must be exchanged with cw and vice
>>> versa.
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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/20230921/06ab4225/attachment-0001.html>