PDA

View Full Version : Correct LightWave Modeler precision settings?



chippwalters
01-04-2014, 03:31 AM
Typically, with most 3-D modelers there is a finite model universe. And, by setting the default working space units, you can optimize that model universe for whatever scale you are working in.

I want to model for a 5" x 5" x 5" 3-D printing model size. I also want to use mm. What are the best settings to use in order to create the highest accuracy possible for this volume?

I searched this forum as well as the current LW Modeler documentation but could find nothing regarding modeling precision. Any help would be much appreciated. Thanks!

lertola2
01-04-2014, 08:32 AM
Lightwave uses real world units and the unit is always meters. You can type other units into Lightwave's edit fields but internally Lightwave will store the numbers in meters. For example you can type 22 mm, or 3.5 ft. and Lighwave understand that.

jeric_synergy
01-04-2014, 10:59 AM
(awayfrommachine) I tried to do " 1/8" " in LWM yesterday and couldn't make it work. I was puzzled. Also tried " 1/8 in ".

Very (sadly) surprised. What was I missing?
++++

To answer the OP, there's also a setting somewhere in LWM that sets the PREFERRED units: defaults to meters, but you can set to cm, mm, km, whatever. Also choose between metric, English, and the other one that seems identical to metric.

For most RW things, centimeters is a reasonable unit. I usually think of it as ~half an inch.

UnCommonGrafx
01-04-2014, 11:04 AM
Press 'd'.
Look at the Units tab.
You can change it to the English system, if you wish, and it will show up as 1/8".

To the OPs question, and to add to Lertola2's comment, as you zoom in and out, modeler re-configures its space. You can see what scale the space is by looking in the left-lower corner. IF it says 1m, then each block is 1m; if you zoom in and it becomes 10mm, that will be the size of the present grid. In this way, a great deal of precision can be had and seen.

jeric_synergy
01-04-2014, 11:08 AM
UCG, but my understanding was that no matter what system you had set, you could enter, say,
1mtr+2"+0.25cm+2'
and get a correct answer.

To clarify, it wasn't that it DISPLAYED wrong, but that it was totally incorrect: LWM was translating 1/8" to something like 3 meters.

chippwalters
01-04-2014, 11:46 AM
So, I'm a bit confused. Can I create a 1 mm part on an object the size of the galaxy? Obviously not. So, how best to manage the discrepancies in scale?

jeric_synergy
01-04-2014, 11:54 AM
With illusion.

chippwalters
01-04-2014, 12:25 PM
With illusion.

While illusion works great at the movies, I just can't get it to work with my 3D printer. :-)

jeric_synergy
01-04-2014, 01:01 PM
Next time you print out a 1:1 galaxy, we can address this issue.

Shiny_Mike
01-04-2014, 01:55 PM
If you're modeling small features on say skyscrapers, and get stuck (can't zoom in anymore, etc..) one way around it is modeling at 10X scale and scale everything by .1 once model is complete. 5"x5" doesn't seem to give me trouble though - just tried a 5"x5" shape, grid snap at 1um, and I was making slices 1um apart. (btw, if you haven't used it - the "info" tool is nice for checking position values/moving points to an exact position. select some points and hit the "w" key)

lertola2
01-04-2014, 02:53 PM
So, I'm a bit confused. Can I create a 1 mm part on an object the size of the galaxy? Obviously not. So, how best to manage the discrepancies in scale?

Lightwave is limited by the precision of the floating point numbers that it uses to store vertex locations. So it does not work well to model a 1 cm object several km out in space. You use up the significant digits of your floating point numbers by moving the object so far away from the origin so there is less precision for the shape. If I were making something smaller than 1mm or larger than 1000 km I would change its scale so that the units were not so extreme. I am working on an animation now that zooms from a few inches down to a 10 nanometer scale. The 10 nanometer objects are modeled about a meter wide. They are scaled down in layout to be the correct size.

UnCommonGrafx
01-04-2014, 03:07 PM
Correct, it did that because the units weren't clear, so were translated to meters: 1m/8" is what I think it did. Or some such mathematical error. So it gave the right answer for the question it thought you asked.

Scaling up and down work well, too.

And Chipp, you can.

jeric_synergy
01-04-2014, 03:18 PM
Yup, that did it. Got to review my order of procedures. :thumbsup:

(1/8)" gets it right ( 3.175mm ).

It's pretty cool to switch to English, type in " 3.175mm" and see it convert to 0.125". Cheap thrills.

I still don't understand the difference between SI and Metric, and frankly don't care.

Lightwolf
01-04-2014, 05:14 PM
I still don't understand the difference between SI and Metric, and frankly don't care.
Make sure to ignore my reply...

SI only displays the official steps of 1000 (i.e. mm, m, km) while metric uses intermediate steps as well, such as cm. No dm though by the looks of it.

Cheers,
Mike

chippwalters
01-04-2014, 05:14 PM
Thanks guys! So FWICT, LW Modeler dynamically adjusts it's 'working space' and accomodates precision issues by analyzing the largest bounding box of all the objects vs the smallest point differences and then setting it's working space resolution thusly.

Is this close?

IOW, I really don't need to do anything else but set the units to meters and I'm good to go?

Lightwolf
01-04-2014, 05:31 PM
Thanks guys! So FWICT, LW Modeler dynamically adjusts it's 'working space' and accomodates precision issues by analyzing the largest bounding box of all the objects vs the smallest point differences and then setting it's working space resolution thusly.

No. Essentially, all coordinates are stored as metric floating point values. 1.0 being 1.0 metres.

The coordinate values you see in the GUI are on the fly conversions due to the units setting.

However, floating point has inherent problems (this is essentially a general problem all applications using floating point on computers need to deal with). While a large range of values can be represented by them, not all numbers within that range can.*

Also, adding a tiny number to a massive one will result in the tiny one being essentially ignored - this explains precisions issues far away from the origin.

What LW reconfigures is the size of the grid, depending on the area that's visible in the viewport.

Cheers,
Mike

*floating point numbers are a fixed set of digits for a decimal part coupled with a mantissa. I.e. 1.3456e10 (the e10 would shift the decimal point by ten places, making the number stored here 1^10 times larger - that's 10 zeroes.).
Since the decimal part (1.3456) has a fixed length though (5 digits in this example), adding, say, 1.3456e0 (no decimal shift at all) wouldn't do anything since it can't be represented in this way.
The floating point number would need to have the capability of storing at least 10 digits before the decimal plus the ones behind it.

chippwalters
01-04-2014, 05:51 PM
OK. Thanks for that explanation-- esp the 1.0 'basic unit' being 1.0 meters.

So then it goes to reason:

.01 = 1 cm
.001 = 1 mm
etc..

So, my max 3D print build volume is W:140 x D:140 x H:135mm
which is .14 m x .14m x .135m

And the smallest resolution I want to be able to print will be something like 0.15 mm which would translate to base units as:

0.00015 m -- which is a fixed length of 6, not 5 as shown in the example. So, my question is as long as I stay within, say 1m x 1m x 1m build volume, will I have enough resolution to reliable not have any numeric drift? Or, is there a better setting to use than meters?

Lightwolf
01-04-2014, 06:02 PM
0.00015 m -- which is a fixed length of 6, not 5 as shown in the example. So, my question is as long as I stay within, say 1m x 1m x 1m build volume, will I have enough resolution to reliable not have any numeric drift?
Yes, that should be fine. 32-bit floats allow for a precision of ~7.5 digits, double for ~15.9.
Internally, LW stores coordinates using doubles. And at least then saving as an ascii STL, that precision should be retained.

Or, is there a better setting to use than meters?
Internally it's always metres anyhow, so it doesn't matter. And using a larger/smaller scale doesn't affect the precision at all (within reason that is - then it just gets worse ;) ).

Cheers,
Mike

sublimationman
01-04-2014, 06:15 PM
Modeler can zoom in or out to make your objects fit. You can work on an object that is hundreds of meters long (say a space ship) and then zoom in to look at and work on a single bolt that is 1mm in size. It does this in many ways including the < & > kets as well as pressing "a" to zoom to fit your entire model and many other methods.

spherical
01-04-2014, 08:03 PM
OK. Thanks for that explanation-- esp the 1.0 'basic unit' being 1.0 meters.

So then it goes to reason:

.01 = 1 cm
.001 = 1 mm
etc..

So, my max 3D print build volume is W:140 x D:140 x H:135mm
which is .14 m x .14m x .135m

And the smallest resolution I want to be able to print will be something like 0.15 mm which would translate to base units as:

0.00015 m -- which is a fixed length of 6, not 5 as shown in the example. So, my question is as long as I stay within, say 1m x 1m x 1m build volume, will I have enough resolution to reliable not have any numeric drift? Or, is there a better setting to use than meters?

I think you're obsessing about something that really doesn't matter, at least in LightWave. I model all of my parts for printing to real-world scale using a default Unit of Inches. It just works, because how big something is is all you're concerned with in the end. IOW, LW can move/size things on a sub-mil level: 0.0001 mil, to be exact. Doesn't rotate things fine enough for me sometimes, only goes down to 0.01, but I'd venture that this level of fine resolution should meet the requirements of a 3D printer.

jeric_synergy
01-04-2014, 08:22 PM
We're a bit caught up in the weeds here, but:

For convenience, the DEFAULT UNITS setting allows you to enter dimensions in whatever is convenient. In Metric, I can set the default units to Centimeters, enter "1", and it will display 1 cm.

If I enter "1000" it displays 10 m, as 1000 centimeters=10 meters.

As to precision, as Mike said/implied (I think), the greatest precision is available closest to the origin, it's only when you're kilometers away from 0/0/0 that accessible locations start to jump around. So, don't model small things out there.

He said something else but that was caught in my ignore-field.

Lightwolf
01-05-2014, 04:30 AM
As to precision, as Mike said/implied (I think), the greatest precision is available closest to the origin, it's only when you're kilometers away from 0/0/0 that accessible locations start to jump around. So, don't model small things out there.
Yup.


He said something else but that was caught in my ignore-field.
I did? :p

Cheers,
Mike

UnCommonGrafx
01-05-2014, 07:06 AM
Mike,
You spoke to some mathematics in your post.
He may have glazed over.

lol.

Riff_Masteroff
01-05-2014, 03:10 PM
" . . . . . Doesn't rotate things fine enough for me sometimes, only goes down to 0.01. . . . . ."

Rotate will work down to .0001 deg! ! !

Its not well known, but the rotate requester display only goes down to .01 deg. For example, type in .0001 deg and zoom in to the object you are rotating. The requester will show 00 deg, but hit apply multiple times and . . . You will see your object rotate by .0001 degrees each time you 'hit' the apply key.

spherical
01-05-2014, 06:28 PM
AhHA! Wow, that's good to know. I never tried an actual test to see what happened, just took the input field at its word. That needs to be fixed. I even asked for it in the v9.6.x Beta program and it got ignored.

Just tried it and it actually goes down to 0.00001 That's fine enough for me!

C'mon, let's get the UI limitations fixed. The application can do it, no problem.

jeric_synergy
01-05-2014, 06:41 PM
For a non-interactive solution, an LScript would probably work.