The fact that my examples are made with Julia doesn’t mean that you have to switch to reproduce them. GMT.jl is syntax wrapper but at the end is still GMT who do the work. I just don’t have patience anymore for bash scripting and I think any GMT user can recognize the commands and options used.
The example above represents the difference of the two grids created with grdgradient, not an image of the grid itself. But doing it shows that indeed there is something funny happening when the illumination comes from the 3rd and 4rd quadrants. It is known that illuminating from bellow often causes our brain to see a negative, but that it can also influence the perception of the illumination direction is a surprise to me. Or there is bug somewhere. But it’s not obvious because illuminating from 125 has the same effect.
These figs where made with grdimage and a -Iillum.grd computed with grdgradient. (-Es215/10, etc…)
Ah, forgot to answer this. None of the GMT illumination algorithms (or GDAL, or many others) cast shadows. For shadows you cannot escape new tricks, like the Blender example I linked above.
Aha! So, this is the real answer! Grdgradient cannot cast shadows. That would have been helpful to know from the beginning.
Then the description for the -E option is misleading.
To include -E[m|s|p]azim/elev[+aambient][+ddiffuse][+pspecular][+sshine] options in the instructions implies that shadows can be cast.
Since this was a second inquiry (after Kristof’s) along these lines, perhaps the documentation can be adjusted to help others avoid having to go down this dead-end road.
Hmm, I may have talked too much. grdgradient was created at those 90’s that you referred above. I don’t think at that time the modern concept of shadows in computer images existed or was achievable with the computer back than. So the shadows that the man page mention referred to casting bright and shades to create the illumination effect. Now, when people talk about shadows in illumination I interpret it to be images like this
That’s the trap @John_Geodesy and myself fell into. It is just a simple “how is the local surface angled to the light source” without any interaction with surrounding surfaces. And for that it yields pretty convincing results.
texture shading after Leland Brown - currently only available in the Julia Wrapper but it has potential for highlighting terrain features without dropping the “shadow” side into pitch black darkness. You don’t get correct shadows but you get nice depth and border information which can be combined with some traditional hill shading for some nice plots. Maybe this is something for @John_Geodesy as well.
thanks, I played with texture shading. I downloaded and compiled that C code after your instructions and blended the result together with gdaldem’s hilshaded relief using gdal_calc.py. I liked it a lot and even posted some of my spaghetty bash code in one of the more recent texture shading forum threads.
With texture shading it ended up with quite a lot of manual tweaking, suspect similar workflow with the Blender approach. Not perfect for any case, e.g. not for that moon Tycho crater.
As I don’t know what John intended to show this might be missing the point but I find it quite interesting how it emphasises the diagonal structure. Illumination is from azimuth 215°.
The script in Julia:
using GMT
G = gmtread("t.grd");
lelandshade(G, detail=4.0, contrast=4.5, zfactor=25, cmap="t.cpt", azimuth=215, show=true)
The three options detail, contrast & zfactor are your gas pedals to tweak your plot.
Greatly appreciate the extra efforts shared, Kristof. Especially on a Friday! Your latest is close, but the shading in the largest crater still appears to only shade just slightly better than half of the crater.
At a solar elevation angle of 10 to 15°, one would expect most of the crater to be in shade, with just a bit of the NE rim being illuminated. Ray tracing is (I think) what I’m after.
That’s with elevation 10°. Obviously without long cast shadows. I added elev=10 to the command. If you need the cast shadows then raytracing is the way to go.
texture shade with detail=4.0, contrast=4.5 is pretty much a uniform grey image without any visible details. There is no point using such combination imho (or there’s a typo).
Problem is that by “just” calling lelandshade from GMT.lj the user has no way of seeing that parameters of leland texture shading algo were not useful, because the result of texture shading was not shown to the user. By just calling lelandshade the user has no way of knowing whether e.g. lelandshade has been provided with nonsense combination of detail and contrast. These two must be selected manually depending on the plotted reilef.
The best way of tweaking this type of shading is to always plot the color map and texture shade on separate plots so texture shade can be checked visually. This is why my spaghetti code did 6 plots incl the final blend as shown above so the effect of these different parameters is shown and the result can be meaningfully tweaked. E.g. many color maps wouldn’t work well with this shading approach or might need tweaking (like the blue crater spots on the map above does not appear to me as the best way of representing these craters), Z scale exaggeration might need tweaking, % of texture shade in the final blend may need to be adjusted.
PS OK this was the best way I happened to found. If anybody knows better, comments are very welcome.
