Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / RGBA 32 bit float - how many digits?

Author
Message
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 31st Jul 2012 11:21
I can't find in web any clear and exact info - how many digits in 32 bit float (like in RGBA 32 bit float image type)?
I need answer like 1 000 000 000 000 000 000

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st Jul 2012 11:44
256x256x256x256

Or...

4,294,967,296

Health, Ammo, and bacon and eggs!
Nateholio
18
Years of Service
User Offline
Joined: 30th Dec 2005
Location: I\'ve Been Everywhere
Posted: 31st Jul 2012 11:53
I'd guess there's four 8-bit floats in a 32-bit RGBA word.

Not sure exactly what you're after though so here it goes....

There are 32 bits in a 32-bit float. Example:
1011 0011 1000 1001 1011 0011 1000 1001

A 32-bit is broken down into three fields. Sign, exponent, and Mantissa. An IEEE 754 compliant 32-bit float is as follows:
Sign = 1 bit
Exponent = 8 bits
Mantissa = 23 bits

A 32-bit float can represent numbers between approximately:
1.4 x 10^-45
3.4 x 10^38

As for your mention of a 32-bit RGBA float, here is info on 8-bit floats (minifloats).
Sign = 1 bit
Exponent = 4 bits
Mantissa = 3 bits

In a 32-bit RGBA float you'd have four 8-bit minifloats:
10101001 01101001 01010110 10011010

With this said, I'm not exactly sure if GPUs do something similar to the DBP RGB command. If so, then you can probably ignore the minifloats and assume it's a single 32-bit float. Maybe someone around here knows the details.

In Development: K96 - Combat Simulation
Keep your Hope and Change, I choose individual Liberty!
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 31st Jul 2012 12:24
Wait, so RGBA32 means 4 8-bit floats, not 4 32-bit floats?

And one channel float can hold a value up to +- 4 294 967 296?

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st Jul 2012 13:03
Nah, firstly, your not dealing with floats, your dealing with bytes, and what you basically have is a DWORD. A DWORD is made from 4 bytes, or 2 words - and each byte has 8 bits. So 4 x 8bit, or 2 x 16bit, or 1 x 32bit.

So if you pretend that the alpha quotent in RGBA is another colour channel (burple perhaps), then you'd have 4,294,967,296 different colours, instead of the standard 16.7million that we get with 24-bit standard images. The actual range is -2147483648 To 2147483648.

Floats are much more complicated to calculate, as Nateholio shows, I guess it depends on what your trying to do with your 32-bits.

Health, Ammo, and bacon and eggs!
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 31st Jul 2012 13:34 Edited at: 31st Jul 2012 13:35
Well I just stumbled upon note about "packing" RGB to one R32 float. And now trying to understand it.

Nateholio
18
Years of Service
User Offline
Joined: 30th Dec 2005
Location: I\'ve Been Everywhere
Posted: 31st Jul 2012 13:37 Edited at: 31st Jul 2012 13:39
Quote: "Wait, so RGBA32 means 4 8-bit floats, not 4 32-bit floats?

And one channel float can hold a value up to +- 4 294 967 296?"


Ah, I see what you're after now!

Go with what Van B said.

With color values you're dealing with unsigned bytes not floats. Each can be between 0 and 255. The total number of combinations is 4,294,967,296 as Van B pointed out.
You need to be careful when dealing with data. A DWORD (0xFEEDFACE for example) could mean one thing when read/used as a float and something entirely different when read/used as a string or unsigned integer.

Related to this...

What gets me is floats used as color values. I discovered this when writing my DX exporter for terrain. I had it figured out soon enough though. Is there any other examples, relevant to DBP and modeling, where floats are used for colors other than DX?

Edit: Mind posting a link to the note you read?

In Development: K96 - Combat Simulation
Keep your Hope and Change, I choose individual Liberty!
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 31st Jul 2012 13:51
And what about deferred shading, where RGB 32-float or 16-float image is used to store XYZ values? I.e. each channel is more than 255 obviously.

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st Jul 2012 15:17
Quote: "What gets me is floats used as color values. I discovered this when writing my DX exporter for terrain. I had it figured out soon enough though. Is there any other examples, relevant to DBP and modeling, where floats are used for colors other than DX?"


Shaders tend to use floats instead of byte values, like setting a light or fog colour in a shader tends to be {0.6,0.2,0.6,1.0}, that sort of format. If you look right back, when raytracing was the in-thing, the POV file format used floats for this stuff as well, so you'd think it would be more of a standard. I guess it's better for abstraction, to just multiply the floats by the actual range limit, rather than assuming anything. For instance, if you say that a light uses 0.5 red, that's half of the maximum limit and that's a stable standard to use. As opposed to if you said, a light uses 128 red - that makes the assumtion that 255 is the limit. The data you have suddenly becomes dependant on the 8-bit per channel format - there is no way to know that 255 is the limit, it could be 1024, it could be higher than that. We don't know that 0-255 will be our limits for colouring, so it's safer to use floats. In the next 5 years, we might have double the bit depth for colouring, meaning limits of 0-65,000 (est) - if the standard isn't established, then it's best to abstract it. Imagine running a shader that uses byte values in a 64-bit output - everything would be practically pitch black and translucent.

I guess it figures in HDR rendering a lot, it's easier to say something is twice as bright as it can possibly be by using 2.0 than using 512 - for things like proper bloom shading for example.

When actually storing this data though, you might never want to store colour as floats, it's fine to have human readable shader files, a little bloat is no big deal - but if you were storing an image, or vertex colouring data, you could easily end up using 4 bytes (DWORD float) for each colour element... so using floats means 4 times the data footprint compared with bytes, whether the data needs it or not. Let's face it, 32-bit is plenty for storing a pixel colour, for the time being at least - we don't know what the next standard will be, maybe we'll even see 3D data being imbedded directly into new image formats.

Health, Ammo, and bacon and eggs!
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st Jul 2012 15:26
Quote: "And what about deferred shading, where RGB 32-float or 16-float image is used to store XYZ values? I.e. each channel is more than 255 obviously."


With normal maps, the byte limit comes into effect, although alpha is often not used at all. So the X component in a normal map might be the red channel, -127 to 127, stored as a byte.

Not sure if that's what you mean. Anyway, advanced rendering stuff like this is one area where more bit depth would help, especially rendering depth textures - 256 levels is not a lot when it comes to depth rendering - doubling that to 65,000+ levels by adding an extra byte would make a huge difference. Normal maps though, really the ranges should be fine, it's just the actual resolution of normal maps that can affect the quality more than anything. I'm sure we've all see dodgy normal maps in games like Oblivion, and just wish they hadn't bothered.

Health, Ammo, and bacon and eggs!
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 31st Jul 2012 15:26 Edited at: 31st Jul 2012 15:29
If you're talking about the directx image format D3DFMT_A32B32G32R32F, then each channel consists of a 32-bit float.

A 32-bit float has:
Sign = 1 bit
Exponent = 8 bits
Mantissa = 23 bits

However, the mantissa has a hidden implicit bit at the start so can store 24 significant binary digits.

In decimal this will be 24 * log(2)/log(10) = 7.225 significant figures.

The exponent ranges from -127 to 126 (-128 and 127 are for special values) so you can store any positive or negative value between 2^-127 and 2^126 to an accuracy of about 7 significant figures.

In decimal this is about 10^-38 to 10^38, so you can store values of the form:

+/- x.xxxxxx * 10^y

Where -38 <= y <= 38.

Plus there are special values for positive and negative zero, positive and negative infinity, and not a number, as well as the denormalized numbers which can be smaller than the limit above but are stored to less accuracy.

[b]
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 31st Jul 2012 19:30
So 3 values with range 0.00—1.00 will fit float: 100100100
And 38 means 100000000000000000000000000000000000000 ?

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 31st Jul 2012 19:46
Quote: "So 3 values with range 0.00—1.00 will fit float: 100100100"

I have no idea what you mean by that.

Quote: "And 38 means 100000000000000000000000000000000000000 ?"

That number is the same order of magnitude as the largest number which can be stored in a float, yes.

[b]
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 1st Aug 2012 10:10 Edited at: 1st Aug 2012 10:14
Quote: "I have no idea what you mean by that"

Packing 3 values into one:
R: 124
G: 128
B: 111

Btw, could unpack.g be optimized?

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 1st Aug 2012 14:08 Edited at: 1st Aug 2012 14:09
If this is a shader, why don't you use an RGB format and then you won't need to pack them, if it's not a shader, I'm not sure why you want to pack RGB into a float but you would be better off converting to a standard RGBA colour in an integer like DBPro, and then casting that to a float like so:


Trying to pack values into a float like you are doing above will always be very inaccurate because the possible floating point values are not evenly distributed.

[b]
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 1st Aug 2012 14:31
It's a shader.
Quote: "floating point values are not evenly distributed"

I am not using floating point values, only integer. Also I had no choice - RGBA32 float image type.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 1st Aug 2012 16:12 Edited at: 1st Aug 2012 16:12
Quote: "I am not using floating point values, only integer."


You are trying to pack values into a float, not an integer, therefore the fact that floating point values are not evenly distributed will be a problem.

Quote: "RGBA32 float image type."


There is no such image type, I'm assuming you mean D3DFMT_A32B32G32R32F in which case you don't need to pack anything as it has 4 channels, each of which is a float.

[b]
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 1st Aug 2012 16:51
Well I have a weak machine so I want to pack world position and wnorld normals into one texture, it will save me one extra camera.

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 1st Aug 2012 17:35
You don't need to store world position, you just need to store the depth. The position can be calculated implicitly from the location of the pixel and the depth value. Depth + normal = 4 values.

[b]
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 2nd Aug 2012 09:22 Edited at: 2nd Aug 2012 09:24
@Diggsey
That is incredibly interesting! I've searched gamedev site and found this piece:

VS:
Quote: "float4 ReconstructWorldPosFromScreenDepth (float z, float2 ScreenPos)
{
float x = ScreenPos.x;
float y = ScreenPos.y;
float4 pos = mul(float4(x, y, z, 1.0f), matViewProjInv);
pos.xyz = pos.xyz / pos.www;
pos.w = 1.0f;
return pos;
}"


PS:
Quote: "float z = tex2D(PositionMap, TexCoords).r;
clip(z - 0.000001f);
float4 pos = ReconstructWorldPosFromScreenDepth(z, ScreenPos);"


Could you explain what matrix is used (matViewProjInv), what is a ScreenPos and is that code workable?

Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 2nd Aug 2012 17:31
The view matrix converts coordinates from world space to camera space. The projection matrix converts coordinates from camera space to screen space (ie. an x, y coordinate pair and a depth).

When you multiply matrices you combine their effects, so ViewProj would convert directly from world space to screen space. When you invert a matrix it will do the opposite, so ViewProjInv will convert from screen space back to world space, which is exactly what you want.

DBPro will automatically fill in matrix parameters in your shader which are annotated correctly, however I'm not sure there's one for ViewProjInv. You may have to calculate it yourself with the 3d maths commands.

[b]
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 2nd Aug 2012 19:46
Kind of on-topic, what exactly happens when I try to compute two floats with each other when they are extremely far apart?



TheComet


Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 2nd Aug 2012 21:53
With a number as large as 10000000000000000000 floats aren't even accurate to the nearest whole number, so adding 0.0000000000000001 will have no effect. In fact trying to store 10000000000000000000 in a float will give a different number accurate to about the nearest 10000000000000 - ie. not accurate at all.

Multiplying them shouldn't be a problem though, since the exponents will cancel.

[b]
mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 3rd Aug 2012 09:27 Edited at: 3rd Aug 2012 10:40
Thanks, Diggsey!
As I understand, ScreenPos = mul(IN.POS,WorldViewProj)? Or mul(IN.POS,ViewProj)?

Also, is that inverse matrix? --- matrix ViewInv:ViewInverse;

mr Handy
16
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 5th Aug 2012 08:34
@ Moderators

Could you please move this thread to DBP discussion thread?

Login to post a reply

Server time is: 2024-03-29 00:17:47
Your offset time is: 2024-03-29 00:17:47