Kirkjufell mountain

Started by digitalguru, March 01, 2016, 10:08:57 AM

Previous topic - Next topic

Matt

Quote from: digitalguru on March 04, 2016, 07:09:57 PM
•   This part had me going for a while, I could see the vectors projected on the plane successfully, but I thought I should move to the Plane up in Y so it would occlude the terrain in the final render. But the rendered image didn't match the original terrain.  So I translated the Plane down to 0 in Y and it worked - not sure why! Maybe it's because the Displacement tests against the ground level of the Planet to see what is positive and what is negative displacement, Matt would know more about this one.

When the plane is rendered, its surface position determines the texture coordinates for the shaders it's sampling. Power Fractals are 3D textures, so changing the Y position of the plane will change the texture which is generating the terrain. So the plane needs to perfectly match with the undisplaced planet. For complete accuracy you should just render a planet, not a plane, because of the curvature.

Quote
•   Render was relatively quick, I left Detail and Anti-aliasing to the defaults of 0.5 and 0.3, don't think they are that crucial when rendering displacement for a map, but Matt can correct me on that one.

Personally i would increase the Detail to about 0.8 (or maybe even 1.0) to get the micropolygons to be about the size of a pixel. Otherwise you're not really getting the full benefit of that 4k resolution and potentially producing artefacts as values jump from one micropolygon to the next (because each micropolygon is solid shaded). Anti-aliasing of 3 should be good enough.
Just because milk is white doesn't mean that clouds are made of milk.

digitalguru

Hi Matt,

Thanks for the info! Good to know.

QuoteWhen the plane is rendered, its surface position determines the texture coordinates for the shaders it's sampling. Power Fractals are 3D textures, so changing the Y position of the plane will change the texture which is generating the terrain. So the plane needs to perfectly match with the undisplaced planet. For complete accuracy you should just render a planet, not a plane, because of the curvature.

Thought it might be something to do with that, and I guess on a small-ish patch of 8000m x 8000m the curvature is minimal.
I'll try using an additional planet instead of a plane tomorrow.

QuotePersonally i would increase the Detail to about 0.8 (or maybe even 1.0) to get the micropolygons to be about the size of a pixel. Otherwise you're not really getting the full benefit of that 4k resolution and potentially producing artefacts as values jump from one micropolygon to the next (because each micropolygon is solid shaded). Anti-aliasing of 3 should be good enough.

Ok! So Detail 1.0 = 1 micropolygon per pixel

Even so, rendering at Detail 0.5 produced a much much better match when displacing in Maya than I've seen before, Detail 1.0 should look very good indeed!

Dune

You beat me with your experiments, great job. Good that it works! But do you really need a compute terrain? I do a lot without one, which is much faster (~50%). And if so, how about patch size?

digitalguru

QuoteWhen the plane is rendered, its surface position determines the texture coordinates for the shaders it's sampling. Power Fractals are 3D textures, so changing the Y position of the plane will change the texture which is generating the terrain. So the plane needs to perfectly match with the undisplaced planet. For complete accuracy you should just render a planet, not a plane, because of the curvature.

I couldn't make projecting the displacement onto a planet work, so I used the Lake object instead as that follows the curvature of the planet - works just as well. Haven't tested it on a very large terrain, but I imagine that's where you might see some misalignment.

I've attached a new TGD file for this, and added a render layer for the Beauty render which hides the water object.

QuotePersonally i would increase the Detail to about 0.8 (or maybe even 1.0) to get the micropolygons to be about the size of a pixel. Otherwise you're not really getting the full benefit of that 4k resolution and potentially producing artefacts as values jump from one micropolygon to the next (because each micropolygon is solid shaded). Anti-aliasing of 3 should be good enough.

Tried it at Detail = 1 and it's better, at a minimal increase in render time.

Dune - no, you don't need a Compute Terrain node. In fact, as mentioned, the Displacement to vector should be taken before that node. The test scene I used is very simple and there's no shading going on that needs the Compute Terrain piped into it, I just didn't delete it.

The next thing to test is add small scale displacement further down the tree into the shading group. My approach has usually been to do large scale displacements / terrain sculpting then a Compute terrain - then adding small scale displacements along with shading after that. It will be interetsting to see how that could work and preseve that extra detail. You say you don't use the Compute Terrain node sometimes, are there certain situations where you don't need it?



j meyer

Very interesting experiments. 8)

I'm afraid this does not work with ZBrush, though. As far as I'm aware ZB does not read
vdisp maps it just produces them for export.
If anyone knows a way, please let us know.

Dune

If a slope is not needed you can very well do without a compute terrain. Heights seem to be updated from the first displacement, so that's not the problem. Sometimes a XYZ shader is enough and you can get interesting results using that along the line somewhere (not even need for using its input). Only if you work with blue nodes and get position, that sort of thing, it is sometimes needed. When using smoothing and displacement intersection obviously you do need one.
I am lately trying to get decent terrains as fast as possible.

Matt

Quote from: digitalguru on March 05, 2016, 08:10:15 AM
QuoteWhen the plane is rendered, its surface position determines the texture coordinates for the shaders it's sampling. Power Fractals are 3D textures, so changing the Y position of the plane will change the texture which is generating the terrain. So the plane needs to perfectly match with the undisplaced planet. For complete accuracy you should just render a planet, not a plane, because of the curvature.

I couldn't make projecting the displacement onto a planet work, so I used the Lake object instead as that follows the curvature of the planet

I just tried it with a planet and it works for me. Newly created planets are in a different position from the default scene, and that produces different results, but if I just copy the original planet it works correctly.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

digitalguru

#37
thanks Matt, I'll give it a go

update: yes it does... I made a new a new planet node last time and coped the values from the default - must have missed something somewhere




TheBadger

GREAT!

But this IS very complex, don't you guys agree?

I have to say I'm conflicted on the Vector to Zbrush issue. On the one hand I say good!.. Serves you right for having so much awesome that you need a little suck. But on the other hand, Im like, AH CRAP!.. Needs me to see some work from the Z guys on this.  ;D
It has been eaten.

digitalguru

Are you talking about the displacement map export?

It's simpler now, no need to set up a plane, just copy the Planet node and plug the displacement to vector (or scalar) nodes into that.

Check out the attachment in the previous post.

Matt

Quote from: TheBadger on March 05, 2016, 07:41:53 PM
GREAT!

But this IS very complex, don't you guys agree?

It's not a feature as such, so yes it's more complicated than I'd like. If it were an advertised feature it would have to be simpler than this. I do want to add this as a proper feature in future. But I'm glad TG has the low level tools to do all sorts of things like this (by design).

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Matt

The steps involving Render Layers aren't necessary if you just enable and disable objects by hand.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Dune

I haven't checked your files yet, nor done any experiments, but why would you need 2 planets? Isn't the existing enough? Just unhook the initial line of displacement, I'd say, from my head.

TheBadger

#43
QuoteIt's not a feature as such, so yes it's more complicated than I'd like. If it were an advertised feature it would have to be simpler than this. I do want to add this as a proper feature in future. But I'm glad TG has the low level tools to do all sorts of things like this (by design).

Matt

Looking forward to a refining, Matt. I have opened an old project and started working again because of OP's work. Going to see how much trouble I can cause.

It was already set up for this (started it in TG and built it to be exported). Hope I can get through it. Also going to use it for the VR thing if I can make it work. Only have a couple of days a week now to play, and sadly not even all hours of those days.  :-[

Will prove very useful project going to unreal too, if I can get through the first two softs. Then I will understand in practice how well the free flow pipeline can really work, or not work.
It has been eaten.

digitalguru

Hey Dune,

No reason not to use the original planet, I used the render layers so it could always be setup and you wouldn't have to disconnect and reconnect nodes to re-render the vectors.