<div dir="auto">See the problem is, I just found a glitch in my email.</div><div dir="auto"><br></div><div dir="auto">motionsEnabled is part of HAnimHumanoids. (credit to Doug Sanden)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 21, 2023 at 7:21 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I’ve been trying to get a report out, including diffs. These are critical to generating good XML and VRML code with x3d.py.</div><div dir="auto"><br></div><div dir="auto">WS is a priority. Can someone recommend a good Maya .ma to .x3d converter before I go traipsing around the universe finding one?</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 21, 2023 at 6:56 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<div dir="ltr">
<div></div>
<div>
<div>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.</div>
<div dir="ltr"><br>
</div>
<div>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.</div>
<div id="m_8573988425295601699m_-6065222937959768488ms-outlook-mobile-signature">
<div><br>
</div>
<div>v/r Don</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_8573988425295601699m_-6065222937959768488divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><b style="font-family:Calibri,sans-serif">From:</b> x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" style="font-family:Calibri,sans-serif" target="_blank">x3d-public-bounces@web3d.org</a>> on behalf of Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" style="font-family:Calibri,sans-serif" target="_blank">holger.seelig@yahoo.de</a>><br>
<b style="font-family:Calibri,sans-serif">Sent:</b> Thursday, September 21, 2023 2:56:48 PM<br>
<b style="font-family:Calibri,sans-serif">To:</b> Joe D Williams <<a href="mailto:joedwil@earthlink.net" style="font-family:Calibri,sans-serif" target="_blank">joedwil@earthlink.net</a>><br>
<b style="font-family:Calibri,sans-serif">Cc:</b> Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" style="font-family:Calibri,sans-serif" target="_blank">andreasplesch@gmail.com</a>>; X3D <<a href="mailto:x3d-public@web3d.org" style="font-family:Calibri,sans-serif" target="_blank">x3d-public@web3d.org</a>>; <a href="mailto:holger.seelig@googlemail.com" style="font-family:Calibri,sans-serif" target="_blank">holger.seelig@googlemail.com</a> <<a href="mailto:holger.seelig@googlemail.com" style="font-family:Calibri,sans-serif" target="_blank">holger.seelig@googlemail.com</a>><br>
<b style="font-family:Calibri,sans-serif">Subject:</b> Re: [x3d-public] Negative scale and winding order</font>
<div> </div>
</div>
<div style="line-break:after-white-space">
<div>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.</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Holger</div>
<div><br>
</div>
<div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)">
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)">
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)">
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)">
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)">
<div dir="auto" style="text-align:start;text-indent:0px;line-break:after-white-space">
<div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
--</div>
<div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
Holger Seelig</div>
<div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
Leipzig, Germany</div>
<div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
<br>
</div>
<div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a></div>
<div><a href="https://create3000.github.io/x_ite/" target="_blank">https://create3000.github.io/x_ite/</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div></div><div><div style="line-break:after-white-space">
<div><br>
<blockquote type="cite">
<div>Am 21.09.2023 um 19:24 schrieb Joe D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>>:</div>
<br>
<div>
<div>
<blockquote type="cite">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.<br>
</blockquote>
<br>
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.<br>
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.
<br>
<br>
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.
<br>
<br>
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. <br>
<br>
. Thanks and Best Regards,<br>
Joe <br>
<br>
<br>
-----Original Message-----<br>
From: Joe D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>><br>
Sent: Sep 19, 2023 1:26 PM<br>
To: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>>, X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>, <<a href="mailto:holger.seelig@googlemail.com" target="_blank">holger.seelig@googlemail.com</a>><br>
Subject: Re: [x3d-public] Negative scale and winding order<br>
<br>
<blockquote type="cite">
<blockquote type="cite">While this approach is very practical, I am not sure what the spec.actually requires in this respect.<br>
</blockquote>
</blockquote>
<br>
<blockquote type="cite">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.<br>
</blockquote>
<br>
Sorry I sort of wrote this off, to both you and Holger.<br>
A good, reliable solution to this problem is needed, as learned or not from recent experience.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
Thanks for the help,<br>
Joe<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Joe D Williams<br>
Sent: Sep 19, 2023 11:09 AM<br>
To: Andreas Plesch , X3D Graphics public mailing list<br>
Subject: Re: [x3d-public] Negative scale and winding order<br>
<br>
<br>
-----Original Message-----<br>
From: Andreas Plesch<br>
Sent: Sep 19, 2023 9:03 AM<br>
To: X3D Graphics public mailing list<br>
Subject: [x3d-public] Negative scale and winding order<br>
<br>
<blockquote type="cite">Holger made good points on why a negative scale in the parent<br>
</blockquote>
transform should not affect which side of a geomet is considered<br>
facing outward and visible with solid=true.<br>
<br>
OK, I thought I tried that with no effect.<br>
<br>
<blockquote type="cite">While this approach is very practical, I am not sure what the spec.<br>
</blockquote>
actually requires in this respect.<br>
<br>
I did not care, it worked and I will look more later.<br>
The following is all good. I think the players show it different because the user code is changed from what I sent.<br>
<br>
<blockquote type="cite">First, it does not explicitly single out the case of a negative scale.<br>
</blockquote>
Should it ? If so, it would probably have to deal with the effective<br>
world transform.<br>
<br>
<a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/rendering.html#CommonGeometryFields" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/rendering.html#CommonGeometryFields</a><br>
<br>
'The ccw field defines the ordering of the vertex coordinates of the<br>
geometry with respect to user-given or automatically generated normal<br>
vectors used in the lighting model equations. If ccw is TRUE, the<br>
normals shall follow the right hand rule; the orientation of each<br>
normal with respect to the vertices (taken in order) shall be such<br>
that the vertices appear to be oriented in a counterclockwise order<br>
when the vertices are viewed (in the local coordinate system of the<br>
Shape) from the opposite direction as the normal. If ccw is FALSE, the<br>
normals shall be oriented in the opposite direction. If normals are<br>
not generated but are supplied using a Normal node, and the<br>
orientation of the normals does not match the setting of the ccw<br>
field, results are undefined.'<br>
<br>
has the relevant ccw field language.<br>
<br>
I think the specified process is:<br>
<br>
- Compute the outward facing normal of a triangle using the ordering<br>
of the vertices in such a way that the ordering appears<br>
counterclockwise when viewed in the opposite direction of the computed<br>
normal. This uses the local, untransformed (raw) coordinates.<br>
<br>
- invert the normal if ccw=false.<br>
<br>
- Apply the accumulated transforms to both the vertices and the<br>
computed normal. The spec. has a strict definition on how to apply a<br>
transform to vertices to transform from the child space to the parent<br>
space. For normals transformations there is a computer graphics<br>
standard approach and probably opengl based equations but the spec.<br>
itself seems to be silent.<br>
<br>
So perhaps the question is how to apply negative scale transforms to<br>
normals as intended by the spec.<br>
<br>
The Leif example has ccw=false and a negative scale (for z). It<br>
appears as outside in on x_ite and outside out on view3dscene and<br>
x3dom.<br>
<br>
A workaround is solid=false but that may not always be possible or desired.<br>
Another workaround is to not use negative scales/mirroring, eg.<br>
preprocess geometry accordingly which seems like a major limitation.<br>
<br>
-Andreas<br>
<br>
On Tue, Sep 19, 2023 at 10:37 AM wrote:<br>
<blockquote type="cite"><br>
Send x3d-public mailing list submissions to<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:x3d-public-request@web3d.org" target="_blank">x3d-public-request@web3d.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:x3d-public-owner@web3d.org" target="_blank">x3d-public-owner@web3d.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of x3d-public digest..."<br>
<br>
</blockquote>
<br>
<blockquote type="cite">2. Negative Scale<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>
</blockquote></div></div>