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

[Dave A]

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.

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.

So I'll put out what I come up with, when I get it working. Hopefully by 
end of week.

Dave Arendash


On 1/25/2015 11:36 AM, Michalis Kamburelis wrote:
> Leonard Daly wrote:
>> I worked on the MultiTexture node many years ago and still have my notes
>> (someplace). I don't think much has changed. We do have reports that the
>> node is not functioning correctly, but I do not remember enough of the
>> details right now.
> My tests and proposed solutions to the multi-texturing spec are on
> http://castle-engine.sourceforge.net/x3d_multi_texturing.php , if anyone
> is interested. Unfortunately, nothing has changed, X3D spec is still
> half-broken in the regard of multi-texturing, and so far there seemed
> not much interest to apply any of the proposed changes...
>
> Michalis
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>

-- 
Follow me! @thatvrguy