what scale? metric or other

Started by
15 comments, last by JohnnyCode 10 years ago

1) as usually one defines the camera near-plane distance as 1 engine unit.
2) In case you are thinking "why not make the near-plane distance less than 1.0," there is a considerable loss of precision with smaller values: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

1) One does?
2) If you multiply the near value by some scale, then you're also multiplying the far value and all your z values by the same scale for zero net change.

From your link - the precision between a 1cm near plane using cm-scale (1u=1cm) or m-scale (1u=1m) is exactly the same:


zNear = 1 (1cm)
zFar = 100000 (1km)
Z distance = 500 (5m)
Resolution of Z Buffer at this range 0.014900568115137958 (1.5mm)
 
zNear = 0.01 (1cm)
zFar = 1000 (1km)
Z distance = 5 (5m)
Resolution of Z Buffer at this range 0.000149005681151948 (1.5mm)
Advertisement
One clarification: Setting 1=1cm is perfectly "metric".

From the Wikipedia page on Metric System:

The centimetre gram second system of units (CGS) was the first coherent metric system, having been developed in the 1860s and promoted by Maxwell and Thomson. [...]


You seem to be confusing the metric system with the International System of Units.

streaming world system need to know what range of units they'll be working with -- the floating point accuracy of positions that are 10km from the origin differs wildly depending on whether you're using cm, m, km, etc... Whether or not they need to use hierarchical or 64-bit coordinate systems may depend on the choice of units!

I do not know exactly what is the source of this accurracy

errors.. doesnt just using doubles instead of floats not resolves

them? Float indeed with 23 bit precission (8M) with 1 cm resolution should fire up over the range of 80 km (?)

(when using 1.0 as base 1 cm it could mean that indead i could use milimeters of precission too sometimes maybe so it could be

8 km world)

but double is 29 bit more (512M) so even 8 km * 512 M = 4 * k *k * k *k meters, it is compared to earth-sun distance which is 0.15 kkkk meters

That should be enough to very large scenes

can some numeric errors appear on doubles?

We call them “game units” because they are arbitrary. 1 inside the game means “whatever the artists making assets for the game decided it should be.”

Before a project the artists gather around and the lead artist says, “Look, newbies, I’m the LEAD artist. I OWN YOU AND YOU WILL… [insert long lecture about his or her greatness] …AND SO IN THIS GAME 1 = 1 METER IS THAT UNDERSTOOD MAGGOTS? I CAN’T HEAR YOU.”

i hesitate beetween metric and centimetric (the other one when
you just call 1.0 as an 1u (unit, where there i was no stating correspondence between this unit and real world at all) i consider now bad one i was using it before but i was getting lost in it)

It’s not your choice what 1 is. It’s up to the egomaniac lead artist for each game by each team.
Leave it alone and drop the issue. It’s none of your business, and it doesn’t even make sense that your API would itself define the length of 1. What are you planning to do with that “knowledge”? Limit the viewing distance? The only thing that you could possibly accomplish by assuming the length of 1 unit is to add flaws to whatever you are making.


L. Spiro

Im doing home projects so i choice and control everything on my own

I think choice of scale can have some psychological properties and thus is (ot at least can be) some kind of meaningfull

(same as choicing argument names in DrawLine(int px, int py, int qx, int qy) ;/ this is maybe mosty aesthetic but it can be important too and i like to consider things in details - you seem to suggest that it is good to out of aesthetic choices and go to raw working plane? this is some option to [but now i got enough time and coul try to get a carefull (hopefully good, though good here is not so easy definable) choices])

1) as usually one defines the camera near-plane distance as 1 engine unit.

1) One does?


Yeah, I'm going to question that as well. On OFP the camera's near clip was set to 0.03 (or 3cm), although the far was only set to 333.33 meters out to maintain the precision we were after. (For the 'near' pass; far pass started at 333.33 and went out much further).

(This was also a game with crazy requirements where 1km = 1024 pixels on a texture because artists; this gave us some interesting conversation numbers in the engine. Physics was largely unaffected however as they ran a different tile size and update rate to the rest of the world. As I recall they shifted 'world centre' every 512m where as the renderer worked in 1km wide tiles.)


Yeah, I'm going to question that as well. On OFP the camera's near clip was set to 0.03 (or 3cm), although the far was only set to 333.33 meters out to maintain the precision we were after. (For the 'near' pass; far pass started at 333.33 and went out much further).

(This was also a game with crazy requirements where 1km = 1024 pixels on a texture because artists; this gave us some interesting conversation numbers in the engine. Physics was largely unaffected however as they ran a different tile size and update rate to the rest of the world. As I recall they shifted 'world centre' every 512m where as the renderer worked in 1km wide tiles.)

I got also terrible issues with planes flickering where card supportet only 24 bit depthtbuffer, Today i suspect 32 is absolute minimum probably,Can more be assumed?

23300 to meters (23.3) - so i really dont know, think that maybe metric can spare me a bit of headahe (?)

Since 23300cm is 233m, not 23.3m, yes. Using meters will save you a bit of headache, if you do that kind of conversion in your head. Fewer conversions means fewer occasions to get it wrong. By only ever using straight SI units (no multiples, and in particular no "weird units" like feet and pounds), you somewhat reduce the likelihood of pulling a Mars Climate Orbiter.

The nice thing about SI is that things make sense, and things are intrinsically "graspable". Interestingly, both the meter and the kilogram were born out of political intrigues rather than science and in quite dubious times and circumstances. And still, something very sane and practical came out of it.

The accounts of Delambre and Méchain, who by the way did their trip 70 years before... (who are Maxwell and Thomson?), well, the guys who did the trips to Barcelona and Dünkirchen through civil wars, the Spanish-French war, partisans and rebels, and arrests for espionage with strange instruments... are well-documented, and a quite fun story, much like a Three-Musketeer tale.

It's amusing in particular because Méchain was well-known for being the most accurate, pedantic, anal-fixated living person of his time, but after having nearly completed his work, he realized that he did the calculations for the base point wrong by a few hundred meters (well, not meters at that time). So he didn't dare returning home for nearly two years out of shame. Though the difference was well outside the technical capabilities of that time anyway, nobody would have been able to tell if the prototype meter had been 0.01mm too big, nor would they have been able to manufacture it that precisely.

On the other hand, as long as you are firmly confident with the units that you are handling, it doesn't matter even if you use kellicams. Usually, not you will be doing the conversions, but the computer. So as long as the conversion is correct once, there's no headache.

Setting 1.0 to a SI unit will not do any harm in the future, while anything else bares a risk of complications. Setting 1.0 to a centimeter, what is not a SI unit, but only its multiplications (0.01m), will for example brake Newton force unit or anything else dependant on SI (1N=kg/(m/(s*s))). You can ofcourse remultiply your application 1.0 calibration. A SI unit is by standards a second, kilogram, meter, volt and so on, and all units derive from them (force N,speed m/s, aceleration m/(s*s), and so on)

This topic is closed to new replies.

Advertisement