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

Re: [Public WebGL] Progressive loading

Alvaro Segura said:

> Some WebGL applications suffer
> from delays in inlitialization due to several reasons: texture
> downloads, shader compiling, mesh data downloads.<br>

> Applications with many and/or very large textures have to way
> for them to be fully downloaded before they can be loaded into
> WebGL. Usually their onload event is used. Before that textures
> are "black". It would be beneficial to support progressive
> texture loading so that the user does not see a frozen scene but
> sees some progress going on.

It would be neat to have progressive loading of textures so you could
start the game playing with blurry maps and have them gradually sharpen
up...but for most 3D apps, we need MIPmapped textures - and progressively
loading the main image and producing progressively loaded MIPmaps on the
fly...well, it's not impossible, but with some file formats it would be
really complicated!

What you really need to do this well is a file format where the MIP levels
are stored explicitly from the 1x1 up to the NxN - and to have each texel
stored as the difference between its' value and the corresponding texel in
the MIP level beneath it so you don't need so many bits to store these
difference value and the file size doesn't just get 33% larger.  That way
the loader would only have to load each MIP level in turn.

However, couldn't you do nearly as well by generating the top couple of
MIP levels yourself into separate files - then just write code to load
lower MIP level files first.

You'd load a little bit more data - but if you stored just the top level
map and a map (say) two MIP levels down, the extra files would be only
1/16th the amount of data and would load something close to 16 times
faster...then when you have them all loaded, start the game running and
replace them as the high resolution maps load.  This would only increase
the amount of data to transfer by ~8% and produce more or less the effect
you're aiming for here.

  -- 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