[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Volume Textures

> ----- Original Message -----
>> On Thu, Mar 24, 2011 at 7:42 PM, Benoit Jacob <bjacob@mozilla.com>
>> wrote:
>> >
>> >
>> >
>> > ----- Original Message -----
>> >> On Mar 24, 2011, at 4:18 AM, John Davis wrote:
>> >>
>> >> > In the meantime, is there any chance we could add an extension to
>> >> > WebGL and Angle to support volume textures for the rather large
>> >> > use
>> >> > case of Chrome and FireFox? This is very low hanging fruit that
>> >> > will
>> >> > add considerable bang on the fragment shader side.
>> >>
>> >> Let's be careful about what we call "low hanging fruit". WebGL
>> >> attempts to allow content to be written across a wide range of
>> >> hardware. That's why we based the spec on OpenGL ES 2.0 rather than
>> >> desktop OpenGL. If you look at the WebGL extension registry
>> >> (http://www.khronos.org/registry/webgl/extensions/), all of the
>> >> extensions there are available on at least one OpenGL ES
>> >> implementation on mobile devices (iPhone).
>> >>
>> >> That doesn't mean we can't discuss other extensions (like this
>> >> one).
>> >> But I would be very against adding any and all extensions just
>> >> because
>> >> they exist on some driver in some version of OpenGL on some
>> >> platform.
>> >> I even agree that 3D textures are available in a majority of
>> >> desktop
>> >> OpenGL implementations. And GL_OES_texture_3D is defined for OpenGL
>> >> ES. But I don't know of any current implementations of OpenGL ES
>> >> that
>> >> support it.
>> >>
>> >> My concern is that WebGL will get fragmented and that authors will
>> >> start using extensions that are available on a small number of
>> >> implementations degrading the WebGL experience for everyone else. I
>> >> don't think we want to go there at this early stage of development.
>> >
>> > For what it's worth, I am agreeing with Chris on this matter.
>> >
>> > To put it in more abstract terms: being a web specification, WebGL
>> > should (try hard to) be universally implementable.
>> >
>> > Benoit
>> Web is never universal. For example, many Korean website build around
>> ActiveX, and it's only for Windows/IE users. Also, we all know if a
>> web is built in Flash, certain devices won't display it.
> Yeah --- I agree that we must compete with that, otherwise people will
> just keep using such technologies instead of WebGL.
>> Again, I think we should wait, but at certain point when webgl is well
>> known and well perceived, adding kicking ass but none-universal
>> extensions should be on the agenda. Otherwise we are limiting
>> possibilities and holding back potential business/markets.
> Yes, it's a compromise between universality on the one hand, and competing
> with proprietary solutions on the other hand.
> For the /short term/ we seem to be in agreement to be conservative about
> the extensions we add.
> For the /longer term/ I would argue that such 'non-universal' extension
> proposals could be accumulated and rolled together into WebGL 2.0, and we
> could also discuss, for each of them, if they could be made part of WebGL
> 2.0 itself or should remain extensions. In this way, we limit the number
> of different situations (either you're using WebGL 2.0 or you're not); we
> preserve the universal nature of WebGL 1.0; and we would make it a more
> conscious choice on the part of the web developers to use these new
> features that are less widely supported than WebGL 1.0 features.

If there any news of an OpenGL-ES >2.0 in the works?   Since WebGL
applications are likely to become a significant fraction of the users of
OpenGL-ES - maybe it's more productive to push to have these features
adopted into the core of ES...and then there's nothing here for us to

Assuming that's going to happen - it might make sense for people who wish
to lobby for new features to hit up the OpenGL ES folks to get them to
roll them into their core specification.

  -- Steve

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl