[x3d-public] [x3dom-developers] ElevationGrid for the modern age

[Kristian Sons]

Hi,

since the discussion shifted somehow to shading (a topic I really like), 
I'd like to point you to our shade.js approach:
http://xml3d.org/xml3d/papers/shade.js/

With shade.js you can have programmable shaders without "all or 
nothing". You can't break lighting and other effects such as fog and you 
don't need to know about any internals of the renderer. It could even be 
a deferred shading algorithm or even a ray tracer. Finally, shade.js is 
based on a subset of JavaScript, a language web developers are very 
familiar with.

shade.js compiles materials to GLSL or OSL. For that we created a 
compiler framework that does all the magic (type inference, eliminating 
control flow that does not apply, optimization such as uniform 
expression extraction). Since we wanted it to run in the browser, the 
compiler framework is written in JavaScript as well.

It's fully integrated into XML3D. But it shouldn't be too hard to 
integrate into a X3D renderer. Here is a very small example of an 
animated shader with shade.js (turn on your webcam):
http://xml3d.github.io/xml3d-examples/examples/shade-tv/index.html

Have a look at the material source (lines 27 - 53). Looks and feels like 
JavaScript without sacrificing performance.

Best regards,
   Kristian


Am 29.01.2015 um 22:57 schrieb Michalis Kamburelis:
>> Michalis, that's a good analysis. The technicalities of actually doing the
>> ops is a bit detailed for me, which gets me back to wanting to specify this
>> more semantically. Which is why I like Fraunhofer's 'common surface shader'
>> for a great deal of the things most of us need it for. I can say 'bumpmap'
>> and it does that, I don't have to know how to multiply normals or whatnot.
>> That's too much like deconstructing the scene for the hardware, and then I
>> might as well be using Three.js. But it IS handy to have that power.
> I like CommonSurfaceShader too (and I would like to implement it in
> Castle Game Engine too :), for now I realize bump mapping by my own
> extension http://castle-engine.sourceforge.net/x3d_implementation_texturing_extensions.php#section_ext_bump_mapping
> ). Seeing CommonSurfaceShader in standard X3D, and just generally
> supported by all browsers, would be cool indeed. And it would indeed
> allow to avoid using existing multi-texturing nodes in some cases.
>
>> What I'm leaning toward is a syntax which is XML-compliant that would allow
>> easy binding to custom shaders. I think x3dom is close to that, but if I'm
>> not mistaken, the way textures are supplied to a shader is a) order
>> dependent, and b) not at all explicit. So I'd like to add a couple of fields
>> to take away that ambiguity, or at least, make it more obvious (that is,
>> easier to follow) for the author.
> X3D "Programmable shaders" component already gives you a full-featured
> way to use custom shaders. Including passing textures to them. You
> pass textures the shaders by name, order doesn't matter in that case.
> Many of the multi-texturing specification problems disappear in that
> case, since it's the shader that 100% determines how colors are mixed.
>
> The only downside of X3D "programmable shaders" component that I see
> is that it's all-or-nothing --- if you want to use shaders, you have
> to implement all the shading by your own shader code. My personal
> solution is that is
> http://castle-engine.sourceforge.net/compositing_shaders.php , but
> that's only Castle Game Engine extension for now.
>
> Michalis
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
_______________________________________________________________________________

Kristian Sons
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
Agenten und Simulierte Realität
Campus, Geb. D 3 2, Raum 0.77
66123 Saarbrücken, Germany

Phone: +49 681 85775-3833
Phone: +49 681 302-3833
Fax:   +49 681 85775–2235
kristian.sons at dfki.de
http://www.xml3d.org

Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
_______________________________________________________________________________