[x3d-public] 3D Format converter database request and Convert Maya .ma to something to X3D or X3DV

John Carlson yottzumm at gmail.com
Thu Sep 21 18:30:41 PDT 2023 

Before you tell me the AI response, “use Blender” tell me which version of
Blender—I’ve tried 3 of them on my desktop. I’ve tried renaming the file to
.fbx—no go.  I haven’t tried Omniverse yet.

In a former life, I wrote a Prolog program to tell me all options (paths
between tools) to convert from one image format to another image format,
that’s not too difficult to write.  I haven’t got a good database this time.

If someone can offer a database of formats different tools or database of
websites that can convert to or from a format, I think I can still write a
program that tells one the possible paths to take.  I just lack data at
this point.  If I can reimplement the “all paths” program (minus cycles, of
course), I can offer it to any party, open-sourced.  I would rely on the
data, of course, which is the hardest part.

John

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

> 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/9dc7b8d4/attachment-0001.html>

More information about the x3d-public mailing list