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

[doug sanden]

Kristian,
> http://xml3d.org/xml3d/papers/shade.js/

"Moreover, shade.js can easily
be ported to other WebGL engines and – with little extra
effort – also to native renderers."

Native - that's music to my ears.

"...our compiler partitions the shader program
by computation frequencies in order to optimize the
run time performance, i.e. it extracts parts of the code that
can be executed on the CPU or on the vertex shader stage respectively..."

So it can do vertex-shader stuff too? And a bit of CPU? 

Sounds interesting.
-Doug

>
> 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
> _______________________________________________________________________________
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org