Look, doubles will make NO differnce because PC 3D hardware doesn’t use doubles. It’s nothing like the argument over filenames, it’s a simple engineering observation. If you want to get more precision you have to implement a scheme as I’ve described. The pressures driving floats vs doubles in hardware are the massive additional gates on chip that double precision would require at the equivalent speed. What would you rather have more geometry or double precision? More texture units or double precision? 8.3 filenames don’t severely hamper the functionality or performance of a filesystem, the analogy being drawn is spurious. Even if you want double precision in hardware, it’s an issue to take up with NVIDIA and ATI, not to argue over with application developers, because there IS NO CHOICE, hardware is single precision. Existing high end hardware from SGI is single precision, suggesting that waiting for it on PC’s where die size and yield is king and other features are seen as important is folly. Moreover, double precision values take more bus bandwidth to send to graphics, this is CRITICAL, because that is the key bottleneck for 3D geometry acceleration today. Even if graphics cards DID have double precision floating point hardware, an application which used floats with origin offset would spank the double precision application because geometry being sent to the card would use half the bus bandwidth with floats vs doubles, even if 3D hardware was the same speed for doubles vs floats (which may not be the case).
I’m advocating using doubles where it’s appropriate, but explaining how to retain that precision when your hardware has single precision fp hardware. It’s been common practice in 3D programming for decades. When your PC has double precision you can do something else (or stick with the faster scheme I’ve presented), until then your use of double precision variables will not solve the precision problems on your PC, it will have no effect.
Wow. That really made my day. Nothing like a good “the earth is flat” to cheer you up.
FYI: The speed of almost any modern application is directly varying with the size of its working set (because of caching, TLB trashing, and other such memory footprint related issues).
dorbie, there’s more than one way to use doubles. It depends on where in the process you use them, so I won’t rule them out, since I don’t know where Rockfort needs them. If the loss of precision is in multiplying matrices, it’s possible to do that “by hand” using doubles instead of with OpenGL, and only then load into OpenGL. Quite easy.
As for hardware using doubles, I don’t think it’s too far fetched, at least in the professional world, where fill rate is not king. You might argue that having more than 8 bits per colour channel is just as wasteful, yet high end pro hardware does it.
On your first part, you clearly haven’t read my earliest post. I explained exactly what you are talking about. I agree there are several ways of going about this, but they ammount to the equivalent operation, model - view cancellation. My objection is using doubles for everything, not only is it expensive wasting memory and bandwidth, it just won’t work on real hardware. This is critical, “IT WON’T WORK!”, like I said take it up with IHVs first.
On your second part, 8 bits per component is a separate issue. There is even a case for floating point pixels which I strongly agree with. The fact that hardware works towards solving one and not the other hardly makes a case for double precision geometry. There are exceptions but I’m not going to point them out for you.
Let’s ditch the nonsense of reasoning by analogy. Stick to the merits of the case that way we don’t have to waste time discovering why situation A does not equal situation B. It’s a sure sign of a weak case and we’ve seen it from you twice already. Debate on the merits of DP geometry, not unrelated issues like pixel component precision or 8.3 filenames.
The original question was also about games, not pro apps, but I don’t concede that pro apps need more precision for the reasons I’ve already explained. Even pro apps should strive for best performance.
[This message has been edited by dorbie (edited 11-11-2001).]
Well, for the game i’m working on i use Floats for all my 3D objects management (matrices,vectors,quats etc)
And finally, i’ve minimised my vertex structure to the min using CHAR &| SHORT values for normals,texture coordinates and
so on & so forth…
Quite necessary when u need to store a large amount of vertice onboard.