Comments on: Encoding floats to RGBA – the final? http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/ Random thoughts of a triangle pusher Sat, 19 May 2012 10:53:32 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Alkis http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-173874 Alkis Thu, 09 Feb 2012 18:28:07 +0000 http://aras-p.info/blog/?p=369#comment-173874 Great and very precise! However, the .w component of the original float4 does not get decoded. Great and very precise!
However, the .w component of the original float4 does not get decoded.

]]> By: Marc http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-121601 Marc Fri, 19 Aug 2011 14:59:07 +0000 http://aras-p.info/blog/?p=369#comment-121601 Aras, This technique works beautifully. Thank you for the post. I'm encoding on the CPU for a target that doesn't support floating point textures. The solution is dead on. Regards, Marc Aras,

This technique works beautifully. Thank you for the post.

I’m encoding on the CPU for a target that doesn’t support floating point textures. The solution is dead on.

Regards,

Marc

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-33431 Aras Pranckevičius Fri, 11 Jun 2010 03:35:17 +0000 http://aras-p.info/blog/?p=369#comment-33431 @stephen: this is HLSL/Cg code. And unlike C/C++ compilers, shader compilers are allowed to change divisions into multiplications by inverse (even if it's not exactly the same under floating point). So this actually compiles into multiplications by inverses already. @stephen: this is HLSL/Cg code. And unlike C/C++ compilers, shader compilers are allowed to change divisions into multiplications by inverse (even if it’s not exactly the same under floating point). So this actually compiles into multiplications by inverses already.

]]> By: stephen http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-33422 stephen Fri, 11 Jun 2010 00:00:23 +0000 http://aras-p.info/blog/?p=369#comment-33422 would it be quicker and would you lose any precision if you precalculated the divisions as constants like const float x = 1.0/255.0; const float y = 1/65025.0; const float z = 1/16581375.0; inline float4 EncodeFloatRGBA( float v ) { float4 enc = float4(1.0, 255.0, 65025.0, 16581375.0) * v; enc = frac(enc); enc -= enc.yzww * float4(x,x,x,0.0); return enc; } inline float DecodeFloatRGBA( float4 rgba ) { return dot( rgba, float4(1.0, x, y,z) ); } would it be quicker and would you lose any precision if you precalculated the divisions as constants like

const float x = 1.0/255.0;
const float y = 1/65025.0;
const float z = 1/16581375.0;

inline float4 EncodeFloatRGBA( float v ) {
float4 enc = float4(1.0, 255.0, 65025.0, 16581375.0) * v;
enc = frac(enc);
enc -= enc.yzww * float4(x,x,x,0.0);
return enc;
}
inline float DecodeFloatRGBA( float4 rgba ) {
return dot( rgba, float4(1.0, x, y,z) );
}

]]> By: Real-Time Rendering » Blog Archive » Clearing the Queue http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20919 Real-Time Rendering » Blog Archive » Clearing the Queue Thu, 17 Sep 2009 17:55:16 +0000 http://aras-p.info/blog/?p=369#comment-20919 [...] is worthwhile for a developer making this decision. Aras’ blog has other nice bits such as packing a float into RGBA and SSAO [...] [...] is worthwhile for a developer making this decision. Aras’ blog has other nice bits such as packing a float into RGBA and SSAO [...]

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20918 Aras Pranckevičius Thu, 17 Sep 2009 17:47:42 +0000 http://aras-p.info/blog/?p=369#comment-20918 @imbusy: whoops, yeah. @imbusy: whoops, yeah.

]]> By: imbusy http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20908 imbusy Thu, 17 Sep 2009 10:37:56 +0000 http://aras-p.info/blog/?p=369#comment-20908 255^0 = 1 255^1 = 255 255^2 = 65025 255^3 = 16581375 Shouldn't the last component be 16581375 instead of 160581375? 255^0 = 1
255^1 = 255
255^2 = 65025
255^3 = 16581375
Shouldn’t the last component be 16581375 instead of 160581375?

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20211 Aras Pranckevičius Tue, 04 Aug 2009 09:59:21 +0000 http://aras-p.info/blog/?p=369#comment-20211 @Pat: I've experimented with spherical and spheremap based normal encodings. Here are my results so far: <a href="http://aras-p.info/texts/CompactNormalStorage.html" rel="nofollow">article link</a>. @Pat: I’ve experimented with spherical and spheremap based normal encodings. Here are my results so far: article link.

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20183 Aras Pranckevičius Sun, 02 Aug 2009 14:59:55 +0000 http://aras-p.info/blog/?p=369#comment-20183 @corysama: yeah, I've tried your approach as well. It works when done on the CPU, but has small errors here and there when done on the GPU. @corysama: yeah, I’ve tried your approach as well. It works when done on the CPU, but has small errors here and there when done on the GPU.

]]> By: goryh http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20181 goryh Sun, 02 Aug 2009 14:21:01 +0000 http://aras-p.info/blog/?p=369#comment-20181 That’s great! It's a perfect match for storing depth in texture for our depth pass. My previous approach was based on storing integral and fractional parts of log2 of depth (multiplied by 16) and future decoding with exp2. It required only 2 channels of texture and with perfectly precision restored original depth value, but takes 7 instructions for encoding and 3 for decoding. Your new approach takes only 3 and 2 instruction respectively with the same precision (I can’t find any differences in precision test). Thanks. That’s great!
It’s a perfect match for storing depth in texture for our depth pass. My previous approach was based on storing integral and fractional parts of log2 of depth (multiplied by 16) and future decoding with exp2. It required only 2 channels of texture and with perfectly precision restored original depth value, but takes 7 instructions for encoding and 3 for decoding. Your new approach takes only 3 and 2 instruction respectively with the same precision (I can’t find any differences in precision test).
Thanks.

]]> By: corysama http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20161 corysama Sat, 01 Aug 2009 06:36:10 +0000 http://aras-p.info/blog/?p=369#comment-20161 I haven't tested this as thoroughly as you have been, but it still might help you out. Check out my post in this thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=486847 I haven’t tested this as thoroughly as you have been, but it still might help you out. Check out my post in this thread:

http://www.gamedev.net/community/forums/topic.asp?topic_id=486847

]]> By: Pat Wilson http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20153 Pat Wilson Thu, 30 Jul 2009 19:09:51 +0000 http://aras-p.info/blog/?p=369#comment-20153 @Aras: Yeah I am really a big fan of spherical normals. They take more operations, but the assumption that is floating around about view-space normals not having a -z is totally false, so you need to either store spherical normals, or you need to reserve a bit (somewhere) for +/- on the Z value you reconstruct via sqrt(1 - x * x + y * y). I did some performance testing a while ago that seemed to indicate that sampling a texture for atan2() is better than actually performing atan2(), especially on older ATI cards, but my current implementation doesn't do this. I want to re-run the test first. @Aras: Yeah I am really a big fan of spherical normals. They take more operations, but the assumption that is floating around about view-space normals not having a -z is totally false, so you need to either store spherical normals, or you need to reserve a bit (somewhere) for +/- on the Z value you reconstruct via sqrt(1 – x * x + y * y).

I did some performance testing a while ago that seemed to indicate that sampling a texture for atan2() is better than actually performing atan2(), especially on older ATI cards, but my current implementation doesn’t do this. I want to re-run the test first.

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20152 Aras Pranckevičius Thu, 30 Jul 2009 18:55:31 +0000 http://aras-p.info/blog/?p=369#comment-20152 @Pat: well, you are a step ahead on encoding normals in two channels :P Figuring out a good encoding for normals is next step on my list. Is the spherical encoding the one you settled on? @Pat: well, you are a step ahead on encoding normals in two channels :P

Figuring out a good encoding for normals is next step on my list. Is the spherical encoding the one you settled on?

]]> By: Pat Wilson http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20151 Pat Wilson Thu, 30 Jul 2009 18:48:36 +0000 http://aras-p.info/blog/?p=369#comment-20151 Aras, you have an uncanny ability to be working on the same things I am working on, with similar results. You were a step ahead of me on this one :) Aras, you have an uncanny ability to be working on the same things I am working on, with similar results. You were a step ahead of me on this one :)

]]> By: Aras Pranckevičius http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20149 Aras Pranckevičius Thu, 30 Jul 2009 17:41:32 +0000 http://aras-p.info/blog/?p=369#comment-20149 I don't think hardware does gamma correction, unless I tell it to. I'm not setting sRGB states on the samplers or on the framebuffer writes. I don’t think hardware does gamma correction, unless I tell it to. I’m not setting sRGB states on the samplers or on the framebuffer writes.

]]> By: steve http://aras-p.info/blog/2009/07/30/encoding-floats-to-rgba-the-final/#comment-20148 steve Thu, 30 Jul 2009 17:31:30 +0000 http://aras-p.info/blog/?p=369#comment-20148 Maybe the problems you're having are related to gamma correction? The hardware is by default going to try to gamma correct the output of the fragment program, but you don't want that if you want to keep predictable levels of precision. Also, when you sample back out of the texture the reverse gamma correction is also applied, since it's assumed that artists designed the texture in gamma space. There's a good article in GPU Gems 3 about this that might help: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html . Obviously they're talking about lighting accuracy but maybe it's an issue in your case too. Maybe the problems you’re having are related to gamma correction?

The hardware is by default going to try to gamma correct the output of the fragment program, but you don’t want that if you want to keep predictable levels of precision. Also, when you sample back out of the texture the reverse gamma correction is also applied, since it’s assumed that artists designed the texture in gamma space.

There’s a good article in GPU Gems 3 about this that might help: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html . Obviously they’re talking about lighting accuracy but maybe it’s an issue in your case too.

]]>