[x3d-public] TwoSidedMaterial deprecation by adding Appearance backMaterial field
Don Brutzman
brutzman at nps.edu
Sun Feb 2 12:11:07 PST 2020
On 2/1/2020 4:51 PM, Andreas Plesch wrote:
> A slight drawback is that the backMaterial material node would need the containerField attribute. A way to avoid that would be to have a BackMaterial node.
Agreed, and do-able. We have many other cases like this. Tools can help with diagnostic checks also.
We likely need to specify explicitly that if a 'backMaterial' field is provided with no front 'material' field in the Appearance, then either (a) a default Material is used for front side, or (b)'backMaterial' field is used for both back and front.
On 2/2/2020 9:00 AM, Michalis Kamburelis wrote:
> To be frank, I'm not sure whether we need "backMaterial". I do not see
> this as a very useful capability (just like I didn't see
> TwoSidedMaterial with separateBackColor=TRUE very useful). I really
> never saw in my career a single case where a 3D gfx artist would want
> this.
> Don 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.""" --- but we're modeling
> rooms and buildings in 3D since many years now, and I haven't seen a
> single real-life case when someone would need this capability. In
> practice,
>
> 1. when modeling interiors, you usually need different interior geometry,
>
> 2. in the very rare cases when the same geometry makes sense, it's not
> a problem (also not a problem for performance) to just duplicate the
> geometry and flip normal vectors.
Not arguing with your experience, and certainly agree that this approach seems advisable for specialty author-produced models.
Nevertheless:
- have seen aliasing problems many (hundreds of) times, probably the majority of composed geospatial scenes (places with things in them).
- the problem continues today when making plain-old models of things that might get dual-purposed for use in geospatial venues.
- when converting autogenenerated CAD or procedural content, this duplication of geometry solution actually changes the model, and also doubles complexity. Thus round-trip conversions are no longer feasible, and performance likely suffers further in very large scenes.
Thus a simple "don't do two-sided materials, do something else" does not seem to be a scalable general solution for some very important uses cases (that are supersets of existing use cases for using plain-old models).
> You also wrote ''""Correctly modeling both sides of dividing
> quadrilateral is extremely difficult when multiple coplanar polygons
> are required.""" -- The solution to this is known: use
> backface-culling. If you want a wall visible from one side as red, and
> from another side as blue -- you can use two quads, with different
> "ccw" field", and "solid=TRUE". They can be coplanar then, without any
> aliasing issues.
Your rationale makes sense, but in practice the pathology is fairly common in large scenes. After all these years, is it overconfident to think that we just need better browser implementation and testing to fix aliasing occurrences? Quite possibly, and always worth pursuing - but still hard to accomplish over the full range of players.
Might doubling of boundary polygons with opposite ccw/normal vectors make sense for browsers to perform as a rendering technique? Maybe sometimes if carefully implemented, but generally am guessing not, for starters because any associated geometry animation might no longer work.
> Note that glTF doesn't have such functionality (corresponding to
> "backMaterial") either. In glTF you can say that material is two-sided
> (just like in X3D you can that geometry has solid = FALSE), but you
> cannot have different front and back colors.
That is also really good to know.
Minimum approach seems to be deprecate TwoSidedMaterial in X3Dv4, since by our design goals we are not supposed to remove any X3Dv3.3 baseline capability unless it is problematic.
Wondering what you think about compatibility with PBR upgrades: does allowing either legacy TwoSidedMaterial or equivalent Appearance/material/backMaterial approaches result in major difficulty implementing PBR? If two-sided materials are a problematic drawback for PBR, that is important to know.
Yogi Berra's advice "when you come to the fork in the road, take it" is likely apropos as well. In other words: we also have the design option to only support two-sided material in the legacy VRML/X3Dv3 rendering model, while eliminating it in X3Dv4 PBR.
> As for the default, I would leave solid=TRUE default. This was a good
> decision from VRML and X3D 3 IMHO. It's consistent with default in
> glTF.
I sure wish we had called the field 'twoSided' instead of 'solid' originally. That would have eliminated several million questions that continue to this day. My mnemonic device is to think of whether the geometry is 'solid' like a brick, you don't have to render the inside of a brick... hmmm, just added that to X3D Tooltips.
https://www.web3d.org/x3d/content/X3dTooltips.html#Box.solid
> Regards,
> Michalis
>
> niedz., 2 lut 2020 o 01:51 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>>
>> A slight drawback is that the backMaterial material node would need the containerField attribute. A way to avoid that would be to have a BackMaterial node.
>>
>> On Sat, Feb 1, 2020, 7:45 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>>>
>>> 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
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
More information about the x3d-public
mailing list