Scale units option

[monks]

Hi Aaron, it would be nice to have the option of working in imperial units: feet and miles. Even though scale always redounds to metres, I often find it easier to set heights in the DM for instance in feet- especially for hills and mountains (relative relief I think they call it).

Cheers,
monks

[Aaron]

Hi Monks,

Hmm...I'll think about it, but at first pass I'm not very excited with the idea. Allowing other unit systems would, at the very least, require the re-write of a swag of dialog boxes to allow for dynamic substitution of '(m)' for '(ft)' or '(mi)' in labels, plus auto-conversions to/from metres in the open/close code. If I do it in one place, I'd have to do it everywhere to be consistent.

Then there are presets to think about. Yech.

And which mile? There's international (i.e. English), U.S. survey, nautical, long, Roman, Dutch, metric, etc. Same goes for feet. And if I'm supporting these archaic units, why not farthings, furlongs, fathoms, chains, rods, yards, inches, leagues, cubits, ... [Aaron wanders off in the distance mumbling to himself].

Whoa, sorry for that. Umm...as I said above, I'll think about it, but no promises.

Cheers,
Aaron.

[monks]

And which mile?

Why, the English country mile of course, the best there is dear boy!

I suppose it does complicate things...shame as feet are so comfy.

monks

[JavaJones]

This is where I could see shared components and developer cooperation paying off. Sure you'd still have to implement the dialog changes but what if someone had done all the unit conversion grunt work for every imaginable unit already, up front? Wouldn't that make things a lot easier?

I can never get a good impression of just how tall something is (in relative terms) in meters, even though I can always convert to feet.

- Oshyan

[monks]

'owdo Oshyan Good point. Same here, I always think in feet, especially for terrain

monks

[Aaron]

'ello,

Wouldn't that make things a lot easier?

Not a 'lot'. The grunt work, as you put it, is the trivial part. At a guess, I'd say it would be about a five minute job to implement the actual unit conversion code (from any of the units listed above to any other). Furthermore, it would probably be quicker to do this myself than to find and download someone else's code, bash it into the correct shape, then verify that it works as advertised/expected. Don't get me wrong; code re-use is a wonderful thing, but it's wasted effort on simple problems.

The hard parts of this problem are making sure the conversions are done everywhere they should be, keeping track of which units to use where, hacking the dialogs appropriately (!), and verifying that everything works as it should under all/most conditions. At a guess, that's a couple of weeks worth of work.

Anyway, I am currently implementing a new generic dialog/control framework that would allow me to easily hot-swap 'm' with 'ft'/'mi', so once that's done I might have another look at supporting archaic^H^H^H^H^H^H^H imperial units. Then again, once that's done I'll be using it to implement the painting tools for the heightfield/texture/etc, which is probably of greater interest, no?

Cheers,
Aaron.

[monks]

Don't get me wrong; code re-use is a wonderful thing, but it's wasted effort on simple problems.

Absolutely. The time spent even digging it out on the net wouldn't be worth the trouble sometimes.

Then again, once that's done I'll be using it to implement the painting tools for the heightfield/texture/etc, which is probably of greater interest, no?

Hmmm....let me see, the ability to work in chains and rods or heightmap pencil ...

monks

[JavaJones]

Point taken. Obviously the conversion code itself would be simple, it's finding the details of all the units and setting up the specific conversions that might be tedious.

It seems like if these kinds of components were more widely know/available anyone starting a project such as yours would keep them in mind or even utilize them from the beginning, thus saving a fair amount of work. I am guessing at any rate that meters was used in your app by default because you didn't feel it necessary or worth your time then to implement a more flexible system. But if a more flexible system was already available and all you had to do was let it hook into your code, and you were building from scratch, it seems like it'd be a lot more efficient way to go.

- Oshyan

[Aaron]

Hello,

Point taken. Obviously the conversion code itself would be simple, it's finding the details of all the units and setting up the specific conversions that might be tedious.

That bit's easy too. A quick google/wikipedia search brings up the convention from all these units to metres.

It seems like if these kinds of components were more widely know/available anyone starting a project such as yours would keep them in mind or even utilize them from the beginning, thus saving a fair amount of work.

Seriously, 5 minutes at best. Unit conversion is not the hard part.

I am guessing at any rate that meters was used in your app by default because you didn't feel it necessary or worth your time then to implement a more flexible system.

Yup, I didn't think it was worthwhile. Call me an International System of Units snob.

But if a more flexible system was already available and all you had to do was let it hook into your code, and you were building from scratch, it seems like it'd be a lot more efficient way to go.

Trust me on this Oshyan, having a reusable conversion module would not save much time. In the time it took me to reply, I probably could have implemented the conversion to/from metres/US feet/imperial feet/yards, US miles, imperial miles (etc...) twice over. The hard part, and the part that can't be made into a reusable module, is all the application-specific stuff like checking/converting inputs at the starts/ends of all of the algorithms, re-building the user-interface, and debugging the whole mess.

Cheers,
Aaron.

[JavaJones]

I will certainly bow to your much greater knowledge on this.

So is it particularly more difficult to implement a multi-unit system *from scratch* as compared to a single unit one?

- Oshyan

[Aaron]

Hi Oshyan,

Yeah, sadly it would be.

With a single unit system there is nothing to fear, since you never have to do a conversion, and you are always absolutely certain as to the units of various quantities.

With multi-unit systems, you have to check the units *every* time you use a quantity, and convert where necessary. This opens up a huge potential for mistakes, which could corrupt data in a very hard to find way. The big dangers are simply forgetting to check/cast a variable in an instance, or by accidentally casting to the wrong unit. The latter is particularly insidious, as it would appear to be correct until you carefully stepped-through the code. Programmers aren’t infallible and will make mistakes – using a multi-unit system would simply give them more opportunities to do so. This means debugging and validation would be harder too.

Now, L3DT does support multiple units in a few instances, such as the BT load/save code. However, this is easy to manage because it's a very well-defined problem. There is one point in the BT loader and one point in the saver where I have to check the units and convert accordingly. Everywhere else it's metres.

Hmmm...I suppose you could create a class to encapsulate your variable-unit quantities and do automatic-casting when called upon, but that's still a lot harder than using a standard data type such as float. Even with a nice class like this, you would still need to specify the units to which you are converting, so you're still prone to those hard-to-find coding mistakes.

Furthermore, performance would suffer. You’d have to use more memory to nail the unit to each quantity, and the extra casting would slow things down (not much if done right, but non-zero nevertheless).

Then there's the user-interface. Every time you show or read-in a quantity, you have to display its unit. Like most developers, I use static text in most dialogs because it’s quick and easy. With variable-unit quantities, you have to re-format that text depending on the unit. That's not actually super-hard, but it is harder than always assuming the same unit.

So, in summary, yes it would be harder. This little black duck doesn't think the extra effort would pay-off in this case (though I have no doubt it is necessary in other GIS-type apps).

Cheers,
Aaron.

[JavaJones]

Gotcha. Thanks for the detailed explanation.

- Oshyan

[cliff]

I have an idea for a potentially viable workaround on this, which also happens to be useful to me... allow a floating point number for the meters per pixel.

I don't know what this would do to your calculations though, and whether or not this would actually work...

[Aaron]

Hi Cliff,

Uh, I think all the relevant dialogs do accept floats for metres per pixel. Have you found otherwise?

Cheers,
Aaron.

[cliff]

When I am in the Design Map Size screen, under Heightfield Resolution (m), it will not let me enter a float value.

If it is allowed, maybe I'm just doing something wrong. I tried both 1.6 and 1,6 with no luck in either case. The cursor just returns to the first position of the field when I hit the period or comma.

That being said, it seems like a pretty good solution to the metric/english issue if someone wants, say, 1 pixel per foot or something.