<div dir="auto">Duplicating the geometry is also what was suggested as a quick solution for the x3dom issue.<div dir="auto"><br></div><div dir="auto">While this is certainly possible, a dedicated node would allow for more optimal implementations and would mean better ergonomics.</div><div dir="auto"><br></div><div dir="auto">An initial BackAppearance or TwoSidedTexture implementation could just use naive internal duplicating of geometry but still provide the ease of use. Later it could be optimized if necessary.</div><div dir="auto"><br></div><div dir="auto">Some thoughts,</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 3, 2017 6:08 PM, "Michalis Kamburelis" <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2017-11-03 18:36 GMT+01:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>>:<br>
> There was a question a while ago on x3dom issues if there is a<br>
> TwoSidedTexture node similar to the TwoSidedMaterial node:<br>
><br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shape.html#TwoSidedMaterial" rel="noreferrer" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/<wbr>components/shape.html#<wbr>TwoSidedMaterial</a><br>
><br>
> There is MultiTexture so it is not unreasonable to expect a TwoSidedTexture.<br>
><br>
> Is there a way currently to have a different texture on the backside<br>
> apart from duplicating the shape ?<br>
><br>
> What could be good way to generalize such that different material,<br>
> texture, or common surface shader nodes can be used simultaneously on<br>
> backs and fronts ?<br>
><br>
> Perhaps a BackAppearance node ?<br>
><br>
<br>
1. BackAppearance seems a bit "too flexible to implement" for me ---<br>
it would also allow for different "shaders" for front and back faces,<br>
since I guess "Appearance.shaders" can be different than<br>
"BackAppearance.shaders". And I have no idea how to implement such<br>
thing (with a single draw call :) ). Typically only the fragment<br>
shader really knows which side you're looking at.<br>
<br>
2. In fact, even TwoSidedTexture seems a bit uneasy to implement for<br>
me, if the children of TwoSidedTexture could be any texture node,<br>
including MultiTexture. You could then specify that<br>
<br>
- front side has MultiTexture e.g. with 3 textures inside (e.g. some<br>
cubemap multiplied by some 2d texture multiplied by some 3d texture)<br>
- back side has MultiTexture e.g. with 2 textures inside (e.g. some 2d<br>
texture added to some other 2d texture)<br>
<br>
IOW, you could have different texture logic/equations for front and<br>
for back side. I can implement this :), but I'm not sure is this<br>
acceptable to all implementors.<br>
<br>
In contrast, the existing TwoSidedMaterial has much simpler<br>
implementation: both front and back sides have lighting calculated<br>
using the exact same equations, only the parameters to these equations<br>
are different depending on which side you're looking at.<br>
<br>
Following this, I think a safer version of TwoSidedTexture would be<br>
something that cannot have MultiTexture as a children, and maybe even<br>
that requires that both front and back textures are the same kind<br>
(both 2d, or both 3d, or both cubemaps...). And MultiTexture can have<br>
(as a children) a TwoSidedTexture. So then you could do (in classic<br>
encoding):<br>
<br>
Appearance {<br>
texture TwoSidedTexture {<br>
front ImageTexture { url "front.png" }<br>
back ImageTexture { url "back.png" }<br>
}<br>
}<br>
<br>
or<br>
<br>
Appearance {<br>
texture MultiTexture {<br>
texture [<br>
ImageTexture { url "first_layer.png" }<br>
TwoSidedTexture {<br>
front ImageTexture { url "second_layer_front.png" }<br>
back ImageTexture { url "second_layer_back.png" }<br>
}<br>
]<br>
}<br>
}<br>
<br>
I think this would be OK to implement :)<br>
<br>
3. I'm not sure how much is such TwoSidedTexture needed, in practice.<br>
You can already achieve a similar effect by reusing the same geometry<br>
but with different "ccw" value. E.g.<br>
<br>
----<br>
Shape {<br>
geometry IndexedFaceSet {<br>
DEF MyCoord Coordinate { ... }<br>
ccw TRUE<br>
solid TRUE # this is the default, I just emphasise it here<br>
coordIndex ...<br>
}<br>
appearance Appearance {<br>
# configure Material, Texture, etc. for ccw=true side<br>
}<br>
}<br>
Shape {<br>
geometry IndexedFaceSet {<br>
USE MyCoord<br>
ccw FALSE<br>
solid TRUE # this is the default, I just emphasise it here<br>
coordIndex ... # unfortunately, you have to repeat coordIndex here<br>
}<br>
appearance Appearance {<br>
# configure Material, Texture, etc. for ccw=false side<br>
}<br>
}<br>
----<br>
<br>
The above is not perfect (a renderer will make 2 draw calls, and you<br>
need to duplicate coordIndex contents). But it already works, in all<br>
browsers, and you can change any Appearance parameter this way :)<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div></div>