Hi there,

i've some questions about compression tricks in mind.

Because trying those all is a lot of work i'd like to hear anything from people who already have some experience.

I'm using OpenCL on GPU, but API should not matter here.

1. E.g i have a normal in xyz and a radius in w component of a vec4, but now i want a cone angle too. I see those options:

Either convert the normal to spherical coords so needing only two values.

Or pack two half floats in the last component.

Or create another buffer or tex to store the additional stuff.

Is there an answer like 'mostly option 2 is the fastest way, because trig is slow',

Or is it more like 'it totally depends on usecase'?

2. I do GI and cover the geometry with samples at 10x10cm resolution.

Can i expect using half floats for everything (position, direction, color...)

should be accurate enough for a 1km game world?

Is this usually done only for memory savings or can it help / hurt performance too?

Use fixed-point numbers for position. There is nothing special about the origin, so you don't need more resolution there than elsewhere. There are 1Km/10cm = 10,000, so you are going to need at least 14 bits to represent that. So 16-bit integers would do just fine.

I forgot to say that i will center at camera, close samples are small and distants are large - typical LOD solution.

For position i must keep the floats in mem and it's more a question of a performance win.

According to the link decoding spherical coords on 5870 is quite fast.

Thanks! :)

This is a nice article about compressing normals (in a g-buffer): http://aras-p.info/texts/CompactNormalStorage.html

In general, the trend on modern hardware seems to be that math gets cheaper and cheaper while bandwidth gets (relatively) more expensive. So compression at the cost of a few ops is often worthwhile. It does depend on the specific hardware and use case though (and I'm no expert).

I think half floats would struggle a bit to cover 1000m at 0.1m intervals. A half float is only 16 bits so only has 65536 possible values, plus most of them will be focused close to zero, so perhaps not appropriate for position data. Half floats are probably fine for direction and colour though.

I found this a while back. Still have yet to go through and read all of it, but it looked interesting. http://jcgt.org/published/0003/02/01/paper.pdf

Huh! - seems it's possible to make out a science of really everything :D

Funny that i somehow use the same 'group normals to octants' idea to quickly reject backfacing branches of the samples tree, which is why need the cone angle.

Maybe it's enough to use some integer bits to store the angle after the tree has been build.