[x3d-public] X3D working group: X3Dv4 glTF Physical Material, lighting, meshes

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Sat Nov 24 07:40:46 PST 2018


1. Michalis, thanks 1M for another set of really thoughtful implementation notes.  No doubt you have also been influenced by important related work from Andreas, Holger, Timo, Johannes and many others.

Lots of things to consider strategically and technically.

a. the X3D Working Group would be well advised to make the elaboration and early adoption of this plan our primary focus for January-February 2019.
b. your organization of the interrelated topics has given us an excellent outline to examine, test and build upon.
c. adding a separate material and lighting model (in addition to the classic X3D model) seems the clearest way to define past/future rendering unambiguously.
d. adding new fields onto Material, versus avoiding ambiguous interpretations by defining a new PhysicalMaterial node that has suggested backwards mappings, needs a close look.
e. similar tradeoff analysis (new field extensions or new nodes) for Lights is also very important.  pairwise production of new/old Light nodes seems infeasible for authors.
f. some tightening might be possible, e.g. remove TwoSidedMaterial by adding field for backMaterial to Shape.
f. handling of "GPU-tuned" meshes might simply be new geometry nodes that don't have input fields (e.g. ElevationGrid idiosyncracies).
g. design patterns of StaticGroup applied to Shape might also help.
h. Security considerations when loading glTF files are fundamentally important.  Strictest would be to only allow loading via Inline to ensure that all tests are performed.

Crafting X3Dv4 specification prose in github as best way to achieve clarity will be also most effective way at encouraging influencer/early-mover advantages of membership.  Public scrutiny will occur in small doses periodically, but Web3D Consortium membership will certainly add value.

2. Can we make RenderedTexture the focus for teleconference Friday 30 NOV?  Meeting goals:
a. rough consensus on functionality,
b. list of all related references,
c. outline of draft specification prose,
d. commitments to implement/evaluate in December if possible.

Moderator and scribe needed (I expect to be getting on a train at that time).

3. Thanks everyone for considering these potentially major graphics advances.  Have fun with X3Dv4!  8)


On 11/16/2018 11:28 AM, Michalis Kamburelis wrote:
> Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
>> b. *Inline support for glTF and Physically Based Rendering*.
>> -  Michalis notes that required, well-defined glTF lighting model implies experimental X3D lighting-model changes that correspond to).
>> - Vince described how we need to scope this to Shape/mesh capabilities, or possibly other glTF capabilities also e.g. Camera etc.
> 
> Some links from me (I posted them during the call in another thread too):
> 
> My plan for implementing PBR in X3D (and Castle Game Engine):
> https://github.com/michaliskambi/x3d-tests/wiki/Include-PhysicalMaterial-and-PhysicalEnvironmentLight-in-the-official-X3D-specification
> 
> A summary at the begging of:
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F
> .
> 
> Implementing PhysicalMaterial, PhysicalEnvironmentLight is a
> prerequisite to be able to write Inline { url "foo.gltf" } in X3D :)
> 
> I want to actually implement this in Castle Game Engine / view3dscene
> (although most probably not in 2018, but at the beginning of 2019).
> 
>>
>> c. Others?  *RenderedTexture* might be easy.
>>
>>          http://www.xj3d.org/extensions/render_texture.html
>>
> 
> The important observation about RenderedTexture is that various X3D
> browsers already implement it. Use-cases, documentation, test scenes
> are available, and implementation details are available in open-source
> implementations.
> 
> - Castle Game Engine (and view3dscene):
> https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_rendered_texture
> 
> - InstantReality:
> http://doc.instantreality.org/documentation/nodetype/RenderedTexture/
> 
> - Xj3D: http://xj3d.org/extensions/render_texture.html
> 
> - X3DOM: https://doc.x3dom.org/author/Texturing/RenderedTexture.html
> 
> RenderedTexture can be a basis for mirrors:
> 
> - https://doc.x3dom.org/tutorials/lighting/mirror/index.html
> 
> - https://castle-engine.io/x3d_extensions_mirror_plane.php
> 
> I propose we gather a set of good test files (I already have some in
> CGE, https://github.com/castle-engine/demo-models/tree/master/rendered_texture
> ), document their proper output (make a screenshots from various
> supporting browsers), and then everyone can:
> 
> - Implement RenderedTexture
> - Or check if their existing implementation of RenderedTexture is
> consistent with others.
> 
> Michalis volunteers to prepare these test cases + screenshots :)
> 
>> Suggested New Year's Resolution: following X3D Working Group suggested priorities for implementations, we start publishing Mantis issues one-by-one for X3Dv4 improvements.
> 
> Since Don raised an issue of "New Year's Resolutions" :), I mentioned
> at the end of the call that we could think about focusing our efforts
> on releasing X3D v4.0. An important step to do this, I believe, is
> agreeing on a *minimal* set of features that *definitely need* to be
> included in X3D v4.0.
> 
> (And then everything else can be deferred to future 4.x versions. And
> we can focus on the things that must be done.)
> 
> IOW, I believe we should trim down the
> http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development . It
> is now a large set of candidate ideas, with varying levels of "being
> researched enough to invent useful X3D nodes to express them", and
> "being useful for many X3D users". And it doesn't even contain all the
> ideas that we talk about --- e.g. it doesn't contain PBR.
> 
> I think that talking about this "list of features necessary for X3D
> 4.0" is a large conversation, but it needs to happen at some point
> (and rather sooner), to actually release X3D 4.0 in 2019 :) From
> talking with many of you, I think you share this opinion. I *really*
> want to see X3D v4.0 in 2019 :)
> 
> P.S. I know that everyone has his own opinion about "what is high
> priority" for X3D 4.0 . If you want to know mine, it's in "high
> priority" section on https://github.com/michaliskambi/x3d-tests/wiki
> :) Of course everything I write is up for talking.
> 
> Regards,
> Michalis


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