[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL 1.0 ratified and released
- To: "L. Van Warren" <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] WebGL 1.0 ratified and released
- From: Steve Baker <email@example.com>
- Date: Tue, 08 Mar 2011 18:40:50 -0600
- Cc: "'public webgl'" <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=vglBs CP4HxzIW3k9GjfvkKEtC5s=; b=aYMsDAhKaCgu4c//CTK51RnUuhz3ybBay6QfE x+n+RexLdx3ARyqar6sft6Aq3pErJU5HF5QM+a5Hxr7pmtZnc0/GmEhntEoLyiAB AF6kptQLu0tceyyMxEusvCCHkED/qMS8M3gIzSCxvJVlwZRlGJGKeAl++Vg8sgD2 s2UldA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=VIeJeQ3wCHBpu1LOF1ZiaXI+MUnkxvQI5SF/JB+60BqNb1oO/WR3vHnJmEsL4 BHGuFXCugD2Xp0rxClKJGGnOHtZM3Bd4QV7+I/Q8VXlmwiG5gG+rit/4hmZoXBqX rNR6fEQZm24WJ5ME9G131Mqp9DSTivOZgWaXNEkQB8i99U=
- In-reply-to: <003501cbddd8$0b16a920$2143fb60$@com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4D7028A3.email@example.com> <firstname.lastname@example.org> <F6335B97-4C05-46B9-975E-F27B5F36DC9B@apple.com> <003501cbddd8$0b16a920$2143fb60$@com>
- Sender: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11
The trouble is that we're based around OpenGL ES 2 - which doesn't have
double precision...also, we're aiming to be a portable standard and the
number of people who have hardware that can cope are still pretty minimal.
With any specification process - you can always be looking over the next
hill saying "We have to have that new feature that's JUST becoming
available" - but by the time you've waited, there's another big thing
just over the next hill after that. At some point you have to stick a
stake in the ground and say "this is it" and mean it...and that's been done.
What we have runs on fairly old desktop GPU's (it runs on my nVidia
6800) and on iPhone4/Android2.x types of system. That's a pretty good
line to draw - a large fraction of the market will be able to run the
full WebGL spec - either now or by the end of the year when their
iPhone3/Android1.x lock-in contracts expire. Most of the 'pad' computers
purchased during the present marketting tsunami should be able to run it
If we insisted on 64 bit support - maybe 1% of people would be able to
run it. Nobody would find it worth writing for - it would die just like
it's predecessors (anyone still use VRML?!).
So even if we had 64 bit support, it could only be at best a poorly
supported extension and your code would have to be written to fall back
on 32 bit...or less actually...we don't even have core support for
floating point textures, and I suspect that a system with 16 bit
"half-float" in the GPU would still be compliant.
The critical extensions right now (IMHO) are: Floating point texture,
depth rendering to an FBO, vertex textures, multiple-render-targets,
support for ddx()/ddy().
This isn't the last ever version of WebGL - future revisions can do this
stuff. We had to get something out of the door.
On 03/08/2011 03:30 PM, L. Van Warren wrote:
> I’m an old graphics guy, who trained in the Utah Graphics Lab in the
> mid 1980’s.
> Looking over the new WebGL standard gives a moment for reflection of
> the great strides that have been taken.
> Public standards like this are really important.
> My only concern is that double precision arithmetic is not being
> Perhaps with modern graphics GPU’s 64 bit arithmetic is a bottleneck
> or a hassle, I don’t know.
> I just recall a family of problems which went away when we computed in
> double precision.
> The images were much crisper and easier to filter properly.
> These issues came up in intersection calculations that were
> numerically brittle, such as the intersections of nearly parallel
> lines in perspective, etc.
> Other than this it looks great.
> - L. Van Warren MS CS AE / wdv.com
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: