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

[GLG]

>So you're saying that my iPhone can do real-time
>raytracing? Or my 4 year old ATI graphics card? I've seen
>nice demos of ray-tracing in a fragment shader, and I know
>new Nvidia (and presumably ATI) is very powerful and have
>the potential to do ray-tracing much faster. But that's not
>mainstream.

Hello Chris,

I am very surprised to hear this from you. IMO, a 4 year old
graphics card is not mainstream, it is either obsolete, or
about to be, and has little relevance in this discussion. If
I can voice my personal point-of-view, I believe we should
focus solely on the future without too much regards to past
and present hardware/software. Taking example from the
gaming industry, the latest and greatest games and hardware
are always at the absolute leading edge. What will be is
what we need to meet, otherwise the product of the effort
will already be somewhat dated by the time it comes out. I
think we need to exhibit extreme foresight, and attempt to
provide the foundation for as much of all things 3D as we
can, because if we don't, then later we'll start hearing
things like -why didn't they do it? Although we might not
implement things like shaders and physics, and use ray
tracing in the short term, making sure that there will be a
way to support these in later versions is paramount. Heck,
if I had my way I would even seriously look into the
possibilities of a DAG implementation, and start laying the
groundwork for that. I know, baby steps, but the general
directions should not lead to dead ends anywhere. Babies
tend to walk in circles. We should attempt to envision clear
paths of possibilities that are as wide as we can make them,
even if not implemented today, or failing that, it will have
to be reworked again when the lifecycle of the
implementation is complete. By that time, Web content will
be much more complex, and, once more, it will be necessary
to break it when that happens (as in the incompatibility
with existing 3D worlds). I am just saying, let's try to do
it in a way so this never happens again; In a way so that,
no big money company come again and say, look, we can do
this better, as it happened so many time with VRML/X3D. I am
sure you at least partially agree with the above, and I
realize this may be far more difficult, but if it were easy,
it probably would not be worth doing. That may sound a
little idealistic, but after all, we are building for
'virtual' reality. :)

Having said the above, I do not understand why you often say
"it will fail" if we try to do more. I'd rather have
something fail early if it is to fail, because failing late
breaks content and that is not a better alternative. Again,
my opinion, but I would like to hear you speak more on this
topic.

Cheers,
Lauren  


>-----Original Message-----
>From: x3d-public-bounces at web3d.org [mailto:x3d-public-
>bounces at web3d.org] On Behalf Of Chris Marrin
>Sent: Thursday, January 06, 2011 2:56 PM
>To: Dmitri Rubinstein
>Cc: X3D mailing list Graphics public
>Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting
>discussions:Declarative 3D interest group at W3C
>
>
>On Jan 6, 2011, at 11:42 AM, Dmitri Rubinstein wrote:
>
>> 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 ?
>
>So you're saying that my iPhone can do real-time
>raytracing? Or my 4 year old ATI graphics card? I've seen
>nice demos of ray-tracing in a fragment shader, and I know
>new Nvidia (and presumably ATI) is very powerful and have
>the potential to do ray-tracing much faster. But that's not
>mainstream.
>
>>
>> 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.
>
>The single most important aspect of a web browser isn't
>power or performance or even feature set. It is security.
>Every browser vendor rails against plugins because it opens
>the browser to intentional and unintentional security
>breaches. When discovered, the only recourse the browser
>has is to send out an update which blacklists the guilty
>plugin. The user sees his or her web application suddenly
>stop working because of this and so they blame the browser,
>not the plugin vendor.
>
>Adding a feature like WebGL to the browser is done to add
>features and performance to be sure. But more importantly,
>it allows the browser to control the security of that
>component.
>
>Allowing plugin access to a bare OpenGL context is another
>huge security issue. OpenGL was not designed to be hardened
>against attacks. We are just now working with vendors to
>add these capabilities. So I don't see any possibility of
>opening the internal workings of the browser to any 3rd
>party plugins.
>
>-----
>~Chris
>chris at marrin.com
>
>
>_______________________________________________
>X3D-Public mailing list
>X3D-Public at web3d.org
>http://web3d.org/mailman/listinfo/x3d-public_web3d.org