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

[Kristian Sons]

Doug,
> 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.
Yes. Would be nice to use it with all the capabilities of a recent 
OpenGL API :)

I think there would be two alternatives integrating shade.js into a 
native library application:
1. Integrate the JS Compiler into the app using a JavaScript VM (or 
shader compilation as a service)
2. Implement the concepts of shade.js with a compiler framework such as LLVM

>
> "...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?
Well, if an expression in the material is uniform (e.g. 
env.uniformColor1 * env.uniformColor2), the result is uniform, i.e. it 
doesn't change per fragment or per pixel and can be computed on CPU. A 
single multiplication will not pay of, however, as we have shown in the 
paper, more complex expressions will result in speed-ups in particular 
on mobile devices.

  We also shift stuff into the vertex shader, e.g. (linear) coordinate 
space transformations. Currently we are looking into how to use shade.js 
also for programmable light models and for animation/displacement with 
Xflow.

Best,
   Kristian


>
> 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
>   		 	   		
> _______________________________________________
> 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
_______________________________________________________________________________