Unanswerable question?
Blitz3D Forums/Blitz3D Programming/Unanswerable question?
| ||
| Here's a good one: If we can claim (quite rightly) that Blitz scenes/levels can be huge - square kilometres in size, what sort of accuracy could we claim for the placing/scaling of entites - less than a millimetre? Strange question I know, but someone asked me recently, and I couldn't think of an appropriate answer. All suggestions welcome. |
| ||
| Greetings Puppies, Whatever scale you use, I guess it'd be the floating point accuracy of blitz? Peace, Jes |
| ||
| I think floating point is accurate as long as you don't have lots of significant figures. eg. 0.0000000000000001 is accurate, but 0.57283847562637473 isn't because you have to store lots of figures. This is because floats are stored as a value and how many decimal places it is left/right of the decimal point. As such, 1000.00 metres and 0.001 metres can be represented perfectly accurately. When you hear of accuracy problems with flaoting point, it's because you can only store so many significant figures. eg. If a division x/a results in the real answer 547.348571834568134581734581733854791356481 internally this would be rounded to maybe 547.34857183456813452. The actual accuracy is 2^32. Lots of roundings results in float inaccuracies. But storing figures is likely to be accurate for the users anyone would want in setting a scene. |
| ||
| So, Shift Geezer, I guess that explains why when I use CameraZoom to look far away I see some strange effects. I guess that if I use a scale of 1 metre to 1 Blitz unit, I'd have to calculate from my current position to 'X' metres in order to say that the software is accurate to less than a centimetre. But as I moved towrds to the object being viewed the accuracy would naturally become more and more accurate. So what is the total number of digits involved in a floating point number? |
| ||
| Floating point accuracy is 24-bit, which is about seven digits. So the smallest change you can make to a number is roughly a ten millionth of that number. You could change 10000 by .001, or change 100000000 by 10. |
| ||
| in theory in z-resolution is 32 Bit, but practically I would use 0.001 to 32000. This would be 1mm to 32 km. THis is still a resolution of only 15 Bit and should work with the 16 Bit Mode too (WBuffer off) |
| ||
| So that equates to 1 millimetre over 10 kilometres. But I'm seeing 'floating point effects' (surfaces intersecting) when I CameraZoom out to 1 kilometre (unreasonable I know to expect such great accuracy, not moaning - just wondering why). I suppose that for any 'local' area where you are standing things are going to be pretty accurate, but I guess overall I'm wondering how far you would have to move from Blitz's 0,0,0 centre location before you'd start seeing that that object (or vertices) that you placed exactly at 'x,y,z' had started to drift. |
| ||
| Probably this depends on the hardware too. Although they all promise to use a 32 Bit resoltion, it seems to me they use a kind of LOD OPtimation in the Z-Order. Well, I am not a specialist. Anyway, when I play Deus Ex (that is based on the unreal engine AFAIK), I oftenly see sawtheets inaccuracies with things like Wallpapers that are posisioned close to a wall (multiple diagonal transparent stripes, typical rounding inaccuracy), although I play it in 32 Bit Mode. Maybe setting the quality settings in the graphics card tool to maximum would solve this problem. |
| ||
| Actually, I feel that the question is more general than that (we're all used to edge problems). I'm being asked 'how accurate is the 3D engine' by technical people, and I'd love to be able to say 'Accurate to less than a millimetre', or some such. But I guess that the truth is 'accurate to <something> over <something else> distance'. |
| ||
| Blitz has no World Relation setting, so it's up to you to define a range. if it's a millimeter up to 32km or if it's one meter up to 32 thousand km, it doesn't matter. I't a virtual relation. |
| ||
| Z-ordering is most accurate close-up and least accurate far away. I've heard something about w-buffering. I don't know if that would help... |
| ||
| I believe it was in Dungeon Siege 2 they choose to "move" the world around the camera instead of moving the camera around the world. That way they never had any problems with floating point precision. They divided the world into smaller subzones. though the problems with this approach was the transition between the subzones but it allowed for "infinite" sized worlds. I think there is an article somewhere there Chris Taylor describes this in detail. |
| ||
| The units are arbitrary, but the scale is relevant, due to the floating points as noted above. Also, the renderer may show z-buffer faults at extreme scales, depending also on Camera ranges. |
| ||
| This is an unanswerable question; What are floats ni b3d 32 bit. Why? is it unanswerable? I bet you can "answer" it, but theres likely something you missed. |
| ||
| Lets' try another angle, Cygnus: If as Floyd says, floating points are 7 digits (including the dec point?), then you can have 1000.01 and 1000.02, but 1000.021 will be equivalemt to 1000.02, since the last digit is dropped. So approximate accuracy is 10000.1->9, 1000.01->9, 100.001->9, 10.0001->9 etc (this is a question, not a statement). I certainly wouldn't mind comments from Blitz Support at this point..... |
| ||
| If it's 7-digit accuracy, wouldn't that be more like 100000.1->9, 10000.01->9 etc? This seems to make sense to me. The closer you place an object to global coords (0,0,0), the more digits of accuracy you have at your disposal. An object at (10,0,0) has 5 digits (after the decimal point) accuracy available when placing/moving it on the X axis, whereas an object at (10000,0,0) only has 2 digits. Therefore, the smallest amount the object at (10000,0,0) can be moved on the X axis is .01 - a not insignificant amount when placing/moving objects. I'm not stating this as fact - just thinking out loud. :) Does this sound about right to everyone else, though? |
| ||
| I don't have the Blitz manuals on this machine, and the online versions do not seem to discuss internal representation of numbers, but... There are three issues here: (1) how the compiler converts commands and variables into code to run on the cpu (i.e. machine code) (2) how the actual Arithmetic Logic Unit processes the values and stores them in RAM (3) how Blitz commands to display the stored value will report back Most floating point representations can be likened to 'scientific notation' or 'exponential form' where a value like 2.3 x 10^3 is equivalent to 2300 and 2.3 x 10^-1 is equivalent to 0.23 The float will be made up of a number of bits.... let's say 16 bits for illustration purposes. The compiler could then be forced to treat these as an 8 bit mantissa (the value part) and an 8 bit exponent (the size part). In this case we can have 256 different 'values' and a range of 256 'sizes'. Having to have a 'sign bit' for each of these would reduce it to 127 values and powers in the range -64 to +64. ...Of course this is just one setup. Depending on 'typical' values required we might go with a 12 bit mantissa and a 4 bit exponent. (Again allowing for sign bits) this would allow a range of 2048 values and powers in the range -4 to +4. In reality I assume Blitz floats are 32 bit numbers, with a fairly decent resolving power (i.e. range of values) and scope (i.e. range of powers). However... the functions that convert a value to something that the text commands can handle will truncate or round off the real, internal value. So arguements about 'digit accuracy' really only apply to attempts to display the value - they are related to, but not exactly the same as arguements about the representation of the value. Of course 'displaying' applies as much to positioning routines as textouts, so any advice about avoiding problems with floating point innacuracies due to scale differences should be taken into consideration. Just thought I would post this to save someone getting hung up on exact definitions of Blitz ranges based on what gets reported on screen ! |
| ||
| Wasn't there a previous post somewhere about Blitz units? |
| ||
| I'd be damned surprised if floats were only 16 bit. Windows is a 32 bit OS like most others these days and CPUs work in 32 bit. 16 bits Floats would be a waste. Just googled this... [urlhttp://www.funducode.com/freec/Datatypes/datatypes1.htm[/url] We should get a 23 bit mantissa and 8 bit exponent, giving 7 significant figures in the manitissa up to a max value of 8388608. As such all floats will be rounded to 7 (6?)significant figures, and accuracy is at most 1 millionth your largest value. Therefore a millimetre would be accurate in a kilometre, but movements of fractions of a milimetre of an object a kilometre in size will suffer rounding errors. |
| ||
| big10p: "An object at (10,0,0) has 5 digits (after the decimal point) accuracy available when placing/moving it on the X axis, whereas an object at (10000,0,0) only has 2 digits. Therefore, the smallest amount the object at (10000,0,0) can be moved on the X axis is .01 - a not insignificant amount when placing/moving objects. " Shifty Geezer: "Therefore a millimetre would be accurate in a kilometre" - I think you guys have hit it on the head. As I said, this is not about (in practical terms) what Blitz can or cannot do, but more about desribing to non-technical people the accuracy of any 3D engine written in Blitz. And I think "one millimetre accuracy over a kilometre" would pretty much describe it. - I'd be impressed anyway! Thanks for all your thoughts. |
   |