[x3d-public] TwoSidedMaterial deprecation by adding Appearance backMaterial field
Andreas Plesch
andreasplesch at gmail.com
Sat Feb 1 16:45:55 PST 2020
Sounds good. Any chance that solid=false could become the default?
---on the phone---
On Sat, Feb 1, 2020, 5:18 PM Don Brutzman <brutzman at nps.edu> wrote:
> Am expecting that two-sided material will be a capability with increasing
> use as more models are created for building internals (rooms walls
> stairwells etc.) and component parts (perhaps CAD-related) with internal
> compartments.
>
> There seems to be a simple way to do this that can deprecate/eliminate
> TwoSidedMaterial without loss of modeling capability: add a backMaterial
> field to Appearance node.
>
> Suggested approach:
>
> SFNode [in,out] backMaterial NULL [X3DMaterialNode]
>
> "The material and backMaterial fields are respectively used for both the
> front and back side of geometry whenever the X3D lighting model is active.
> If no backMaterial is defined, then the material field applies to both
> sides of related geometry."
>
> ========================================================
>
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shape.html#Appearance
>
> 12.4.1 Appearance
>
> Appearance : X3DAppearanceNode {
> SFNode [in,out] fillProperties NULL [FillProperties]
> SFNode [in,out] lineProperties NULL [LineProperties]
> SFNode [in,out] material NULL [X3DMaterialNode]
> SFNode [in,out] metadata NULL [X3DMetadataObject]
> MFNode [in,out] shaders [] [X3DShaderNode]
> SFNode [in,out] texture NULL [X3DTextureNode]
> SFNode [in,out] textureTransform NULL [X3DTextureTransformNode]
> }
> ========================================================
>
> This simple approach provides complete backwards compatibility with any
> existing Shape that uses the TwoSidedMaterial node (X3D version 3.2 or
> later). So not only can that node be deprecated, but conversion between
> X3Dv3 and X3Dv4 can be lossless.
>
> Not seeing any need for special wording regarding 'solid' field since
> specification seems to handle that situation already:
>
> * 11.2.3 Common geometry fields
>
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#CommonGeometryFields
> "The solid field determines whether one or both sides of each polygon
> shall be displayed."
>
> Further motivation to not eliminate two-sided rendering:
> Correctly modeling both sides of dividing quadrilateral is extremely
> difficult when multiple coplanar polygons are required. This is because of
> aliasing ("tearing") effects that currently can only get handled in a
> complex way using NavigationInfo parameters. It is not currently practical
> to have medium-scale objects within a large-scale world unless a
> NavigationInfo values are modified (or NavigationInfo nodes are bound)
> accordingly. Problems can remain even if two polygons remain parallel but
> are separated by a small distance.
>
> btw, workaround heuristic for aliasing effects:
>
> * X3D Tooltips, NavigationInfo avatarSize,
>
> https://www.web3d.org/x3d/content/X3dTooltips.html#NavigationInfo.avatarSize
>
> "Warning: important design thumbrule is to keep (visibilityLimit /
> avatarSize.CollisionDistance) < 10,000 to avoid aliasing artifacts (i.e.
> polygon "tearing")."
>
> * Hint: Aliasing
> https://en.wikipedia.org/wiki/Aliasing
>
> * Hint: Clipping
> https://en.wikipedia.org/wiki/Clipping_(computer_graphics)
>
> On 1/21/2020 5:02 PM, Andreas Plesch wrote:
> > I checked the x3dom implementation of TwoSidedMaterial. It is more
> efficient, eg. faster than having two separate Shapes and Geometries for
> front and back since it allows rendering of both faces in one call to the
> GPU shader. If separateBackColor is requested the shader is modified to
> check on the fly with gl_frontfacing (
> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl_FrontFacing.xhtml)
> if the back is rendered and if so use the back colors instead of the front
> colors. That is pretty much all that is required.
> >
> > But it may still be worthwhile to trade a bit of performance of a rarely
> used feature for an opportunity to simplify.
> >
> > I think the fact that after an authors sees missing back faces
> TwoSidedMaterial is easier to discover than the tiny looking solid field
> and its equivalent functionality, helps explain why it is fairly popular.
> The examples probably cover the solid field pretty well. It would still
> help to make solid=false the default. It is a more drastic change but may
> be ok for a new major version of x3d.
> >
> >
> > ---on the phone---
> >
> >
> > On Tue, Jan 21, 2020 at 11:11 AM Andreas Plesch <andreasplesch at gmail.com
> <mailto:andreasplesch at gmail.com>> wrote:
> > >
> > > Thinking about PBR, what would be the consequence of not having a
> > > TwoSidedPhysicalMaterial ?
> > >
> > > I think it means that two sided behaviour would then be only
> > > achievable with solid=true and duplicate geometries with opposing
> > > normals each with its own PhysicalMaterial. This does not need to
> > > impact decisions on TwoSidedMaterial, it appears. PBR is new and how
> > > to do two sided lighting would also be new for PhysicalMaterial. While
> > > it would be nice to have parallelism with PhongMaterial, it is not a
> > > requirement.
> > >
> > > But I think I am changing my mind to be more in favor of just
> > > deprecating TwoSidedMaterial completely although it is harder for
> > > normal users then to generate the effect. I am not sure, however, that
> > > x3dom implements the ccw field for primitive geometries like Sphere
> > > correctly although it may.
> > >
> > > If there would be more frequent opportunities to update the spec., I
> > > would probably prefer to keep TwoSidedMaterial but mark it as on the
> > > way out, deprecated, and then remove it in the next version. But
> > > perhaps it is time to remove it now.
> > >
> > >
> > > On Tue, Jan 21, 2020 at 10:32 AM Michalis Kamburelis
> > > <michalis.kambi at gmail.com <mailto:michalis.kambi at gmail.com>> wrote:
> > > >
> > > > Andreas Plesch <andreasplesch at gmail.com <mailto:
> andreasplesch at gmail.com>> wrote:
> > > > >
> > > > > There is movement around TwoSidedMaterial. See
> > > > >
> > > > > https://github.com/castle-engine/view3dscene/issues/23
> > > > >
> > > > > and
> > > > >
> > > > >
> http://web3d.org/pipermail/x3d-public_web3d.org/2019-December/011594.html
> > > > >
> > > > > I would vote to keep a version of it since the alternative of
> manually doubling the geometry with inverted normals is too awkward for
> normal users.
> > > > >
> > > >
> > > > If we keep TwoSidedMaterial (with sepatateBackColor=true
> possibility),
> > > > then we also need a solution for PBR for this. So my proposed
> > > > TwoSidedAnyMaterial from
> https://github.com/Web3DConsortium/X3D/pull/8
> > > > would be relevant. It allows to make two-sided Phong Material or
> > > > two-sided PhysicalMaterial.
> > > >
> > > > ( I don't have an opinion here, whether we should keep
> > > > TwoSidedMaterial, or remove it and instead have a simple boolean
> field
> > > > "twoSided", I just note that *if* we decide that TwoSidedMaterial is
> > > > useful, then necessarily also new TwoSidedAnyMaterial is useful, to
> > > > have the same capabilities for Phong and physical materials. )
> > > >
> > > > Personally, I never saw real use-cases for TwoSidedMaterial with
> > > > separateBackColor=true, but maybe my needs were specific :) If many
> > > > people use with separateBackColor=true, then we should reconsider
> > > > keeping it indeed.
> > > >
> > > > > There is a need, however, to clear up some confusion. As far as I
> can judge there is no need for separateBackColor. It should always be true
> since this case appears to be the main point of the node.
> > > > >
> > > >
> > > > As per my comments in
> > > > https://github.com/castle-engine/view3dscene/issues/23 -- I think
> that
> > > > right now the specification says something different (solid=false
> with
> > > > one-sided Material means that back faces are black). It's also
> > > > somewhat consistent with implementation (using OpenGL[ES] etc.):
> > > >
> > > > - one thing determines backface culing ("solid"), like
> glEnable(GL_CULL_FACE)
> > > >
> > > > - another, independent thing controls whether the "back" faces have
> > > > lighting calculated correctly (using TwoSidedMaterial instead of
> > > > Material). This is typically a code in GLSL shader that inverts a
> > > > normal if gl_FrontFacing==false.
> > > >
> > > > But I could be persuaded to your approach :) I see your point --
> right
> > > > now we have some combinations that aren't really useful:
> > > >
> > > > - Using solid=false with one-sided Material is hardly useful, as
> > > > authors don't really want to see pure black faces.
> > > >
> > > > - Using solid-true with TwoSidedMaterial isn't very useful, since
> you
> > > > activate two-sided lighting calculation, but then don't render back
> > > > faces.
> > > >
> > > > As I understand, you would prefer to simplify it.
> > > >
> > > > - Connect whether "the back faces are visible" with "the back faces
> > > > have correct lighting calculated" into a single feature, activated
> in
> > > > one place (by "solid" field).
> > > >
> > > > - And then the only purpose of TwoSidedMaterial would be to achieve
> > > > *different* colors on front vs back faces.
> > > >
> > > > This would actually be somewhat aligned with current CGE
> > > > implementation too. In CGE I actually *sometimes* realize Material
> as
> > > > two-sided (in Phong shading),
> > > >
> https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_shading
> > > > .
> > > >
> > > > > Also, there needs to be clarification how solid=true and
> TwoSidedMaterial interact. I think x3dom lets TwoSidedMaterial win over
> solid=true in the intent to render back faces. Most other browser probably
> let solid=true win, eg. will not render back faces at all even with a
> TwoSidedMaterial.
> > > >
> > > > The current X3D specification is clear here, IMHO:
> > > >
> > > > The "solid" field determines whether back faces are visible. It is
> > > > unrelated to Material/TwoSidedMaterial. So the X3DOM behaviour is
> not
> > > > correct, IMHO.
> > > >
> > > > I'm not saying that we cannot change it :)
> > > >
> > > > Regards,
> > > > Michalis
> > >
> > >
> > >
> > > --
> > > 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
> >
>
> 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
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200201/c59f73a3/attachment-0001.html>
More information about the x3d-public
mailing list