[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] Re: ETC compression method.
Thanks Mark. That's great info! I can figure it out from there.
So if I'm reading this correctly, basically, ETC1 gives us 6x
compression on 8/8/8 RGB data (compared to - for comparison - 8x
compression with the DXT1 method) - with two unique 4/4/4 colors or two
rather similar 5/5/5 colors per 4x4 texel block - split into the top and
bottom (or left and right) halves of the block and some intensity
(sort-of) variation between the texels within each half. But there
doesn't seem to be any blending of color within the 4x2 block so the
color changes will alias rather badly - while intensity variations
should be reasonably well represented.
I'm guessing it'll look sharper than DXT1 but with poorer color
resolution/precision. That should work reasonably well when the image
isn't magnified because our eyes don't need color at such high frequency
as they need monochrome data. But when the texture is magnified, ETC
color is likely to look pretty blocky.
I presume ETC1 does a terrible job of encoding normal maps because the
per-texel "intensity" variations will just have to be re-normalized out
again in the shader - leaving just two 4/4/4 normals per 4x4 block. On
paper you'd be way better off just dropping the texture resolution by a
factor of two and storing your normals as 5/6/5 (not using compression
at all) than using ETC1.
It'll be interesting to see what happens in ETC2.
Mark Callow wrote:
> Hi Steve,
> The only public description I know of is in the
> extension spec. There are presentations that Jacob made to the Khronos
> Group which would give you the information you are looking for but I
> cannot turn them lose. Jacob is on vacation until the near the end of
> this month. Once he returns I'll ask him if he can release one of his
> Note that ETC1 is for RGB. For alpha you'll have to wait for ETC2.
> ETC is certainly an unfortunate name from the point of view of web
> On 2010/08/09 12:39, firstname.lastname@example.org wrote:
>> It's great to hear that we'll have a compressed texture format available.
>> The weakest link in doing web-based 3D graphics is the time the textures
>> take to load - so this is a critical issue.
>> Sadly, I have never worked with ETC images (although I know a lot about DXT).
>> Does anyone know of a readable online description of how ETC compresses
>> data? I hate to have to figure it out from the 'etcpack' stuff. I
>> presume it's a lossy scheme - and I need to understand how it loses so
>> that I can advise my artists on when they can usefully use compression and
>> when they cannot. eg: Can I compress normal maps without getting horrible
>> artifacting? Is it better to store RGB and A in separate maps rather than
>> trying to compress them together? What is the trade-off between using
>> lower resolution uncompressed maps versus higher resolution compressed
>> A Google search doesn't turn up anything interesting (because 'ETC'
>> matches 'etcetera') and the Wikipedia article on ETC is about one line
>> long! (cf gallons of available documentation on DXTn compression).
>> -- Steve
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: