[x3d-public] beyond Blinn-Phong: PBR

Mon Jan 21 09:16:45 PST 2019

A response below

Message: 2
> Date: Mon, 21 Jan 2019 02:27:53 -0800
> From: Joseph D Williams <joedwil at earthlink.net>
> To: Andreas Plesch <andreasplesch at gmail.com>,  Michalis Kamburelis
>         <michalis.kambi at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] beyond Blinn-Phong: PBR
> Message-ID: <E1glWo5-0007qm-6l at elasmtp-dupuy.atl.sa.earthlink.net>
> Content-Type: text/plain; charset="utf-8"
>
>
> ? ? glTF supports animation of transformation components but does not
> define exactly when an animation is played,
>
> So, if I remember, as if I just awoke from a long sleep, then the gltf is
> to provide a secure and reliable way to transport carefully defined data
> structures into and out of either an unknown authortime or a known runtime.
> Maybe I am focusing of the binary forms for various gltf syntax.
>

Yes, glTF is supposed to be transport format to be used inbetween
authortime and runtime. Its design goal is to avoid friction for the
runtime to render on the screen using a limited subset of OpenGL (webGL) at
the expense of authortime legibility. All glTF syntax have a large binary
component (the 'buffer') which contains the bulk of the data (geometry,
animation, textures).

glTF can be validated. But it does not have built-in security to guard
against tampering and such. Systems need to provide their own security
layer around glTF where required.

> gltf took collada and the rest into the deepest parts of best practice
> highly optimized data structures of mesh and field simulations in a form
> the best practice realtime 3D graphics processing tools wanted to get it --
> Validated trusted secure binary the runtime can swallow without chewing.
>
> The runtime can import this binary directly because the runtime is a
> ?standard? runtime using  ?standard? known best-practice runtime data
> structures. These data structures are defined by the preferred forms for
> binary data used directly by geometry and animation processors. The gltf
> incidentally has an authortime text form to provide systematic
> human-readable editing and validation, but the human-readable form is just
> to allow data specialists to define carefully denominated strongly typed
> definitions for the binary form actually used by features of the runtime.

The geometry, animation and shading processor targeted are GPU shading
programs. Although initially targeted at GLSL, wide support has shown that
there is enough abstraction to allow other platforms as well although I do
not know how much effort this required.

> The x3d deals mainly with the authortime form and does not define any
> runtime data structures except for runtime external and internal scenegraph
> event flows. An x3d tool would be expected to produce its internal runtime
> structures from the ?standard? x3d user code according to its needs. The
> great purpose of gltf is to provide a known binary form that accurately
> reflects known expectations of the runtime.
>
> A comprehensive x3d authortime tool might have an accessory to directly
> import and use certain text forms of gltf if the data types and structures
> are the same. Likewise, an x3d runtime might be able to directly import and
> use certain binary forms. Or, any combination thereof.

There are the parallel options of translating glTF to x3d which is
currently possible for geometry and transform animations, and treating glTF
as inline, inert, jpg-like content. A translator could always be used at
authortime and provides most flexibility. glTF inline has the advantage
that it can be easier to implement and preserves 'swallowing without
chewing'. New x3d nodes such as PhysicalMaterial or BufferView/Accessor for
binary data can be imagined as internal helpers or as spec. worthy x3d
additions.

> Since the gltf is defined and supported by the same folks who developed
> the concepts behind realistic accelerated realtime 3D Graphics, from which
> x3d is derived, then we might expect that gltf would be of great use to x3d.
>

glTF has wide industry support. Incidentally, PBR was not part of glTF 1.0,
which required content to provide its own shaders.

> ? ? but does not define exactly when an animation is played,
>
> So far, the gltf does not define an interactive runtime that I have seen
> (please send a link if there is), although I think I have seen authoring
> that defines sets of gltf data and seen runtimes that use sets of gltf
> files to produce an animated scene.

You are right. Animation is seen as clips made available to the runtime in
the context of a larger scene. glTF just provides the storage. The runtime
needs to provide interactivity and logic.

Should there be a way for a X3D scene to control animations in an inline
glTF ? If so how ? Using standardized DEF  names for (virtual) TimeSensor,
Interpolator nodes from the glTF ?

Thanks and Best,
> Joe
>
>
>
>
>
> From: Andreas Plesch
> Sent: Sunday, January 20, 2019 6:31 PM
> To: Michalis Kamburelis
> Cc: X3D Graphics public mailing list
> Subject: Re: [x3d-public] beyond Blinn-Phong: PBR
>
> Timo Sturm provided these nodes. The main work is to get to the gltf data
> to a special shader which in itself is not complex. I think the goal is to
> proceed to an overdue x3dom release after consolidating into development
> release with what we have. There would be some time to make adjustments to
> node signatures perhaps focusing on PhysicalMaterial.
>
> The flipped Y axis for texture coordinate is handled in the fragment
> shader:
>
>
> https://github.com/x3dom/x3dom/blob/webVR/src/shader/ShaderPBRMaterial.js#L124
>
> The 1 - coord.y should not have a noticeable performance impact. There is
> currently no way to access the gltf texture coordinates from the x3d scene.
>
> glTF supports animation of transformation components but does not define
> exactly when an animation is played, just how long a cycle is. x3dom just
> plays and loops them but could opt to play once or not play and just
> provide the equivalent Timesensor, Interpolator and ROUTE nodes for the
> scene to use as it wants. On the other hand there is no way to EXPORT from
> a gltf inline.
>
> -Andreas
>
> On Sun, Jan 20, 2019 at 3:21 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
> Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > For glTF inline support, PBR shading will be required. The glTF spec.
> has an example implementation for PBR but for anybody who wants to dive in
> more, there is the free
> >
> > http://www.pbr-book.org
> >
> > It seems somewhat artificially inflated and is based on ray tracing but
> explains the foundational PBR concepts in depth, and in code.
> >
> > I just wanted to share that resource but will point out that x3dom will
> have a PhysicalMaterial node and an EnvironmentLight node which are used by
> the glTF loader.
> >
>
> Cool! I also want to define PhysicalMaterial and EnvironmentLight in
> Castle Game Engine, for interoperability with glTF. It will be good to
> converge on a single specification for these nodes, and eventually add
> it to the X3D 4 specification :) We have the same goals (achieve PBR
> in X3D, and achieve it in a way that makes glTF 2.0 -> X3D conversion
> straightforward), so I'm sure this will be possible.
>
> I don't have an exact specification yet (my rough ideas are on
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F
> , this page collects thoughts and info from our talks on x3d-public :)
> ).
>
> Regards,
> Michalis
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190121/2066856d/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 118, Issue 60
> *******************************************
>

-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190121/afab07bd/attachment-0001.html>