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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200201/fa5369bd/attachment-0001.html>