[x3d-public] X3D Working Group minutes, endgame review: TextureProjector nodes, do we include shadows?
Don Brutzman
brutzman at nps.edu
Fri Oct 16 10:24:57 PDT 2020
We had a very productive meeting today.
Thanks to everyone active for all work on review, implementation and evaluation as we finalize X3D4 for release this year.
Dialog always helps. Am happy to note that we are in the endgame for X3D4 technical improvements.
For cc:ed X3D4 implementers unable to attend, respectfully request that you provide responses (public or private) now if possible.
Below please find minutes for this week's X3D Working Group meeting, Friday 16 October, 08-0930 pacific time.
---
Attendees: Anita Havele, Michalis Kamburelis, Vince Marchetti, Dick Puk, Don Brutzman.
Participation:
[0.1] Web3D Teleconference Information
https://www.web3d.org/member/teleconference-information
> Please use the following link for all Web3D Consortium Meetings.
>
> Join URL: https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
Last week's minutes and followups:
[0.2] [x3d-public] X3D Working Group agenda 9 OCT 2020: game plan and trajectory for voting on release of X3D4 specification
http://web3d.org/pipermail/x3d-public_web3d.org/2020-October/013764.html
[0.3] [x3d-public] comments on Projective texture mapping: near/far naming, textureTransform
http://web3d.org/pipermail/x3d-public_web3d.org/2020-October/013780.html
[0.4] [x3d-public] X3D working group meeting Friday on TextureProjector nodes: special light or texture-mapping technique?
http://web3d.org/pipermail/x3d-public_web3d.org/2020-October/013784.html
[0.5] [x3d-public] announce: X3D4 updates
http://web3d.org/pipermail/x3d-public_web3d.org/2020-October/013791.html
---
1. Outreach
a. Web3D 2020 Conference registration is FREE and open, schedule released online. Over 100 people have registered and all papers/posters are now submitted to ACM Digital Library. They will be freely available for 1 month when the conference starts.
[1.0] Web3D 2020 Conference registration
https://web3d.siggraph.org
[1.1] ACM Digital Library: Web3D Conference
https://dl.acm.org/conference/web3d
Checking the calendar:
* https://web3d.siggraph.org/events/
* Web3D Consortium Town Hall
https://web3d.siggraph.org/event/plenary-2
(page includes calendar links)
* Export Events button puts it all on your calendar:
https://web3d.siggraph.org/events/?ical=1
---
b. Anita has been working on establishing an excellent new blog.
[1.2] blog entry "X3D in a Box"
https://webx3d.org/box-of-x3d
It has seemed somewhat difficult to get a transparent background as part of the X3D model floating over the web page. Surprisingly, we haven't found a lot of people doing this yet. We looked at the latest/greatest and focus on background transparency.
[1.3] X3D Tooltips: Background transparency
https://www.web3d.org/x3d/tooltips/X3dTooltips.html#Background.transparency
Good discussion and review together. For issue of transparency in Background, and overlaying an X3D model over other HTML content, Vince shows that this capability works for both X_ITE and X3DOM.
========================================================
Proof of concept of an X3D model overlay over an image in a HTML page,
as demonstrated in WordPress:
Using X_ITE:
https://webx3d.org/x3doodle-ec/
https://webx3d.org/x3doodle-pb/
Using X3DOM:
https://webx3d.org/x3doodle-x1/
https://webx3d.org/x3doodle-kc/
========================================================
Nicholas showed some good additional examples earlier in the week, but unfortunately we lost those links... hoping to recover them.
They will debug further the "Box of X3D" blog example further. Some other hidden "gotchas" or subtleties may exist, such as ordering of elements for HTML page and X3D model.
Cool screenshot attached! More to follow on this topic.
---
2. Projective Texture Mapping (PTM)
[2.0] X3D4 Working Draft 2, 42 Projective Texture Mapping (PTM) Component
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/ProjectiveTextureMapping.html
a. Critical point of difference: do the TextureProjectorParallel/TextureProjectorPerspective nodes implement X3DLightNode, or are they simply a texture-wrapping function for geometry?
Agreement that either approach is technically feasible, and consistent with updated Physically Based Rendering.
Consensus that we will treat them as X3DLightNode, and all that it implies... Good, this is clearest and best solution.
---
b. Include textureTransform? This addition seems simple, logical and consistent.
- Perhaps optional since the node itself can be rotated via a parent Transform... but that is not quite the same set of features as a textureTransform capability.
- Problem seen implementing: none.
Further opinions welcome. Absent objections, am inclined to include it.
---
c. Component naming concern: if we indeed take an X3DLightNode approach, then "Projective Texture Mapping (PTM)" component seems misleading because we are not mapping any texture to any geometry per se. "TextureProjector*" names are OK. So, might a better name be "Texture Projector" component? Seems clearer and more consistent.
d. Conceptual naming concern: is TextureProjectorParallel more appropriately named/designed as orthographic? Fine point perhaps.
e. Node naming consistency: typically we keep common part of node names last (e.g. Background/TextureBackground nodes, *Material nodes, others).
Perhaps these are better names:
- PerspectiveTextureProjector (or simply TextureProjector)
- ParallelTextureProjector or OrthoTextureProjector
Discussion: minimal. Dick and I will think it through and resolve next Monday. Further inputs welcome.
---
3. Shadows - or not?
Lots of excellent discussion and prior review. Time to decide.
Motivations:
++ Upside: minimalist changes like the above for X3D content enables the creation of scene content that lets authors take advantage of shadows, while X3D browsers can continue to innovate regarding what algorithms they use.
-- Downside: much-requested feature remains unfinished, and specialty shadow implementations remain non-interoperable.
[3.0] [x3d-public] X3D minutes 2 OCT 2020: draft X3D4 Shape component, 3 approaches to X3D4 shadows, RenderingEnvironment node, audio concepts
http://web3d.org/pipermail/x3d-public_web3d.org/2020-October/013726.html
a. Do we add a field on X3DLightNode indicating that a light node can cast shadows?
YES
---
b. Is the best field X3DLightNode shadowIntensity? Default value is 0.0 (for backwards compatibility of X3D content). Is that sufficient to omit a boolean?
OK on both counts...
* SFFloat [in out] shadowIntensity 1 [0,1]
---
c. Do we also provide a boolean field on Shape nodes indicating they can cast shadows? If so, then is default on or off?
Considered HELPFUL. Not considered difficult.
* SFBool [in out] castShadows FALSE
Defaults to FALSE for backwards compatibility with all existing X3D/VRML content. Authors must deliberately add shadows if they want them.
Semantics: a Shape only casts shadows if corresponding Light nodes have shadowIntensity > 0.
Previous emails in thread used term "shadowCaster" but this expression is a bit ambiguous in English. "castShadows" seems like a crisp boolean expression of capability.
Any better names for the field? Seems to work, potential improvements welcome.
---
d. Specification prose?
All suggestions welcome. Dick and Don will distill phrasing from the excellent email thread and work on it next week.
---
4. Identical DEF/USE for backMaterial definitions
Concerns.
- requiring DEF/USE for front and back textures is sometimes difficult to achieve when autogenerating content via a server,
- at a minimum, allowing identical redefinition ought to be allowable since net requirement to browser is unchanged.
- having different front/back textures is a legitimate goal.
This was discussed in a series of mails over past week.
Michalis thinks that DEF/USE was preferable for majority of cases and has higher performance, but agreed it is not a hard requirement.
Interesting use case: IFS mesh describes a denim jacket with a plaid lining... will want to share same mesh but have different textures on outside and inside.
Agreement that different front/back textures is worthwhile and feasible.
We will ensure that next review/revision the X3D4 specification supports this capability.
---
5. Color interpolation of Background nodes
[5.1] [x3d-public] Which color space for Background color interpolation
http://web3d.org/pipermail/x3d-public_web3d.org/2020-October/013778.html
Implementation discussion on email thread apparently indicates that X3D4 specification improvement is needed:
> > So perhaps it is not too late to add "in RGB color space" to
> >
> > https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/enveffects.html#Backgrounds
Updated reference:
[4.2] X3D4 WD2 24 Environmental effects component
24.2.1 Backgrounds
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/environmentalEffects.html#Backgrounds
Paragraphs 4 and 5 each conclude with
- "The sky colour is linearly interpolated between the specified skyColor values."
- "The ground colour is linearly interpolated between the specified groundColor values."
So... is that addition "in RGB color space" (appended at the end of each sentence) sufficient for X3D4 specification prose ?
*** This matches dialog on mailing list. Confirmed.
Or should we allow some variation by browsers and instead append ", typically in RGB color space" ?
*** Bad idea. Leaving open in specification is similar to current ill-defined situation. Better to resolve and state clearly.
We will fix spec, appending in RGB color space" twice as indicated above.
---
And so, done! Appreciate all consideration of these resolvable issues.
It is good to be finalizing everyone's "wish list" and get to the new era of tuning and polishing X3D4 models & player implementations.
Have fun with X3D4! 8)
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 --------------
A non-text attachment was scrubbed...
Name: JoeKickHtmlX3D.png
Type: image/png
Size: 452413 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201016/f1a9f3ab/attachment-0001.png>
More information about the x3d-public
mailing list