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

Re: [Public WebGL] Volume Textures



How does this bench against hardware trilinear?

On Fri, Mar 25, 2011 at 7:06 AM, Thatcher Ulrich <tu@tulrich.com> wrote:
John -- the code to do a trilinear sample is pretty short.  I'm
wondering if you could test this to see if it works for you.  I just
typed this up and compiled it, but didn't test it, so no guarantees:

// Tex is a "simulated" 3D 256x256x256 texture -- a 4096x4096 2D
// texture, made up of 256x256 tiles, arranged in a 16x16 pattern.
// The tiles are z-slices, minimum z in lower left, increasing
// left-to-right and bottom-to-top.
vec4 texture3D(sampler2D tex, vec3 xyz) {
 // Find the two adjacent z slices, take a 2D sample from each, and
 // blend them together.

 vec3 xyz_256 = xyz * 256.0;
 float z = xyz_256.z;
 // TODO: z0,z1 could be put in a vec2; then floor() and mod()
 // below could be vectorized.
 float z0 = floor(z);
 float z1 = z0 + 1.0;
 float zblend = z - z0;

 // Choose the tiles.
 vec2 offset0 = vec2(floor(z0 / 16.0), mod(z0, 16.0)) * 256.0;
 vec2 offset1 = vec2(floor(z1 / 16.0), mod(z1, 16.0)) * 256.0;

 // Sample the tiles.
 vec4 s0 = texture2D(tex, (offset0 + xyz_256.xy) / 4096.0);
 vec4 s1 = texture2D(tex, (offset1 + xyz_256.xy) / 4096.0);

 return mix(s0, s1, zblend);
}

-T

On Fri, Mar 25, 2011 at 11:20 AM, John Davis <jdavis@pcprogramming.com> wrote:
> Wait how long?  Can't we at least start the Angle work?  I'm guessing the
> changes will take a few months, and then there will be testing.
>
> On Thu, Mar 24, 2011 at 11:12 PM, Mo, Zhenyao <zhenyao@gmail.com> wrote:
>>
>> 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.
>>
>> 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.
>>
>> > -----------------------------------------------------------
>> > 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
>> > -----------------------------------------------------------
>> >
>> >
>>
>
>