[x3d-public] Negative scale and winding order
John Carlson
yottzumm at gmail.com
Sat Oct 7 23:04:38 PDT 2023
Also can convert XML to JSON!
Go Holger!
John
On Sun, Oct 8, 2023 at 12:02 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> Holger, something I just noticed about this: you are loading a .gltf file
> but displaying it as an X3D file in X_ITE Playground?
>
>
>
> Interesting, assume you are converting directly from glTF JSON to X3D XML
> on the fly…
>
>
>
> 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:* Holger Seelig <holger.seelig at yahoo.de>
> *Sent:* Monday, September 25, 2023 4:04 PM
> *To:* Andreas Plesch <andreasplesch at gmail.com>
> *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Joe D Williams <
> joedwil at earthlink.net>; X3D <x3d-public at web3d.org>; Holger Seelig <
> holger.seelig at yahoo.de>
> *Subject:* Re: [x3d-public] Negative scale and winding order
>
>
>
> There is another glTF negative scale test:
>
>
>
>
> https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/NegativeScaleTest/glTF/NegativeScaleTest.gltf
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2FKhronosGroup%2FglTF-Sample-Models%2Fmaster%2F2.0%2FNegativeScaleTest%2FglTF%2FNegativeScaleTest.gltf&data=05%7C01%7Cbrutzman%40nps.edu%7C46179475647e4b5b0d3c08dbbe1bb590%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638312798479012285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P7s2bOtTjM1C8B6mP3jHhvFQ%2B6OtMoSTfNFydbEas4g%3D&reserved=0>
>
>
>
> View in Playground:
>
>
>
>
> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/NegativeScaleTest/glTF/NegativeScaleTest.gltf
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fplayground%2F%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2FKhronosGroup%2FglTF-Sample-Models%2Fmaster%2F2.0%2FNegativeScaleTest%2FglTF%2FNegativeScaleTest.gltf&data=05%7C01%7Cbrutzman%40nps.edu%7C46179475647e4b5b0d3c08dbbe1bb590%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638312798479012285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i4ydl0AFyPBHrlz9109s9vpxdG3CRIP68ZafsAioGO0%3D&reserved=0>
>
>
>
> --
>
> Holger Seelig
>
> Leipzig, Germany
>
>
>
> holger.seelig at yahoo.de
>
> https://create3000.github.io/x_ite/
>
>
>
> Am 25.09.2023 um 04:14 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>
>
>
> Using Holger's example of using negative scale for mirroring, this
> gist shows how various browsers treat negative scale:
>
> https://gist.github.com/andreasplesch/220e5b2bdc5422d998b24f30f90e255d
>
> It turns out all browsers do not treat negative scale as a special
> case leading to inverted faces.
>
> This does not necessarily mean that x3d could not align with glTF type
> negative scale behaviour in the future but it clearly shows that spec.
> changes would be needed.
>
> Another consideration is that the required checking for negative scale
> requires some per frame cost which currently is overhead for almost
> all scenes but could be seen as a worthwhile investment to make
> negative scale usable for mirroring purposes.
>
> I think Viewpoints are already required to ignore scale, so that
> should not be an issue.
>
> The x3dom dev. version now supports negative scale for glTF inlines as
> required by the glTF spec. It would be straightforward to expand that
> behaviour to all Shapes.
>
> -Andreas
>
> On Fri, Sep 22, 2023 at 1:00 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>
> I looked into the feasibility of automatically adjusting ccw based on
> negative world scale for x3dom. It looks like it could be pretty
> straightforward but has a potentially significant drawback for scenes
> with a lot of Shapes. Since it requires computing the determinant at
> every frame for every Shape, it actually would likely be slower than
> just using solid='false' even if that doubles the amount of drawing
> because that is entirely GPU based. Also it would impact any scene. So
> I am not sure if supporting a negative scale is worth the performance
> cost across the board. This is potentially the reason why it is
> optional for view3dscene. For glTF support, in x3dom it is still
> possible to only compute the determinant at every frame for
> BufferGeometry which is the only geometry used for glTF. So I am
> leaning towards enabling automatic ccw for negative scale only for
> glTF inlines (which is opaque to the X3D spec.) and otherwise
> recommending solid='false' for mirroring use cases.
>
> -Andreas
>
> On Fri, Sep 22, 2023 at 12:02 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>
> We could check behaviour of other existing X3D browsers, especially
> freeWRL, Octaga and BSContact which are still available.
>
> Since negative scaling has not been historically supported, it may be
> worth deviating from established, but not well defined interpretations
> in browsers. This would definitely require a spec. change/addition.
>
> glTF compatibility can be accomplished by checking for negative scale
> during import and adjusting ccw accordingly, or by global behaviour
> affecting all geometres. If there are no backward compatibility
> concerns, consistent behaviour for any affected geometry would be most
> helpful for authoring.
>
> glTF style, automatic adjustment of normals in case of negative
> scaling presumably also applies to explicitly provided normals (in
> normal maps) ? I think it must to support the mirroring use case.
>
> https://github.com/KhronosGroup/glTF/issues/1697 has more discussion
> about similar questions and points to
>
>
> https://github.com/KhronosGroup/glTF-Asset-Generator/blob/master/Output/Positive/Node_NegativeScale/README.md
>
> for a series of tests.
>
> -Andreas
>
>
> On Thu, Sep 21, 2023 at 7:55 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
> _______________________________________________
> 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/20231008/f3fe2c29/attachment-0001.html>
More information about the x3d-public
mailing list