Compass tab - a suggestion and a wish

[WAS]

Like I said before I think "roaming the planet" is a minor use case. I'm sorry.

Using the search feature of the forum and real world data used in projects a lot says otherwise. We literally just had a recent topic about finding real world data on the planet. It's also one of the focuses of the software and a major feature point. Just cause you import heightmaps at 0,0,0 and slap shit on them says nothing about it's points and other users uses.

[Hetzen]

Like I said before I think "roaming the planet" is a minor use case. I'm sorry.

Using the search feature of the forum and real world data used in projects a lot says otherwise. We literally just had a recent topic about finding real world data on the planet. It's also one of the focuses of the software and a major feature point. Just cause you import heightmaps at 0,0,0 and slap shit on them says nothing about it's points and other users uses.

The further away you get from the origin, the more rounding errors you will get with large numbers, especially when using real world units for planetary sized objects. Even at 64 bit, if 0,0,0 is at the pole and you are looking at a rock on the equator, scales in the mm's will cause problems frame by frame. It is generally best practice to keep as much of the camera action around the origin, especially for animations.

[WAS]

Even at 64 bit, if 0,0,0 is at the pole and you are looking at a rock on the equator, scales in the mm's will cause problems frame by frame. It is generally best practice to keep as much of the camera action around the origin, especially for animations.

Seems more an admission of failure of Terragen as a product. Lmao Literally contradictive to selling points and features (from orbit to ground level anywhere on the planet; not 0,0,0). Additionally, I've done plenty of scenes away from 0,0,0, such as Mt St Helens at it's origin in my state, without any noticeable issues.

These are things to fix, or why the hell is Terragen rendering a planet for absolutely no reason (literally overkill calculations over any other engine and planes), if it doesn't work? For orbital shots only? lmao

Again, these conversations of pure limitation don't serve TG well. Lol This forum comes up in all searches regarding the software and if it's good to use.

[Hetzen]

What? You don't half talk a load of crap.

People tend to make their landing point around 0,0,0 and adjust their scenes accordingly. As they do in any software.

[Tangled-Universe]

Thanks Jon, will have a look!

[WAS]

What? You don't half talk a load of crap.

People tend to make their landing point around 0,0,0 and adjust their scenes accordingly. As they do in any software.

"Any software" is using planes you rearrange. This is an entirely different concept and your claim not only contradicts Planetsides narratives on Terragen (on the website, interview, and magazine), but the concept in general. For one talking about crap, you're sure spewing it, and making TG look like crap. The whole planetary model is inherently designed to move away from planes and static scenes in one position. It's hard to believe you missed that.

So much for infinite detail, sweeping vistas, moving along terrain (at scale) and orbital to surface/vise versa shots, huh? I guess TG is just full of BS? Lol Idiotic discussion.

[Matt]

OK, guys, you both said your bit.. let's keep it civil please. You both said things that are right. Terragen can render entire planets. Near the origin you can get very close to the surface. Far away from the origin you can't get as close without rounding artefacts, so you might want to think about where the origin is if you need to get really close to the surface. If you're rendering an entire planet from orbit, or even a high altitude shot, this isn't a problem. For space-to-ground zoom shots, it's preferable to make your ground view fairly close to the origin.

[Matt]

I've been thinking about this feature. The calculation speed is not a problem, it's going to be fast. But we need to define what the compass angles mean. There are a few different ways to set up a Terragen planet and think about its coordinate system, and each one will have a different meaning for compass heading. The Sunlight settings have the same problem, but I chose one coordinate system which makes sense for landscapes located at the origin and at the "top" of the planet. I feel that it's useful to stay consistent with the Sunlight controls, so I'd probably want a compass setting in the Surface Layer to work the same way (at least by default). However, this would have strange results if you use it far from the "top" of the planet. At different parts of the planet a different coordinate system would be preferable, but it would not correspond to the sunlight controls.

[WAS]

OK, guys, you both said your bit.. let's keep it civil please. You both said things that are right. Terragen can render entire planets. Near the origin you can get very close to the surface. Far away from the origin you can't get as close without rounding artefacts, so you might want to think about where the origin is if you need to get really close to the surface. If you're rendering an entire planet from orbit, or even a high altitude shot, this isn't a problem. For space-to-ground zoom shots, it's preferable to make your ground view fairly close to the origin.

I had no issues with Mt. St. Helens at origin. We're northern hemisphere, but not extreme or anything. Very far from north pole. Was no real issues with ground details, surface constraints or anything. So I'm wondering how extreme an effect this is, to what extremes.

You'd think with a planetary model, and what inherently implies, the planet would be rotated and 0,0,0 would be equatorial, so if your scene was going to orbital shots, you're coming from the equator region, and can easily setup poles without them being your focal areas and putting poles at opposite equators.

[Hetzen]

I've been thinking about this feature. The calculation speed is not a problem, it's going to be fast. But we need to define what the compass angles mean. There are a few different ways to set up a Terragen planet and think about its coordinate system, and each one will have a different meaning for compass heading. The Sunlight settings have the same problem, but I chose one coordinate system which makes sense for landscapes located at the origin and at the "top" of the planet. I feel that it's useful to stay consistent with the Sunlight controls, so I'd probably want a compass setting in the Surface Layer to work the same way (at least by default). However, this would have strange results if you use it far from the "top" of the planet. At different parts of the planet a different coordinate system would be preferable, but it would not correspond to the sunlight controls.

Perpendicular to the planetary surface will probably make the most sense, so north south east west, up down. ?

**Edit** This isn't an easy question.

[sboerner]

Meanwhile . . .

I was taught recently a far simpler way of masking a side using dot product. Copy and paste below and connect to your mask input. Then adjust the Constant Vector to the side you want.

This works nicely, thank you. Attaching Hetzen's code as a .tgc.

[Matt]

Perpendicular to the planetary surface will probably make the most sense, so north south east west, up down. ?

**Edit** This isn't an easy question.

Yup https://en.wikipedia.org/wiki/Hairy_ball_theorem

We'll always have to choose between at least two coordinate systems if we want this to work anywhere on the globe.

[Tangled-Universe]

It's obvious from this discussion that I'm in favor of the approach similar to the sunlight.
It will support by far the most use cases.
If a new/fresh approach fixes all existing nuisances then that's a win too of course.

[cyphyr]

Could a simple compass function similar to the sunlight one work with a modulator based on the local planet normal?

[Hetzen]

You get gimble lock at the poles.