Sign in to follow this  

Compression questions

This topic is 1121 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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! :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

This topic is 1121 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this