PDA

View Full Version : Why do models have to scaled X 3937 to be acurate size?



Carcegen
04-30-2010, 03:56 PM
Lightwave 9.6...

I am working on a small 4" handheld device that will be output to SLA printers and eventually manufactured with CNC machines. The problem is I've been going by the units that are on the grid to make the parts. I have now done two protoypes and have found that in order for my parts to be acurate in size, they must be upscaled x 3937! And then the STL's and any solid viewer reads the correct size. How did I come up with 3937? It happens to be the exact amount of inches in meters -- 39.37. Drop the decimel point and you get 3937.

Now you might say this is just conversion problems between LWO and STL files but if you actually upscale that part and ask Lightwave to do a bounding box around it comes out to the exact size the part should be. This is AFTER upscaling it x 3937.

Am I missing something or is there an inherent flaw in Lightwave's grid system?

Lightwolf
04-30-2010, 03:59 PM
Which unit system are you using in LW?

Cheers,
Mike

MicroMouse
04-30-2010, 10:25 PM
Even though you are working in inches, your model's dimensions are stored as meters in the LWO file.

Different programs assume different units of measurement for the STL file and the software for the CNC machine is assuming the units are inches.

Result is when you save from LWO to STL you have to scale from meters to inches.

Wayne

Carcegen
05-03-2010, 12:58 PM
I am using inches and I will switch to millimeters just to check. All seems fine - everything measures correctly until I ask it to make a bounding box around the object and it's extremely small. But when I went upscale it 3937, the boudning box reads the correct dimensions and this is BEFORE any converstion to STL. So when asked - Lightwave knows the correct dimensions - which are 3937 too small. Very strange.

shrox
05-03-2010, 01:01 PM
I came up with 3935. I have to scale up by 3935% to get DXF files to be the proper size in TurboCad. Units are irrelevent in this case.

Carcegen
05-03-2010, 01:12 PM
Try it yourself.. go into modeler, make a model about 4" big. Measure it with the tape measure to be sure. Then go to MEASURE and ask it to create a BOUNDING BOX around the object. This will give you exact dimensions. Notice the dimensions it returns on screen before hitting MAKE. These are NOT the correct dimensions you have been working at. In fact they are 3937 times smaller than they should be. This is really a huge problem in Lightwave when working on real world size objects. Why does the program KNOW it's wrong and yet does nothing to correct it?

Carcegen
05-03-2010, 01:14 PM
Units are not irrevelant. Inches in meters is exact 39.37007. So your 3935 is off by about 2 thousandths. To be exact - use 3937.

shrox
05-03-2010, 01:21 PM
Units are not irrevelant. Inches in meters is exact 39.37007. So your 3935 is off by about 2 thousandths. To be exact - use 3937.

My figure was guesswork. I meant the object is the same size whether measured in inches or millimeters. Which ever units I have on, it's still has to be scaled by "3937"%. I'll use your number from now on, our previous stuff using 3935 was for non-critical parts.

Hieron
05-03-2010, 04:44 PM
Or some countries finally adapt to the sensible SI system and stop working with measurings lengths that were cool and new during the crusades.
Baffles me it's still being used.

Sorry I can't be constructive with regards to LW. Always used m's and the rapid prototypers here use it as well. Never been an issue.

Lightwolf
05-03-2010, 04:54 PM
Units are not irrevelant.
Well, in LW they kind of are, the unit display does not change the size of the object, it just changes how to dimensions are displayed to the users. So there is no actual conversion of the point coordinates going on the behind the scene, their numeric positions stay the same regardless of the units used (which why the LW unit system is so elegant in the first place, as it allows for a complete mix and match).

Internally the numeric 1.0 is the equivalent to 1.0m.

STL doesn't have units though, so if any software reading the STL interprets 1.0 as being 1 inch, foot or whatever... then you need to scale.
However, in this case I'd actually blame the software importing the STL, because that should allow for conversions.

Cheers,
Mike

Hieron
05-03-2010, 06:27 PM
Totally agree on the above. Stuff like that becomes annoying when you get a Maya object that turns out to be 1km in size.

"just set your scale to cm's then, duh!"

ehm.. why is your object not defined in the first place? bleh

shrox
05-04-2010, 08:46 AM
I include a 1 inch square with the files I make. That is a sizing reference.

I would guess that if the errors from different formats are consistent, some one should be able to write a script or plugin that automatically sizes the model depending on format.

Elmar Moelzer
05-04-2010, 12:50 PM
What LightWolf said. The importing app is the one having the problem here.

Carcegen
05-12-2010, 07:17 PM
Problem exemplified: Make a 5" round globe. Look on the grid - it shows 5 inches. Take the tape measure from the DETAIL tab and it measures 5 inches across. So far so good. Now.. drum roll please... ask the measuement system to make a bounding box AROUND the object and tell me if you see 5" x 5".

No, here's what you see --

Minimum corner (-.064, -.064, -.064)
Maximum corner (.064, .064, .064)
Extent .127 X .127 X .127

Now if I take that same ball and size it up X 3937, here's what the same bounding box in LW reads:

Maximum corner (-2.500, -2.500, -2.500)
Maximum corner (2.500, 2.500, 2.500)
Extent 5.000 x 5.000 x 5.000

Why does the bounding box read correctly ONLY after the object is upsized 3937%?

Can someone there at Lightwave please explain.

Lightwolf
05-12-2010, 07:21 PM
Can someone there at Lightwave please explain.
Easy, the bounding box plugin doesn't display the values in a way that leverages LWs unit conversion, thus showing the internal values (which are based on 1.0 being 1m).
That's a bug/issue with the bounding box function.

Cheers,
Mike

MicroMouse
05-12-2010, 08:10 PM
5 inches x 2.54 centimeters per inch = 12.7 centimeters = 0.127 meters.

For the users convenience, LightWave lets the user work in inches. Behind the scenes LightWave converts your inches to meters which are stored in the LWO file.

If your object measures 5 inches along the X axis and it is centered on the origin the minimum X value will be -0.0635 meters and the maximum X value will be 0.0635 meters.

Wayne

shrox
05-12-2010, 08:16 PM
I have to scale a 1 inch square by 3937% for the exported DXF file to appear as a 1 inch square in TurboCad. Why the odd number?

Snosrap
05-12-2010, 09:10 PM
We 3D print real world scale decorative hardware for furniture from LW models everyday. We use Chrome Cow's STL import/exporters. No problems what so ever.

MicroMouse
05-12-2010, 09:17 PM
1 inch x 2.54 centimeters per inch = 2.54 centimeters = 0.0254 meters

0.0254 meters x 39.37 inches per meter = 1.0 inch

Generally CAD software uses a UNITLESS system of measurement that means 1.0 units is whatever the user wants it to be.

One unit could be a nanometer, inch, foot, millimeter, kilometer, parsec or whatever.

Wayne

Silkrooster
05-12-2010, 10:49 PM
If i go by what your saying then the actual size is not included in the file itself. Otherwise both programs would know 1" = 1" regardless of the unit use internally. Both programs are capable of doing the conversion, but it sounds like the units themselves are stored in the file which is giving the other program grief since it does not know what the unit is equal to in another program.

MicroMouse
05-12-2010, 11:47 PM
There is nothing written to the LWO file to indicate that one unit is one meter.

The actual size is written to the LWO file with no indication that the units are meters.

If the user enters 1 meter in LightWave, then 1.0 will be written to the LWO file.

If the user enters 1 inch in LightWave, then 0.0254 will be written to the LWO file which is the value another program will find when it reads the LWO file.

Conversion of measurements when switching between programs is a big headache.

Wayne

Carcegen
05-13-2010, 12:42 AM
So that when you are working in say inches, the object is truly the size it states? From what I'm hearing lightwave assumes that 1.0 is 1 meter. So to get one inch to read correctly I need the one inch converted to one meter - hence the 3937% upscale. Seems there could be an added button in lightwave to work in real world units. With 3D material being passed into so many different forms , it would help a lot.

Carcegen
05-13-2010, 12:45 AM
You just finish with the size stated in LW and it prints out the exact size? wow... Not here at all.


We 3D print real world scale decorative hardware for furniture from LW models everyday. We use Chrome Cow's STL import/exporters. No problems what so ever.

Silkrooster
05-13-2010, 01:12 AM
There is nothing written to the LWO file to indicate that one unit is one meter.

The actual size is written to the LWO file with no indication that the units are meters.

If the user enters 1 meter in LightWave, then 1.0 will be written to the LWO file.

If the user enters 1 inch in LightWave, then 0.0254 will be written to the LWO file which is the value another program will find when it reads the LWO file.

Conversion of measurements when switching between programs is a big headache.

Wayne
Ok, I think I got what you mean. It writes the correct value to the file just does not include what measurement system was used. So the program reading the file does not know if it was in inches or the metric system or some other alien system some dope thought of.

Lightwolf
05-13-2010, 06:33 AM
So that when you are working in say inches, the object is truly the size it states?
Yes. And the size also doesn't change if you change the way LW displays units either.
The unit "conversion" is only for display to the user.


From what I'm hearing lightwave assumes that 1.0 is 1 meter. So to get one inch to read correctly I need the one inch converted to one meter - hence the 3937% upscale.
No, no, no, no. ;)
It is precisely the correct size already. But, if you export to another file format then the reading application needs to know what one unit within that file is (as most 3D files formats, especially simple ones like STL, have no explicit units).
If the reading application assumes that one unit in the STL is one inch, and you can't change that to be one metre in said app, then you do need to scale in Modeler. But that's just to get that "dumb" other app to read the STL as you expect it to, LW itself handles the stuff perfectly well.

Cheers,
Mike

shrox
05-13-2010, 08:37 AM
I am not referring to a unit of measure, the mesh has to be scaled up by 3937%. Why the odd number? Why not 100, or 1024, or some mathematically sensible number?

Lightwolf
05-13-2010, 08:47 AM
I am not referring to a unit of measure, the mesh has to be scaled up by 3937%. Why the odd number? Why not 100, or 1024, or some mathematically sensible number?
Because imperial measure aren't sensible ;)
What's the conversion multiplier from one inch to metres?
And in this case it's not even a "conversion" as such, but a "hack" to let one inch be equivalent to the value 1.0 (in a metre based system) for a tool that expects 1.0 to be one inch.

Cheers,
Mike

shrox
05-13-2010, 08:49 AM
What's the conversion multiplier from one inch to metres?

Doh! I can't believe I didn't recognize that!

Lightwolf
05-13-2010, 08:51 AM
Doh! I can't believe I didn't recognize that!
I couldn't either, that's why I was easy on you :D

:beerchug:

Cheers,
Mike

shrox
05-13-2010, 08:53 AM
I couldn't either, that's why I was easy on you :D

:beerchug:

Cheers,
Mike

It happens, I only recently realized the spelling of "The Beatles" was significant...

Dexter2999
05-13-2010, 08:57 AM
LW says "1"
Other software says "1 what? One of these?" and substitutes a unit of measure.

You wanted inches. The other software substituted something else.
Wayne explained the math above.
1 inch x 2.54 centimeters per inch = 2.54 centimeters = 0.0254 meters

0.0254 meters x 39.37 inches per meter = 1.0 inch

See that "39.37" that is your magic number. Move your decimal and corespondingly so on the Metric measurement and you will find what your other software is substituting (I think). Two places over would be from Centimeters, to Millimeters, to Nanometers (someone who actually uses Metrics please correct me). So the 3937 is to convert from Nanometers to Inches. (I think)

bjornkn
05-13-2010, 10:12 AM
3937 would be the percentage to scale to, hence value * 39.37 or *3937%.

The easy way for you imperial STL'ers would be to forget your inches and just model in meters (as we modern people do ;) , pretending that they are inches. When exporting to a program that doesn't understand other input units than inches it will never know that those inches were actually meters inside LW. The numbers will be just fine as they are ;)
No need for 3937 any more ;)

shrox
05-13-2010, 10:18 AM
3937 would be the percentage to scale to, hence value * 39.37 or *3937%.

The easy way for you imperial STL'ers would be to forget your inches and just model in meters (as we modern people do ;) , pretending that they are inches. When exporting to a program that doesn't understand other input units than inches it will never know that those inches were actually meters inside LW. The numbers will be just fine as they are ;)
No need for 3937 any more ;)

Yes, But I just didn't notice the 3937 relationship. 39.37 inches equals 1 meter (well, .999999 meter). And I was officially taught metric too...

Dexter2999
05-13-2010, 11:19 AM
Aside from the math...

Could it be that the difference is in that the program you are bringing it into doesn't know units so it defaults to the lowest measureable unit? In standard the smallest complete unit is an inch and from there you move into fractions. But in Metric they don't do fractions so it defaults to nanometers?

What I think I am understanding is that even if modeled in Meters in LW it doesn't say "meters" it just gives a quantity. So importing a LW model using metrics could still need to be scaled up by 1000? or 10000?

Lightwolf
05-13-2010, 11:43 AM
What I think I am understanding is that even if modeled in Meters in LW it doesn't say "meters" it just gives a quantity.
Well, yes. LW interprets the quantity of 1.0 (if used for dimensions) to be 1 metre, regardless of which unit system it uses to display said quantity to the user.
And also imports/exports that way. Most (if not all) file format only deal with quantities anyhow, so you'd need to scale at one place in the process and change the actual quantities to a range that the other app expects.

One could also say: 1.0 represents a quantity in LW that is 39.37 inches, or three odd something feet (and this is a display only conversion that the unit system does for you).

Cheers,
Mike

Captain Obvious
05-13-2010, 01:35 PM
The more important question is: why the heck are you using anything other than metric?

Lightwolf
05-13-2010, 01:47 PM
The more important question is: why the heck are you using anything other than metric?
It wouldn't help in his case though. So the real question is: Why the heck does the app reading the STL for rapid prototyping assume the imported file is 1 inch per unit?
Or doesn't it?

Cheers,
Mike

Dexter2999
05-13-2010, 01:56 PM
Metrics are just French propganda :P

MicroMouse
05-13-2010, 03:11 PM
Some file formats have a unit of measurement associated with the dimensions and some file formats do not have a unit of measurement associated with the dimensions.

Even when a file format has a unit of measurement associated with the dimensions that does not mean the actual value stored to the file has not been scaled to a different unit of measurement or to a value that has no relationship to any unit of measurement.

<Example>
A LightWave user is building a terrain and the dimensions are all in meters. The terrain will be saved to one LWO file. At some point the user realizes that the terrain which is centered at the origin is too big and the dimensions are exceeding the limits of single precision floating point numbers used by LightWave.

The user decides to scale down all dimensions by 0.45 (45 %) and then finish building the terrain. The user saves the terrain to both an LWO and DXF file.

The CAD user knows his friend uses LightWave so he starts measuring in meters and gets strange results. After talking to his friend the CAD user divides all dimensions by 0.45 and he can now measure everything directly in meters. CAD software usually uses double precision floating point numbers so has no trouble handling the terrain in actual meters.
</Example>

There is no simple automatic solution for exchanging models between various software and so don't be surprised if you have to do some scaling to get the dimensions right sometimes.

--------

The StereoLithography Apparatus (SLA) was created by 3D Systems, Inc. I have a specification document that they sent me dated "October, 1989". From this document

<quote>
CAD UNITS
The CAD units must be either millimeters or inches.

1 millimeter = 0.03937 inches
1 inch = 25.4 millimeters
</quote>

All information in the specification talked about building the models in CAD software.

I have no information on this and just assume that the SLA software had a control which could be set to either millimeter or inch before reading the STL file.

Wayne

Lightwolf
05-13-2010, 03:18 PM
<Example>
....At some point the user realizes that the terrain which is centered at the origin is too big and the dimensions are exceeding the limits of single precision floating point numbers used by LightWave.

The user decides to scale down all dimensions by 0.45 (45 %) and then finish building the terrain....
Floating point doesn't quite work like that unless the terrain is the size of the solar system ;)
It's relative sizes that matter (small in relation to huge), not absolute sizes.

Not that it really matters in this discussion ;)

But there you go, if they expect millimetres, scale by 1000 before exporting and you're set.

Cheers,
Mike

jaf
05-13-2010, 06:53 PM
One of the reasons many Terragen users like Lightwave as their modeler is a 100m building from LW scales perfectly with a 200m hill in TG (the top of the building is at the 100m mark of the hill, if both are based at y = 0.) You can work in the same scale with both applications.

MicroMouse
05-13-2010, 10:12 PM
I know how floating point numbers work, Mike.

Just a terrible brain lapse when making up an example.

Wayne

Silkrooster
05-13-2010, 11:03 PM
You know you guys shouldn't harp too much about the imperial system. Not all measurements are taken as fractional units. When accuracy is required, measurements are done with the decimal system.
An example is a metal shop where the need to measure down to 1/1000 of an inch or smaller is required. Even though I had written it has a fraction, a micrometer or caliper will display it as a decimal.

Lightwolf
05-14-2010, 04:47 AM
I know how floating point numbers work, Mike.

Just a terrible brain lapse when making up an example.

That happens to all of us ;)

Now where's my coffee?

Cheers,
Mike

bjornkn
05-14-2010, 06:01 AM
For fun I had a look at http://en.wikipedia.org/wiki/United_States_customary_units and imperial/US measurements really are much worse than I thought. Not only is it completely inconsistent, but there is also a lot of different types of measurments with the same name. Like a troy pound is different from an Avoirdupois pound, survey feet being slightly different from a standard feet etc. What a mess! Do you archviz guys really have to battle with survey leagues, miles, furlongs, chains, rods, feet and links (33/50 feet!) ?
It's a bit funny though that a US survey foot is defined as 1200/3937 m!, which makes it 1/8inch (3mm) longer per (Survey?) mile than a "normal" foot ;)

shrox
05-14-2010, 08:47 AM
For fun I had a look at http://en.wikipedia.org/wiki/United_States_customary_units and imperial/US measurements really are much worse than I thought. Not only is it completely inconsistent, but there is also a lot of different types of measurments with the same name. Like a troy pound is different from an Avoirdupois pound, survey feet being slightly different from a standard feet etc. What a mess! Do you archviz guys really have to battle with survey leagues, miles, furlongs, chains, rods, feet and links (33/50 feet!) ?
It's a bit funny though that a US survey foot is defined as 1200/3937 m!, which makes it 1/8inch (3mm) longer per (Survey?) mile than a "normal" foot ;)

Most of those terms are antiquated and not commonly used. I was on a Central Arizona Project survey team for the US Dept of the Interior, and we measured across the Arizona desert 33 feet at a time...

Dexter2999
05-14-2010, 10:02 AM
we measured across the Arizona desert 33 feet at a time...


Only because you were getting paid by the hour. ;)

bjornkn
05-14-2010, 01:51 PM
US survey feet then, I suppose? ;)

JonW
05-17-2010, 02:41 AM
Which “hour” are you using, an “Apparent solar hour” or a “Mean Solar hour”?

warmiak
05-17-2010, 10:24 AM
It wouldn't help in his case though. So the real question is: Why the heck does the app reading the STL for rapid prototyping assume the imported file is 1 inch per unit?
Or doesn't it?

Cheers,
Mike

It has to assume something ... as you know when it comes to units in 3d rendering there is only one i.e 2.0f is twice as large as 1.0f :-)

shrox
05-17-2010, 10:26 AM
Which “hour” are you using, an “Apparent solar hour” or a “Mean Solar hour”?

In the hot Arizona summer sun, every hour is a mean solar hour...

Lightwolf
05-17-2010, 10:53 AM
It has to assume something ...
Well, since it does with physical sizes in the end it shouldn't. That's what prefs and import options are there for. *shrugs*

Cheers,
Mike

05-18-2010, 04:47 AM
And of course if everybody works in SI there's no problem.
Except of course there is.
To software a unit is a unit - not an actual inch(length of thumb joint), yard (length of bit of wood in museum,) meter (distance between 2 notches on a who-knows-whatium rod in a sealed chamber) or mm (obscure multiple of wavelength light emmited by over-excited molecule of who-knows-what-else-ium in a vacuum).

All our work is digital & in metric, nominally SI.
It's just that the Hairdressers (architects, artists, blokes with ponytails) think that one basic unit is 1m (in this they agree with LW), while the Plumbers & Boilermakers have all read the SI small print and think that one basic unit is 1mm.
At least an error of x1000 in linear measurement is pretty easy to spot, whereas mm/inch confusion has often crept through to the construction stage!
(Not forgetting a horrific episode (which I like to try and forget) some quarter century ago, when I discovered mid project that although some nice people in a certain far east country were using feet & inches on their dimensioned drawings returned for checking, there were oddly no measurements involved 10 or 11 inches.
They were using feet as their basic measurement OK, but had decided on feet & tenths of feet, and based their way of writing it down on drawings we had sent them.
So their 1'5" was actually 1'6".
Certain large expensive objects did not fit together very well.

johnliebler
05-18-2010, 07:07 AM
In ancient times...
Hundreds of years before the dawn of history
Lived a strange race of people... the Druids

No one knows who they were or what they were doing
But their legacy remains
Hewn into the living rock... Of Stonehenge

:)

BeeVee
05-18-2010, 01:42 PM
Oh no! Does metric go up to 11 now?

B

Lightwolf
05-18-2010, 01:46 PM
Oh no! Does metric go up to 11 now?

B
That'd be hexametric, up to 0xf ...

*rimshot*

Cheers,
Mike

shrox
05-18-2010, 01:48 PM
In ancient times...
Hundreds of years before the dawn of history
Lived a strange race of people... the Druids

No one knows who they were or what they were doing
But their legacy remains
Hewn into the living rock... Of Stonehenge

:)

(Enter tiny little Stonehenge pi sign...)