Scale units option

[Aaron]

Hi Cliff,

Oops, the validation is a bit nuts-o in that dialog. You can enter a '.', but you have to enter at least one digit first. E.g. to write '.5', write '5', then add the dot. That's something I'll tidy up for v2.4b.

Cheers,
Aaron.

[cliff]

Awesome! Thanks again!

For those of you needing feet-to-meters, to do a 1 pixel per foot use a pixel size of 0.3048 pixels per meter and it will be 1 pixel per foot. Any other scale can be derived from there.

I'm too lazy to remember the forumulas, but you can use this page for it.

Cheers!

[Aaron]

Hi Cliff,

I've just uploaded L3DT v2.4b release candidate 1, which has less enthusiastic data validation on the horizontal scale in that dialog. It now checks that the value is a valid number when you click 'next>', rather than as-you-type.

Cheers,
Aaron.

[jack.dingler]

I personally don't find the conversions to be a big deal.

For gaming space, visual a meter as a yard. It's close enough. After all, you're not cutting wood. It's just electrons.

I'm currently responsible for maintaining and updating a CAD/CAM system to drive plasma (and other) cutters for sheetmetal and plate.

We have to worry about metric/imperial units and integration with a variety of systems and formats.

It's not very pretty.

I'm taking legacy code that was orginally built by a DOS programmer and bringing it into the 1990s. Someday we might even shoot for the new millenium...

In some of the systems, it became a real pain to keep track of units for angles and other systems, so I'm found myself building a numbers class that is built on a double data type, and derived classes know what kind of units they are. I've proven it works for angles where radians, degress and quads all get interchanged, so now the next part is to tackle imperial, metric, etc...

Its gonna be a pain, but in the end it'll be worth the effort.

But I'm working on a huge complex system with lot's of components. And we have to be international in our units. I can justify spending the time and money doing it.

I don't see that as the case on an app like L3DT. The app has a lot of work to do, can take hours to complete various passes, so I see speed as more important than unit flexibility.

BTW, are you using floats or doubles? Once on the chip, floats are promoted to long doubles, then demoted again going to memory.

I don't know that there's any reason to use floats in code, with modern processors.

[Aaron]

Hi Jack,

BTW, are you using floats or doubles? Once on the chip, floats are promoted to long doubles, then demoted again going to memory.

I don't know that there's any reason to use floats in code, with modern processors.

I use doubles where possible, and floats where necessary for memory space concerns. Heightfield, for instance, are always floats, and occasionally short ints. Also, once you get to large maps sizes - where speed is really a concern - you're probably going to use the mosaic system, which is mostly disk-limited anyway (I'll admit this is kind of a lazy justification for not doing more optimisation, but it's nonetheless reasonably truthful).

Cheers,
Aaron.