Feature request: Rotate textures via lat/long

[bigben]

Dear Matt

Please save me from TOS (Trigonometry Overload Syndrome, https://youtu.be/oep4mRpmrkQ)

Being able to set the lat/long of the apex of the planet is really useful.
Being able to rotate and translate textures with the planet is also great.
But mix a global GEOTIFF DEM with a spherical image map and you have to calculate the rotation required for the image map to match the lat/long at the apex. 

The default spherical map is equivalent to lat/long 90,0 at the apex. IMO it would be really helpful if, when "Rotate textures with planet" is selected, the rotation of the image map (at least any image map with spherical projection) is first matched to the lat/long of the apex. This may then require a second rotation of ALL image maps is a X,Y,Z rotation is also specified for the planet. Does this sound practical?

[bigben]

Should have added this to the first one. 
As we can't link to an input for the transformations, this calculation has to be done outside of TG at the moment and then pasted in.
e.g. http://gis.stackexchange.com/questions/10808/lon-lat-transformation

[Matt]

Have you tried the Geog Image Map Shader? It responds to changes to the planet's lat-long settings, and it can be set up to map a single image to the whole planet, just like the Image Map Shader, but there are a few non-default settings.

Auto georeference from file: OFF
Reproject on the fly: OFF
Load method: Terragen (may or may not be necessary)

The lat-long coordinates you need are in the screenshot below.

[attach=1]

I've also attached a clip file.

"Rotate textures with planet" is designed specifically to rotate textures by the rotation parameter of the planet. It wouldn't be right to overload this with the lat-long settings. But it might be good to have another option which does do this.

Matt

[bigben]

The geog image map shader has a habit of losing one hemisphere with a full sphere image and doesn't work with greyscale images (haven't tried greyscale for a while).  I'll have a go with those settings tonight.  Yeah, I can't wait that long, who am I kidding.  I wouldn't have changed reproject on the fly in the past and this helped, although I also had to Flip Y. There's also something funky happening with the translate textures with planet.   [edit] See children....  uncle Matt said "Load method: Terragen" and I didn't listen    I'll leave the images as a lesson.

[bigben]

PS... Loading greyscale is working    Georeferenced images it is then. That will simplify things a lot. 

[Matt]

I'm glad that worked

It looks like you'd benefit from hitting the ']' key a couple of times while the 3D Preview has focus. This will increase the near and far clipping distances and allow your background sphere to draw properly. This is only necessary on some computers though.

Matt

[Matt]

Flip Y seems to be necessary with the GDAL loading method, at least with some file formats. If you change it to Terragen, it shouldn't be needed.

Matt

[bigben]

I'm glad that worked

It looks like you'd benefit from hitting the ']' key a couple of times while the 3D Preview has focus.

Sooo much better in the preview.

Unfortunately there does appear to be something funky happening with Translate texture with planet.  I put a surface shader below sea level for reference. No difference between load methods.

[Matt]

Unfortunately there does appear to be something funky happening with Translate texture with planet.  I put a surface shader below sea level for reference. No difference between load methods.

Do you need to have that checked? Translate is going to move the texture, so if it's right when it's disabled, it'll be wrong when it's enabled.

If you do need it checked to make other shaders move along with a moving planet, then you can disable its effects on the geog shader (or any other shader) by connecting that shader through a Transform Shader or Transform Merge Shader with the "Use world space" option, causing it to forget any translation applied by the planet.

Matt

[bigben]

I wasn't expecting to do that myself, and I suspect most people wouldn't be moving the planet but it may be used by some for animations.  I'll have a look at those settings and add some notes in the docs for the model.

"Rotate textures with planet" is designed specifically to rotate textures by the rotation parameter of the planet. It wouldn't be right to overload this with the lat-long settings. But it might be good to have another option which does do this.

Matt

OK, so in switching all of my image maps to geog image maps, the main method of rotating the planet for an animation would be via the lat/long at apex.  There would still be a need to rotate textures with the planet, but as you say, using both lat/long and the planet's transformation gets messy. 

An option to rotate textures via the lat/long at apex setting may be the simplest. Checked, the rotation of textures matches the rotation required for the lat/long at apex, overriding any rotation values in the planet node. Might be good to have it toggle with Rotate textures with planet so that the user gets a queue that you can't have both (after a few retries ) Does this sound sensible?

[TheBadger]

Wouldn't it be easier to animate the camera around the planet to give the effect of a rotating planet? Based on this conversation here, I would say that is a lot easier than figuring out all the things you are trying to do here. Just comp in a background in post and you got a rotating planet.

On the other hand, the more you think about it, the more you may figure out how to everything in TG more easily. So...

I guess the ideal would be to have the planet behave naturally. To do all that can be done with it in the easiest way regardless of user level (more or less). But reality rarely meets the ideal. So..

I hope you can make it "perfect". But if not, my first lines above are a possible work through.

[bigben]

You can keep the planet stationary and move everything else around it but it does calculating camera orientation can get very tricky e.g. Down here in Australia, Y is down(ish), not up, and flying to the west Over Melbourne I'd have to roll the camera 37 degrees to keep the horizon level.

Rotating the planet doesn't rotate geog image maps or DEMs, just as changing the lat/long at apex doesn't rotate textures. To move both together would preferably be done by using a single rotation mechanism. In the short term it will be easy to either keep the planet stationary and move everything around it or use 90 degree increments for one of lat/long at apex, for which 3d rotations are relatively easy to calculate because you're just swapping one axis

[ajcgi]

Hey guys,

Was there any progress on this? I'd like to be able to rotate MOLA data to different positions for different scenes, in an ideal world without going via Global Mapper.
The ultimate aim is to get certain pieces of the Martian landscape to be at the north pole to lessen camera issues, lighting differences between shots, etc, plus it might make Daniil's erosion plugin a simpler affair to use.

Alex

[Oshyan]

The MOLA shader hasn't been updated in quite a while, so unfortunately the above limitations are still in place as far as I know.

- Oshyan