[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting discussions:Declarative 3D interest group at W3C

[Dmitri Rubinstein]

Chris Marrin schrieb:
> On Jan 5, 2011, at 4:32 PM, Dmitri Rubinstein wrote:
> 
>> Chris Marrin schrieb:
>>> On Jan 5, 2011, at 11:15 AM, Joe D Williams wrote:
>>>>> (such as XFlow, server-based rendering based on XML3D, AnySL and its successor AnyDSL
>>>> Is there anything public on AnyDSL?
>>>> What is the best link for XFlow?
>>>> What is Khronos association with ASL?
>>> I don't think this group should be trying to blaze the trail with new shader languages. We actually considered that in WebGL and decided instead to support a very strict version of GLSL ES 1.0. To make all this work with HLSL (via the translators in ANGLE) we tightened up a few requirements of the underlying system. As GLSL ES progresses with more of the desktop functionality, we can rev the WebGL spec. So I think you should consider the shading language a solved problem.
>> Is it really solved ? How do you want to combine GLSL with ray tracers like NVIDIA's OptiX or our RTfact ? Ray tracers are real time now, what native XML3D browser clearly demonstrate. And making GLSL as the only shading language for 3D in Web couples it tightly with rasterization rendering techniques. This was already a big problem with VRML and X3D, when we wanted to connect it with our real time ray tracer.
> 
> Experiments and science are wonderful things. But this is engineering, and our work has to work on a wide variety of hardware and OS configurations. One day non-rasterization rendering techniques might be mainstream. But that day is not today.

I don't think that real time ray tracing is just a science, since 
everybody can run it on a today hardware (I understand this as 
mainstream). You don't need anymore a cluster of PCs or dedicated 
hardware. And also a hardware power of GPUs and CPUs grows every year, 
so it will be faster and faster. So when I am a customer and have 
already 3D in a browser, and I also have an app that can render me this 
3D in a real-time without a browser then I will ask a question: Why it 
doesn't work within the browser ?

When this is somehow engineering problem, and we also discussing 
engineering details here (Do we ?), then let me ask you engineering 
question:
Why not add into a browser a more sophisticated plugin API that allows a 
plugin to provide a native implementation for elements of an arbitrary 
XML namespace and propagating all events like DOM changes and CSS 
information into plugin. Combined with direct access to OpenGL's 3D 
context, and I think this is already available via NPAPI:Pepper, this 
should be enough to implement scene graph engine without modifying a 
browser. Then the decision what to support and how 3D DOM should look 
like is up to the plugin author.

Dmitri