Space Rocks

[Kadri]

Anything animated by accident?  Like the 4d noise for example?

[WAS]

No. Just checked the shaders in play. This is so strange.

There is better colour continuity on some of the masks and stuff. I'm at a loss. Oh well I guess.

[WAS]

Wonder if distort by normal, and warping masks by the terrain is the issue, if so that's sad as you'd think they'd all respond to the final position call.

[Dune]

You wrote you had a final transform set to world. I immediately thought that might be the problem. Or any XYZ shader? It secures everything in place.
Just woke to see this thread again, and it looks very good as a still, btw. I liked the 'glowing' version, but indeed, the blacked out one is probably more realistic.

[WAS]

There is a redirect shader, indeed. It is the second shader which varies up the base planetoid displacement. Then the Compute Terrain. That has a patch size of 1000.

[WAS]

I tried with no redirect but hmm, still same deal. Some shaders just act in final position and won't rotate, without there being any transform shaders (except the last for rotation), or craters using Get Position (instead of Get position in texture which does allow rotation)

[Matt]

1. Tex Coords From XYZ will need to be disabled (there are two of them). They wipe out the transform on the shaders that follow.

2. There is another problem which I haven't figured out yet, but I've narrowed it down a little.

The following works:

 - Connect the craters layers directly to Base Colours
 - Disconnect the input to the craters layer

Something in the input to the craters layer is causing the transform to be lost. To narrow this down further you could reconnect those inputs one until it breaks.

[WAS]

Texture coordinates is probably no biggy. I never honestly inspect the differences often, just hope it "understands" the terrain better.

As far as the craters, that is strange. Is it the repetition of the phases utilizing the transform shaders? None of the transforms use world space, but I have noticed doing "scales" like this in steps does slow things down significantly if what you are working with is complex, which is why I rebuilt for this setup exclusively because my other procedural craters with ejecta and all that is extremely slow. I wonder if it could be the bias part of the craters (which is why they kinda look weird as the terrain moves). I did notice with other shaders with info below/above 0/1 it will clamp the data forn some reason.

[WAS]

So I did some tests, I disabled the craters and the texture coordinates but I still see a lot of rolling textures and displacement from the surface shaders. Do notice the area that exports bad with the micro exporter does have issues in TG too without the craters and texture coordinates. So must just be a disp issue and can try diff seeds or something.

[Dune]

Can't tell much more without a file, but I guess Matt's on top of this.

[Matt]

3. There's also a Compute Terrain which will need to be disabled.

4. Redirect Shader displaces along world spaces axes, so that won't be rotated.

5. Using the planet's built-in rotation will produce better results than the transform shader because the micropolygons will move in sync with the textures.

[Kadri]

Hi Matt. I had in the past problems with the planets build-in rotation-moving.

Are there sometimes cases with some nodes that this doesn't work and with other combinations we get then and now problems too?

Would you agree if i said we need some kind of better-easier working as intended related to other nodes (not sure how to write this better hope you understand) when moving rotating objects, textures, shaders etc.?

[WAS]

3. There's also a Compute Terrain which will need to be disabled.

4. Redirect Shader displaces along world spaces axes, so that won't be rotated.

5. Using the planet's built-in rotation will produce better results than the transform shader because the micropolygons will move in sync with the textures.

Ah, so in other words this is all broke...

I have to sacrifice every defining aspect of TG making a nice surface. Seems buggy. A gray block is definitely not an asteroid xD

I can't even see all these bugs making a good real-world planet to spin without using just height and color image maps. In which case TG isn't doing really anything special but the atmosphere node (compared to other applications; though Blenders atmosphere mocks seem very good)

[Matt]

No it's not all broken. "A gray block?"

You can retain almost everything that makes your asteroid look the way it does.

I think all you need to do is disable the Tex Coords from XYZ nodes, replace Compute Terrain with Compute Normal, and do something different in place of the Redirect Shader (e.g. a vector displacement with a rotated vector) if it's necessary for the look. Please give that a try before fearing the worst.

It would be great to have some way to rotate these displacements globally and I'm thinking about how I'll do that. It is not simply a matter of changing the texture coordinates, which is all the Transform nodes are designed to do.

[WAS]

I meant "gray blob".

I got some ideas, but when I disabled all that stuff I was still having issues with all the surface stuff with it's masks.

Also for the redirect wouldn't you just rotate each channel before applying the redirect? Not sure how it works exactly. But since this is just on X would using a scalar, and rotating that accordingly before applying to the redirect work? What about the warp input and a vector disp on X?