Slope restrictions are an essential part of controlling placement of shaders in Terragen.
Wouldn't it be handy if we could have a similar tab in the surface layer that is based on compass heading? It would make it easier than it is today to correctly limit shaders to the side of mountains for example.
I know there are already ways to make north, east, south and west restrictions. But they are quite cumbersome and intricate (at least to me).
Is this perhaps something Planetside could consider adding?
Regards
Robert
+1, this is quite an important factor in nature.
I'd also love to have an easier way to do this, it would be a great addition to the distribution shader.
That's actually a great idea.
I wonder how hard of a hit on the shaders it would be. I think because this is a planet, it would have to be in XYZ, lat, long and heading.
Thanks for your replies.
WAS: I guess that most of the time (when your working on local terrain at the planet´s apex), everything pointing in the Z-axis´s positive direction would be considered North. But on a planetary scale, Y-axis is the one pointing North. At least I think so, sometimes when I think about this I get all confused...Which is the reason I´m wishing we could have a simple tab for this, so that I don´t have to have a brain meltdown... ;)
I have no idea how hard it is to implement or if it will slow down shaders. But I do think it would be a welcome addition and facilitate easier restrictions of shaders. I´m thinking for example of the problems we have with trying to do rectangular/square rocks. A compass shader/tab would make it much easier to mask differently facing slopes according to their compass heading and correctly project different shaders to these slopes.
On a nearby subject I also have another suggestion or wish. I wish we could choose to project image maps perpendicular to the face normals of the terrain. As the normals change with a rolling terrain, so the projection would also change so that the image is always projected "flat" on to the ground, regardless of slope etc. If I remember correctly this was possible in 3d Max when I used it years ago. I wonder if it´s possible to have the same ability in Terragen?
Best regards
Robert
Don't know whether if it's really that hard like really needing lat/long correction etc...I don't think so actually (more on that in the 2nd paragraph).
The kind of calculation involved is similar to slope restriction calculation, which a certain relation between Y and X/Z axis.
A restriction by 'heading' would be the relation between X/Z.
If there needs to be any kind of correction for lat/long and what not then it's probably already built in TG if you look at the possibilities/limitations of current altitude/slope restrictions.
With that I mean that things are not perfect now with regards to slope/altitude restrictions far far FAR away from the origin, but in the past 14 years on these forums 99% of the post involving these discussions are about how to deal with stuff close to the origin. In other words, the lat/long corrections, even if necessary, is of minor importance if you look at the history of discussions/requests.
Long story short, I like this idea and my kind of layman's view tells me it's not impossible or a huge undertaking, we would just have to ask kindly :)
As you said, there are methods already, but no 'easy heading' shader. Maybe a loose shader would do just as well as incorporating it in surface shader and distribution shader. What it should also have is the ability to choose for bigger patches; whole mountain ranges, not every nook and cranny that's facing a certain direction. And preferably without need of a compute terrain :P
Quote from: Dune on February 11, 2020, 07:25:30 AMWhat it should also have is the ability to choose for bigger patches; whole mountain ranges, not every nook and cranny that's facing a certain direction.
Yes Dune, that's what I think too. Perhaps the user could choose a "sample rate" of the underlying terrain. Regardless of what the "compute terrain" is set to.
Quote from: Tangled-Universe on February 11, 2020, 05:41:12 AMLong story short, I like this idea and my kind of layman's view tells me it's not impossible or a huge undertaking, we would just have to ask kindly :)
Let's keep our fingers crossed that Planetside are reading and are able to perhaps fulfill our kind request... ;)
Quote from: Dune on February 11, 2020, 07:25:30 AMAs you said, there are methods already, but no 'easy heading' shader. Maybe a loose shader would do just as well as incorporating it in surface shader and distribution shader. What it should also have is the ability to choose for bigger patches; whole mountain ranges, not every nook and cranny that's facing a certain direction. And preferably without need of a compute terrain :P
I did not refer to any available method, actually. I referred to that the underlying calculations for slope restrictions are of similar nature to calculating the direction in which a normal is pointing.
Thus suggesting that a 'heading restriction' function should not be too complicated to develop. Ultimately that's for Matt to conclude of course, but for now I don't see how that would be so much work.
Slope/Altitude restrictions also apply to each "nook and cranny" so as a start a heading restriction function would work in very similar ways.
Given how the intersect underlying mode of displacement intersection works with smoothed versions of the terrain, I think a similar approach could work for calculating an average 'heading' of a patch of terrain.
If you know how to create a heading mask with blue nodes then it's actually possible to incorporate a patch size function as well.
You would simply need to warp the get function for X meters, where X is your patch size, and then average those.
I did this once for a convexity selector I made. Convexity applies to slope changes, so the same approach would work for 'heading'.
Down the line it's all the same, just on different axes.
Quote from: Tangled-Universe on February 11, 2020, 11:33:27 AMI did not refer to any available method, actually.
No, sorry, Robert did in his first post. I was referring to his text.
Quote from: Tangled-Universe on February 11, 2020, 11:33:27 AMYou would simply need to warp the get function for X meters, where X is your patch size, and then average those.
Can you elaborate on that? I fail to see how warping would work, and how it could be done in TG. It would be cool if the smoothing filter would work on that, btw.
Well lat/long/head would just be a representation of XYZ in 3D, so not sure what you're exactly on about. The issue is for proper compass-based heading, it will be isolated to that heading and lat/long, and no where else, on the globe or otherwise. Otherwise you're best just using directional masks that will work globally off XYZ and wouldn't actually be a compass-based setting.
That being said, the current directional masks aren't exactly fast when you start using a few of them. Enter my comment. Matt doesn't seem keen on adding things that may be slow from past discussions on ideas.
Combining this idea with roaming the planet, such as real-world data, this would need to be actual compass-based in lat/long/head to work realistically across the globe, otherwise just firing a slope north-east (based on 0,0,0 and XYZ) isn't going to work elsewhere and would be erroneous.
You'd think since the Slope Limits do in-fact work globally, that you'd only add a feature like this that also works globally and correctly.
The psuedo-idea here seems could be handled another way, like a Distance Camera sort of shader to paint slopes/faces it sees for more localized effects, using it's own internal viewport angling as directional masks.
Quote from: WAS on February 11, 2020, 01:23:09 PMWell lat/long/head would just be a representation of XYZ in 3D, so not sure what you're exactly on about. The issue is for proper compass-based heading, it will be isolated to that heading and lat/long, and no where else, on the globe or otherwise. Otherwise you're best just using directional masks that will work globally off XYZ and wouldn't actually be a compass-based setting.
I think that is actually what I said about XYZ in 3D.
Furthermore I meant to explain how calculating heading should not be so costly or more costly than calculating slope. It's the same principle, mathematically, only on different axes.
Call me dense, but "north" is just a set of
Quote from: WAS on February 11, 2020, 01:23:09 PMThat being said, the current directional masks aren't exactly fast when you start using a few of them. Enter my comment. Matt doesn't seem keen on adding things that may be slow from past discussions on ideas.
Yeah node-based solutions are slow. A blue node based slope mask would also be slow, yet it is pretty fast as it is implemented into the surface layer.
Any node-based conconction will run faster once it's converted into a C++ coded shader in TG's library. For example: easy clouds
Your final conclusion is not really correct in that sense.
Matt has to carefully plan his efforts, has his own ideas and has to deal with our requests/wishes.
In that sense it's probably more about bang for buck principle and as far as I know he's also not keen on cluttering the UI with many controls or other overwhelming features.
The reason I think this request is viable is because it touches upon something you can observe widely in nature itself and TG lacks simple control over that.
Quote from: WAS on February 11, 2020, 01:23:09 PM1) Combining this idea with roaming the planet, such as real-world data, this would need to be actual compass-based in lat/long/head to work realistically across the globe, otherwise just firing a slope north-east (based on 0,0,0 and XYZ) isn't going to work elsewhere and would be erroneous.
2) You'd think since the Slope Limits do in-fact work globally, that you'd only add a feature like this that also works globally and correctly.
3) The psuedo-idea here seems could be handled another way, like a Distance Camera sort of shader to paint slopes/faces it sees for more localized effects, using it's own internal viewport angling as directional masks.
1) Like I said before I think "roaming the planet" is a minor use case. I'm sorry.
I'm definitely not the one to call the shots(!!), but if I were Matt I'd look at use cases of TG and choose to develop features which are of use to as many users as possible.
In the many years here I haven't seen many "planet roamers" and the vast majority does their stuff around the origin.
2) Yes indeed, see my previous post.
3) The "localized effects" confuses me a bit. Do you want a planet-wide solution or something "local"?
Or do you mean if global is too hard/slow/whatever that a local approach may work for you as well?
For camera based approaches you need to shoot additional rays into the scene, so I'm not sure whether if that would be the preferred method.
Using my analogy that the heading calculations are very similar in nature to calculating slope I think that the surface layer shader may be able to calculate heading along with slope. See it as a cheap happy by-product of already having your surface values calculated for slope, then you can also use that calculated values for a different type of calculation without going all over it again.
Shooting camera rays sounds more costly to me + when animating a flying camera you will notice the areas which are occluded by the heading mask camera. A surface layer type of function would avoid that.
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.
<terragen_clip>
<dot_product
name = "Dot product 01"
gui_use_node_pos = "1"
gui_node_pos = "-200 380 0"
gui_group = ""
enable = "1"
input_node = "Get normal in texture 01"
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
input_2 = "Constant vector 01"
>
</dot_product>
<constant_vector
name = "Constant vector 01"
gui_use_node_pos = "1"
gui_node_pos = "-100 440 0"
gui_group = ""
enable = "1"
input_node = ""
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
vector = "-1 0 -1"
>
</constant_vector>
<get_normal_in_texture
name = "Get normal in texture 01"
gui_use_node_pos = "1"
gui_node_pos = "-280 440 0"
gui_group = ""
enable = "1"
input_node = ""
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
>
</get_normal_in_texture>
</terragen_clip>
Curious! Thanks Jon!
Quote from: Tangled-Universe on February 12, 2020, 10:52:47 AMLike 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.
Quote from: WAS on February 12, 2020, 12:29:39 PMQuote from: Tangled-Universe on February 12, 2020, 10:52:47 AMLike 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.
Quote from: Hetzen on February 12, 2020, 01:04:14 PMEven 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.
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.
Thanks Jon, will have a look!
Quote from: Hetzen on February 12, 2020, 01:33:00 PMWhat? 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.
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'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.
Quote from: Matt on February 12, 2020, 01:54:23 PMOK, 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.
Quote from: Matt on February 12, 2020, 02:07:17 PMI'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.
Meanwhile . . .
QuoteI 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.
Quote from: Hetzen on February 12, 2020, 02:33:37 PMPerpendicular 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.
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.
Could a simple compass function similar to the sunlight one work with a modulator based on the local planet normal?
You get gimble lock at the poles.
Ah yes, true.
Gimble lock is a royal pain but since it is not needed at the poles simply turn of normal modulation if normal equals zero (or whatever value the poles return).
Not really, because you still have to blend between the two coordinate spaces somewhere. And when you do, you either gets twists (see the hairy ball theorem) or you blend between two results which might cancel each other out.
Thank you Matt, for giving your thoughts on this. From my user-perspective the "sunlight-style" controls makes sense and would probably suffice 99 percent of the time, even if it's "local" to the top of the planet. But of course it would be great if there were also the option for a globally functioning compass. ;)
Thanks again!
Cheers
Robert
I would still need a map with a big red arrow.....YOU ARE HERE! ;D