WebGL Experiments: Illyriad’s 3d Town
Ben Adams
space to unlock mouse look):
http://blog.illyriad.co.uk/index.php/2011/11/webgl-experiments-illyriads-3d-town/
The aim of this was not to overly optimise and see what we could do at
the extremes (or rather where we thought the extremes were). It only
works in Chrome as compatibility wasn't the name of the game (mainly
as we couldn't track down what was causing issues in FF in time). All
future releases from us will be aimed at broad compatibility.
These are the lessons we have learnt on the way:
- Small jpegs expand to huge uncompressed textures in ram and while
saving on bandwidth you will quickly hit virtual memory swap on even
mid-ranged computers.
- You can do texture decompression in a pixel shader; however you also
need to do your own bilinear filtering and switch of mipmaping to
achieve it.
- You can't provide your own mipmaps to overcome the previous point -
perhaps a depth based FSAA post render could resolve this?
- It is possible to do performant deferred shading in WebGL, however
without multiple render targets you need floating point textures to
pack the extra info for a single pass of the main geometry.
- Loading 70 large models _when cached_ via webworkers will "snap" the
page in Chrome (need to develop a small exampler and raise a bug on
this one); hence the throttled loading
- We need to go smaller/smarter still on texture size - while it
preforms well once loaded - it takes a long time to download and
initialise.
- We need to go smaller/smarter still on model size - again while it
preforms well once loaded - it takes a long time to download and
initialise.
Generally we are very happy with the results and are now comfortable
to use WebGL in anger (as it were...) and for release.
Hope this is of interest
Kind regards
Ben Adams
www.illyriad.co.uk
Kenneth Russell
> A little tester/teaser of the 3d town we are building (remember to hit
> space to unlock mouse look):
>
> http://blog.illyriad.co.uk/index.php/2011/11/webgl-experiments-illyriads-3d-town/
Very nice! It was nice to see this at the New Game conference and it's
great that you've made it available.
> The aim of this was not to overly optimise and see what we could do at
> the extremes (or rather where we thought the extremes were). It only
> works in Chrome as compatibility wasn't the name of the game (mainly
> as we couldn't track down what was causing issues in FF in time). All
> future releases from us will be aimed at broad compatibility.
>
> These are the lessons we have learnt on the way:
> - Small jpegs expand to huge uncompressed textures in ram and while
> saving on bandwidth you will quickly hit virtual memory swap on even
> mid-ranged computers.
> - You can do texture decompression in a pixel shader; however you also
> need to do your own bilinear filtering and switch of mipmaping to
> achieve it.
> - You can't provide your own mipmaps to overcome the previous point -
> perhaps a depth based FSAA post render could resolve this?
> - It is possible to do performant deferred shading in WebGL, however
> without multiple render targets you need floating point textures to
> pack the extra info for a single pass of the main geometry.
> - Loading 70 large models _when cached_ via webworkers will "snap" the
> page in Chrome (need to develop a small exampler and raise a bug on
> this one); hence the throttled loading
How are you managing your workers? Are you spawning one worker per
model? If so, that is not a good idea -- you should maintain a small
pool of workers and distribute the work to them. Some recent changes
in Chrome's worker implementation which generally improve performance
significantly also changed the behavior in this area. The ro.me demo
was affected by these changes; see http://crbug.com/102158 .
-Ken
Ben Adams
Glad you like. We've learnt a _huge_ amount from the implementation
and a very pleased that it performs well with what we now think is an
exceptionally heavy weight implementation. This means what we will be
able to do by doing things smarter and optimizing will be quite
remarkable.
Yes, looks like same issue and we had to add our own throttling
routine. I believe the latest version of Three.js already has some
fixes in too. Its good to see this being fixed from both sides and
just how quickly both teams have fixed it so shortly after it being
raised - much kudos!
As a side question - does anyone know if the lack of OES_texture_float
(floating point textures) on the Chromebook Series 5 is it a hardware
limitation or a software one? (i.e. can't happen vs. will happen
later?) As we use floating point textures to do deferred shading which
gets us round lack of multiple render targets - and still avoid
multiple geometry passes.
Ben
On Nov 11, 7:57 pm, Kenneth Russell <k...@chromium.org> wrote:
> > A little tester/teaser of the 3d town we are building (remember to hit
> > space to unlock mouse look):
>
Kenneth Russell
> Hi Ken
>
> Glad you like. We've learnt a _huge_ amount from the implementation
> and a very pleased that it performs well with what we now think is an
> exceptionally heavy weight implementation. This means what we will be
> able to do by doing things smarter and optimizing will be quite
> remarkable.
>
> Yes, looks like same issue and we had to add our own throttling
> routine. I believe the latest version of Three.js already has some
> fixes in too. Its good to see this being fixed from both sides and
> just how quickly both teams have fixed it so shortly after it being
> raised - much kudos!
>
> As a side question - does anyone know if the lack of OES_texture_float
> (floating point textures) on the Chromebook Series 5 is it a hardware
> limitation or a software one? (i.e. can't happen vs. will happen
> later?) As we use floating point textures to do deferred shading which
> gets us round lack of multiple render targets - and still avoid
> multiple geometry passes.
I asked one of the team members and it's a hardware limitation.
-Ken