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.
