floating point images and java3d

Engines, Libraries and Tools Java 3D
#1

New and advanced graphic cards (radeon 9800) makes it possible to render 128 bits pixels (4*32 bits float components). I’d love to know if java3d would eventually be able to render using that modes.
Unfortunatly, i don’t have that card, and i don’t know what are the restrictions(if any) or api to do that. Maybe Opengl does it automatically if available (as it does for t&l), then i’ll be a happy coder. If not, any idea of the possibility to access such feature with j3d 1.3.1, or j3d 1.4?
Is it a DirectX only feature?

Thanks.

#2

Yeah, OpenGL has no problems with that. In straight C, a glColor call can normally accept floating point components up to 64-bit, but technically it can go up to whatever the host platform can express. As this is a 64-bit “double” on 32-bit Intel architecture, we’re good up to 256-bit pixels.

When the move to 64-bit desktop architectures finally begins, we’ll be good up to 512-bit pixels… ;D

Assuming DirectX can keep up with that, theoretically there’s no reason why Java3D can’t support it, in time.

#3

heh, that would be fun.
Well, provided i give a bufferedImage stuffed with a float DataBuffer, do you think a texture will be converted by j3d to 8 bits ARGB, or will be kept as is? (being kept would certainly be excellent for me. :slight_smile: )

#4

[quote]New and advanced graphic cards (radeon 9800) makes it possible to render 128 bits
[/quote]
No, ATI is 96 bits, its GeForceFX that has 128

It doesnt work like that. The floating point is used inside the algorithms for calculating the colour you will end up seeing on the screen. This means that existing programs AND Java3D will automaticaly use it. :slight_smile:

The problem of integers is that they have to be multiplied and divided in the process of calculating the final colour on your screen(T&L). This means that your 8 bits per colour can be reduced to e.g. 5 bits per colour because of rounding errors. If you then have a very bright or very dark scene that makes the number of bits you have to play with even smaller. Using floating point operations inside these calculations will prevent the loss of colour information and a nice gamma correction will scale it back to the colour domain the monitor uses(will be 10 bit integers per colour for GeForce FX).

The conclusion:
You get great benefit from floating points cards even using 8bit per colour on your textures and lights.

The extra bits is NOT for giving you alot more different colours to play with, the human eye cant distingish more than 10bit per colour anyway.

BTW. 10 bit per colour gives 1.073.741.824 different colours. That is way more than enough. (8 bit is 16.777.216)

#5

[quote]No, ATI is 96 bits, its GeForceFX that has 128
[/quote]
What i read from here:
http://mirror.ati.com/products/pc/radeon9800pro/specs.html
is that:
“128-bit, 64-bit & 32-bit per pixel floating point color formats”.
How do you read that and make it 96 bits? or maybe this is marketing fuzz? Please explain.

Hem, you"ll get some flames on this 'eye can only see 10 bits, bla bla bla"…
Anyway, i’m not interested in floating point images just for the beauty of what it could eventually give on a screen, or whatever. I work on images with very big precision, and using such features could give me possibilities to accelerate using hardware. See, i need that precision for the exact reason you gave: after multiple filters, quality is bad using integers, while best using floats. My eye might be seeing only 5 bits, i’ll still need that floats to be used.

From what i read at ati, it says that it will render floating point images. I’d love to read a pages that says the opposite.

#6

The pixel pipelines are 96 bit, so some color data is lost. What I am saying is its not 128 bits in the entire pipeline. For me a chain is only as good as the weakest link…

Hehe, smart to use the hardware in this way.

I didnt say you cant, just didnt expect you to be needing it. :slight_smile:

Regards
Nikolai

#7

[quote] The pixel pipelines are 96 bit, so some color data is lost. What I am saying is its not 128 bits in the entire pipeline. For me a chain is only as good as the weakest link…
[/quote]
True. Nevertheless i found nothing on the internal pipeline. Any link? :slight_smile:

#8

http://firingsquad.gamers.com/hardware/radeon_9700/page2.asp

http://www.extremetech.com/article2/0,3973,710342,00.asp

http://www.penstarsys.com/editor/Today/nvidia3/nvda_tdy_5.htm

http://www.onethumb.com/index.mg?EntryID=12

And thousands site like these, that you can search on google.

#9

hmmmmm I seem to remember a document describing 9700 as not “true” 128 bit, while the 9800 is…

/me is searching for document…

#10

that’s what the latest link of Ifadolai says.
r350 is full 128 bits, while r300 is 96 bits.
yum…

#11

[quote]that’s what the latest link of Ifadolai says.
r350 is full 128 bits, while r300 is 96 bits.
yum…
[/quote]
No, I think not. It says he hopes it will. It was written before the release of 350.

350 is also 96 bits.

#12

well, after reading the sentence many times, i agree. My english skills entered the game again, and i lost. :slight_smile:

On an other hand, he could have written it better :stuck_out_tongue:
… err… okay… my fault… sorry. :-[

Anyway, if FX is the way to floating point pipeline, what can we expect from j3d’s mappings on this? Any official answer, or at least some guesses ?