Hi Lindens & Moles: What is the actual conversion measurement of a SL meter to RL feet/inches?

[Pixels Sideways]

Hi Lindens and Moles:

Could you please define this so everyone knows the correct information:

What is the actual conversion rate of a SL meter to RL feet/inches and vice versa?

I have looked for this info but have never found the specific and accurate definitive answer - just guesstimates.

Having these conversion rates officially defined by LL will be helpful in scaling buildings, avatars, etc.

Maybe you could create an official LL/SL scaling grid texture to put on various meter sizes of prims (1, 3, 5, 10, 20, 30, 40, 50, 64) which would be tres cool tool and immensely helpful particularly for peeps who choose to build or size their avatars to to RL scale.  Make it available inworld and on MP and perhaps place them in the inventory LIBRARY in a viewer update.

Thank you!

xo

 

Edited August 5, 2020 by Pixels Sideways
oops

[Ardy Lay]

The metre, symbol m, is the SI unit of length. It is defined by taking the fixed numerical value of the speed of light in vacuum c to be 299792458 when expressed in the unit m⋅s−1, where the second is defined in terms of the caesium frequency ΔνCs.

The yard has since 1959 officially been defined as exactly 0.9144 metre.

[animats]

1 inch = 0.0254 meter. Exactly.

Introduction to the Metric System.

[Mollymews]

am not sure what you are meaning Pixel

a typical standard RL box house, floor to ceiling is 2400mm and door openings are 2000mm high by 750mm wide.

when we subjectively say that average avatar is 1800mm tall by prim measure. (1800mm is approx. 1.64 metres by the Linden Viewer shape editor) then the avatar-to-build scale is 1:1

the default Linden viewer camera position can cause issues with a 2400mm ceiling height, but we can lower our camera position and save as a Camera Preset

[Odaks]

I cannot find anything to indicate the LL has attempted to re-define the internationally accepted conversion from metres to yards, feet and inches, viz:-

1 metre = 39.37" = 3.28' = 1.09yd. (to 2 decimal places).

As @Mollymews points out, above, there are inconsistencies with scale in SL, and these can knock on through a number of different areas e.g. animations, sit positions, vehicle sizes, furniture sizes etc.). Be aware that making your avatar "realistically sized" can make it look rather small because of buildings having over-size doorways and ceilings (which is why most avatars are not realistically sized!). 

I've never found an official scale that applies in general, either. All we seem to have is that the prim dimensions, as built in SL, have to be approximately the same as the RL item being represented.

 

ETA: You were looking for a scale or grid. A scale ruler will appear when you resize a prim using the build tools. This ruler measures in metres, and can be taken to mean RL size. You can use a resized prim to measure other objects, e.g. avatar height.

Also, there are a number of grids available on the Marketplace:

https://marketplace.secondlife.com/products/search?utf8=✓&search[category_id]=&search[maturity_level]=GMA&search[keywords]=builder's+grid

 

Edited August 6, 2020 by Odaks

[Jackson Redstar]

remember the movie Avatar? the Na'vi was a race of beings 10ft (3m) tall. Everything in their world therefore was appropriately scaled and was completely normal. A human visiting would find them and objects huge, and a Na'vi visiting earth would find humans and objects very small, but in their  own home worlds the scale of  everything would be 'normal'. Sl is no different. Its all about the proper scale

[Extrude Ragu]

1 meter in SL is 1 meter in RL.

When you start paying attention to detail using references and measurements, you'll quickly realize that lots of creations where people have just eyeballed it are way out of scale, that's because the SL camera is placed unusually high

[Nova Convair]

LL should never have used meters but bananas instead. 😎 Would have stopped useless RL/SL compares. "Hey I'm 47 bananas tall" "???" questions?

It's a virtual world and you have nothing to compare. No measurable light speed and no physics experiments. If you put 256 1m cubes in a row it reaches exactly from one to the other side of a sim and LL said that a sim has 256x256m. But they could lie 😁 - soooo you still have no proof.

If someone builds a house and furniture in original size - they will find out that is doesn't work. (or ask everybody to shrink instead 😜 ) Go to a chair that stands next to a table and sit down and stand up. Works in RL - great job. Now do it in SL - oh you don't fit between table and chair? And somehow you teleported on that chair? And get catapulted into the ceiling when you get up? Or alternatively stand in the middle of a phantom table and chair?
And you get 2.5 m visitors that would never fit through your RL door or on your RL furniture?

So all that numbers are irrelevant - relations are relevant - things need to fit and to work. The result has not much in common with RL - just the looks are similar.

[animats]

6 hours ago, Nova Convair said:

LL should never have used meters but bananas instead.

That causes huge problems for creators. Early animation systems used their own arbitrary units. Blender had "Blender units". Softimage had "Softimage units". What they meant was up to the creator. That made it hard to pull together assets from different sources. Today, everybody has explicit units, usually metric. You use Blender set to metric (1 meter) mode. If you get a model from a 3D asset site outside SL, bring it into Blender, work on it there to prep it for SL, and then upload it to SL, it should be the right size.

6 hours ago, Nova Convair said:

no physics experiments.

SL has gravity, and it has an acceleration of 1G. Get a bow and arrow from Marketplace and try shooting. Watch the arc the arrows take. That's a 1G arc.

SL even has mass. Although avatars are the weight of their bounding volume filled with water, about 200Kg.

Size matters.

[Ardy Lay]

I think all the confusion was caused by competition.  Maybe it is like the “Compact Disc Loudness War”.  The standard units were clearly defined at the inception but users and subsequently creators IGNORED the option to do it reasonably and got into a competition over loudness/height due to the gross perception that louder/taller was better.  The fact that the Second Life viewpoint was way up and behind the avatar is a rather weak excuse for making avatars stupidly tall just as the average portable CD player being equipped with crap headphones and used in a suboptimal ambient environment is a lame excuse for compressing the dynamic range of recorded music and jamming it to the loud end of the dynamic range of the CD.

[Odaks]

@Nova Convair tells the unfortunate truth about SL scale. If a "tall" avatar looks correct against the world it is in, it is not tall, and certainly not stupidly tall.

It might only be regarded as too tall if you are blinkered enough to use only the height indication given by your viewer (and different viewers might measure avatar height differently from other viewers, so can't be relied upon anyway). Its the surrounding world that your avatar has to suit, not some dubious height scale number in your viewer. Animation and pose creators have a difficult enough time making stuff that suits the "standard sized" avatar (based on the S, M, L sizes agreed amongst clothing creators many years ago?) without people deciding that they know better. But hey, its your world, your imagination.

What I do find interesting though is that the newer "stock" avatars offered by LL appear to be noticeably shorter than the original ones. Is something afoot here?

[animats]

7 hours ago, Odaks said:

What I do find interesting though is that the newer "stock" avatars offered by LL appear to be noticeably shorter than the original ones. Is something afoot here?

Yes. As avatars became more realistic, people became fed up with giant avatars. They looked wrong. Doorways returned to reasonable sizes. So did furniture and vehicles.

[Odaks]

15 minutes ago, animats said:

Doorways returned to reasonable sizes. So did furniture and vehicles.

So SL is being re-scaled across the board to suit? All furniture makers, vehicle makers, animation makers, pose makers....etc have been given new guidelines for building? I suspect not, and a great deal of mismatching will result? The new black is grey! I just hope everyone knows!

Oh, and the camera default fixed?

 

Edited August 8, 2020 by Odaks
Afterthought

[Mollymews]

On 8/8/2020 at 7:01 AM, animats said:

Today, everybody has explicit units, usually metric. You use Blender set to metric (1 meter) mode. If you get a model from a 3D asset site outside SL, bring it into Blender, work on it there to prep it for SL, and then upload it to SL, it should be the right size

i agree. A metre is a metre, as it should be in any/every 2D or 3D modelling and display tool/environment

that we can change the scale and resolution of our screen and/or printer (or hand drawn on paper) doesn't and shouldn't break the meter is a meter rule

[Nalates Urriah]

Lots of opinion and speculation here...

The simple fact is all digital computer models use mathematical descriptions of the things within the model. If I alone am working in the model it is I alone that needs to be consistent with my self.

Anyone can decide the units in their system are whatever they want. Blender, AutoCad products, Draftsight, and other modeling programs will allow you to designate the software's UNITS as what ever you want. People regularly change those units. Someone wants to represent the galaxy, another the solar system, another a country map, another a house, another is designing an engine or a smart phone... or modeling a virus or protein string.

Because modeling software is designed to be fast the mathematical representation is usually integer based. Only when people start adding dimensions does floating point math get involved. If that seems odd read some Wikipedia.

It is when we start to work and cooperate with others we have to decide how we will think about the units we use. The Lindens at some point decided a unit in SL would be a meter. But the math is such that at 4000.0000m is the limit (4098 = 1 0000 0000 0000 b) where precision breaks down. It is a matter of how the SL integers are translated to floating point values. A distance of 200.003m is a floating point number. But the render engine sees it as the integer 200,003. This should explain why using s dimension of 5.0014 gets rounded off oddly.

So, the base unit in SL while labeled a meter the actual unit is much smaller, like a millimetre. 

Confused yet? The point is the units in any modeling program are purely arbitrary. SL has a standard because of the demands and limits of 2003 software and computers and a need for people to be able to work together.

 

[Extrude Ragu]

On 8/7/2020 at 1:31 PM, Nova Convair said:

If someone builds a house and furniture in original size - they will find out that is doesn't work.

 

On 8/7/2020 at 1:31 PM, Nova Convair said:

And you get 2.5 m visitors that would never fit through your RL door or on your RL furniture?

I've owned a private sim for about 4 years and it's a good social study on this, being an environment where most things are made by me and my mesh is for the most part based on an RL reference/measurements as that helps ensure that all buildings/furniture/assets etc feel the right size together.

In my experience, very tall guests who come and stay at my sim for a while generally adjust their avatars size within a couple of days. I'd guess it's because the environment 'makes them feel' tall and the natural desire to fit in amongst other avatars who are more reasonably sized.

You do need to zoom in on the default viewer, in Firestorm is less of an issue because people can ctrl+scroll/ctrl+shift+scroll to adjust camera height and pitch.

On 8/7/2020 at 1:31 PM, Nova Convair said:

LL should never have used meters but bananas instead. 😎 Would have stopped useless RL/SL compares. "Hey I'm 47 bananas tall" "???" questions?

At the end of the day, any 3D creator worth their salt uses references and some form of scale to ensure that their creations all 'feel right' together, as otherwise you end up with scale uncanny valley. Sure, you could use bananas, but all that means is that one artist is going to decide a banana is a meter to inform their creations, another a foot, and some smartass is going to look up the US Department of Agriculture (USDA) standard banana sizes, and decide that the true unit is actually 6.75 inches (0.17 meters) based on the length of the average 'medium' banana 🍌

If every creator is working to a different scale, there is no interoperability of 3d models between environments, which would mean that sim owners wouldn't buy no-mod objects from each other because their sims are all to different scales, likewise people would need to create a new shape for every sim they visit.

Having a standard unit and working by it has value. The question then becomes, who should set the standard unit?  The people who designed the game and chose 'meter' as the unit, or random people who don't work to any real unit at all and are just reacting to their environment?

 

Edited August 12, 2020 by Extrude Ragu

[Wulfie Reanimator]

6 hours ago, Nalates Urriah said:

It is when we start to work and cooperate with others we have to decide how we will think about the units we use. The Lindens at some point decided a unit in SL would be a meter. But the math is such that at 4000.0000m is the limit (4098 = 1 0000 0000 0000 b) where precision breaks down. It is a matter of how the SL integers are translated to floating point values. A distance of 200.003m is a floating point number. But the render engine sees it as the integer 200,003. This should explain why using s dimension of 5.0014 gets rounded off oddly.

So, the base unit in SL while labeled a meter the actual unit is much smaller, like a millimetre. 

I'm very confused by this. What does "4098 = 1 0000 0000 0000 b" mean and how does it relate to "4000.0000"? Do you have any kind of source for the "200.003 is actually 2000003" claim? What do you mean by "5.0014 gets rounded off oddly?"

6 hours ago, Nalates Urriah said:

Because modeling software is designed to be fast the mathematical representation is usually integer based.[citation needed] Only when people start adding dimensions does floating point math get involved.[citation needed] If that seems odd read some Wikipedia.

Could you link any relevant pages...? Integer math is certainly faster than floating-point math -- and it was used back when CPUs were slow -- but the difference is absolutely negligible on anything you could possibly expect to connect to SL with today. To do everything with integers would surely be more of a headache than regular floating-point math. I would even call it unfeasible.

Edited August 12, 2020 by Wulfie Reanimator

[Nalates Urriah]

Most real-time render engines still work with integer math. They have hundreds of billions of operations to perform. Even small performance gains multiplied by billions becomes significant.

Floating point numbers in computers are used for those things which require them. Even our desktops have dedicated floating point processors in the CPU. Video cards are made for other purposes than just graphics display, think bitcoin mining. While numerous biology, physics, and chemistry problems need a floating point base, 3D rendering doesn't.

Integer math measured in MIPS is very difficult to compare to Flops. Deciding which way to go in scientific circles usually depends on the size of the number and the precision needed. Will 8 bit numbers get by? 16? 32? 64? 128? The more bits required the slower the computation. So on modern desktops with dedicated video cards it may be possible to get acceptable performance for an app like SL using either. The apps needing larger numbers tend to use CUDA processing in GPUs where there are hundreds of not thousands of GPUs in the card.

The actual limitation for SL is the size in bits of the numbers that give just sufficient precision and the best speed. In LSL 32 bit signed integers are used. I would have to dig into the render engine to see what is actually used there. I suspect 32-bit unsigned integers were used.

The render math was decided on in 2003-4. Now it is too big a task to make a change. A change would sort of be like changing the foundation of a high-rise building so you could add more stories. So much stuff has to change it is easier to tear the building down and build a new one. Which is why the Lab decided to build Sansar rather than remodel SL for VR. Now it looks like the hardware may get fast enough that SL could possibly run in VR. But a lot has to improve get to a minimum of 90FPS.

I should have written 4095 decimal = 1111 1111 1111 binary. 

Stopping to do a bit of research I find http://wiki.secondlife.com/wiki/LLSD#integer But, it does not talk about the render engine.

 

Edited August 13, 2020 by Nalates Urriah

[Mollymews]

2 hours ago, Nalates Urriah said:

Floating point numbers in computers are used for those things which require them

for most things rendering the linden viewer uses 32-bit floats as this is what the OpenGL API takes as function arguments

[Wulfie Reanimator]

7 hours ago, Nalates Urriah said:

Most real-time render engines still work with integer math.

I have absolutely no idea where you could possibly get this idea. What background do you have to talk with such of confidence?

To me it seems obvious you have no idea how floating point numbers (or rendering 101) works, and how 32-bit ints could never work for rendering in SL in the way that it does. The fact that you didn't include any sources only strengthens my opinion.

7 hours ago, Nalates Urriah said:

Even our desktops have dedicated floating point processors in the CPU. Video cards are made for other purposes than just graphics display, think bitcoin mining.

What is the point you're trying to make? CPUs can do float math, therefore the GPU isn't used because it can do other things? Mind-blowing. Software renderers (AKA, ones that run on the CPU) are incredibly slow (which is the only thing where you're correct) and that's exactly why we have graphics cards and why all modern graphics APIs use the... graphics card.

7 hours ago, Nalates Urriah said:

The actual limitation for SL is the size in bits of the numbers that give just sufficient precision and the best speed. In LSL 32 bit signed integers are used.

LSL also has floats. Vectors are 3 floats, rotations are 4 floats. All of the functions that deal with positions and rotations return the correct float values, with higher precision than "an decimal converted to a float" could give.

7 hours ago, Nalates Urriah said:

The render math was decided on in 2003-4. Now it is too big a task to make a change.

Back in 2000, computers were already fast enough to be using floats and GPUs for games. No sane individual would build a market product like SL with a CPU-based integer renderer. (Never mind that what you're describing is basically "fixed-point" which is slower than floating-point math.)

4096 isn't even a hard limit in SL. Avatars and objects can go higher, a lot higher, and not suffer from doing so until they start reaching heights where 32-bit floats really start breaking down (10-50k meters, try it and see what I mean.)

Edited August 13, 2020 by Wulfie Reanimator

[Nalates Urriah]

We disagree. But, at best the real answer is more complicated then we are saying.

This article from 2003 gives an overview of the thinking then. Notice the section on Floating points. https://www.flipcode.com/archives/3D_Graphics_on_Mobile_Devices-Part_2_Fixed_Point_Math.shtml - Yes they are talking about mobile. But Googling for more information it should become obvious that most games of the era are using fixed point math, which is integer math over floating point (ref 2010+/-). That is what I was playing with in high school when I was hacking around in the Myst Online game and formed my idea games use integers as they are faster.

Molly makes the best argument in defense of your position by referring to the OpenGL calls.

It is at 4096m +/- altitude that the precision of SL math most definitely and obviously breaks down creating visible problems. Above 3000m people see some problems. Those designers that have not put effort into keeping the vertices of their models limited to near integer values find seams opening in their model. It is a common problem in SL. We can go above 4096 but the precision of models falls apart and we can see problems in most models. This is common in fixed point math models, which is why I thought SL ws using integer math in the render engine. But, that was supposition on my part.

I did start looking at the Linden Viewer code to see if I could quickly find an answer. Then I realized from Molly's comment that the working part of the engine is OpenGL. That is another load of code to look through. Fortunately there are discussions of how to best use OpenGL that show up in searches. This is where I find the articles explaining how the engine converts 3D world values (floats) to 2D screen coordinates and how the floating point values passed into OpenGL get converted.

Then I wondered about my thinking that integer is faster than floating point. A bit of research on that reveals that in GPU territory 32-bit integers and floats will process at the same speed. With that in mind, a quick look at OpenGL shows a mix of floats and integers in the processing. But the direction is ALWAYS toward integer math to render to the screen. Well... duh! The screen, any screen, is pixels and the location of all pixels is represented by integers. I should have remembered that point and started there.

So while the SL side of things can be all floats as they pass through OpenGL to screen for display they have to convert to integers. That will true of the newer Vulkan too.

So, while I was thinking SL Viewer code would use integer math for rendering, I was wrong. They don't have to. In fact the Linden code could be said not to do the render but passes it off to OpenGL. They use a a mix of types in the viewer depending on what they are doing or is being represented. OpenGL does the same but with the twist that they eventually have to get to integers to put the result on the screen. So, most... no... ALL render engines use integer math. How much they depend on it or make use of it is debatable.

Reread your post. Do you notice that you begin attacking me rather than providing a critique (sources) based on facts and references?

 

Edited August 13, 2020 by Nalates Urriah
name misspelled

[Wulfie Reanimator]

1 hour ago, Nalates Urriah said:

Reread your post. Do you notice that you begin attacking me rather than providing a critique (sources) based on facts and references?

It's incredibly frustrating for me as a teacher to read so much misinformation in so little content. I may sound harsh, but that's because you're so brazen for how uninformed you are on this. How quickly you were able to find the (correct) abstract information about how games are rendered these days demonstrates that.

In the early 2000s we had games like Unreal Tournament (1999) and Deus Ex (2000) which ran on Direct3D 10. Even D3D 9 (released in 1995) used floating-point math. We even had very high quality games on Valve's Source Engine like Half-Life 1 (1998), later Half-Life 2 and Counter-Strike: Source (both 2004) which absolutely made use of floats. Valve's games from that time are literally revolutionary in many ways, including accurate physics.

1 hour ago, Nalates Urriah said:

they eventually have to get to integers to put the result on the screen. So, most... no... ALL render engines use integer math.

I can't even come up with an analogy that could express how incredible this statement is, and how far removed it is from your original claim.

The amount of theory we would have to go through to explain to you how rendering a 3D world into a 2D screen is done is far too much information to put here. So instead, I leave you with this and you can read through it at your own pace: https://www.scratchapixel.com/

Edited August 13, 2020 by Wulfie Reanimator

[Nalates Urriah]

Well... the fact is all display devices are pixel based and that requires integer math.

You are good at voicing your opinion but no facts. You just criticize me and attempt to be insulting.

At least I corrected the mistakes I had in my opinion.

[Wulfie Reanimator]

2 hours ago, Nalates Urriah said:

Well... the fact is all display devices are pixel based and that requires integer math.

You are good at voicing your opinion but no facts. You just criticize me and attempt to be insulting.

At least I corrected the mistakes I had in my opinion.

I never said that you don't use integer math at all when it comes to rendering... I would be surprised if you could do anything practical without integers.

Go re-read your first and second post in this thread. Your original claim implied that "everything is done with integers, position is measured with fixed-point math and not floats unless you're doing scientific stuff or add more dimensions." That was the context I was responding to.

"You need integers to put pixels on the screen" is a world of difference and of course I would've never disagreed in the first place if that was your claim, but it wasn't. I'm very open to new ideas and love being corrected, but considering my practical knowledge on the subject, there was no way what you were originally saying was as true as you were presenting it as.

But even the way you worded your conclusion, like "actually I was right after all, ha" is upsetting on its own. It's like insisting "water boils at room temperature," and when called out, you clarify with "I looked it up and if the room was a vacuum, the water would boil."

Edited August 13, 2020 by Wulfie Reanimator

[Ardy Lay]

Blep!