Mantra, subdivision and bump map

[thinkinmonkey]

Hello all,

I'm rendering a simple mesh with Mantra Surface: the material has a diffuse texture and a bump texture.

So if I render without subdivision or with a SUBDIVIDE sop (with Mantra-compatible Subdivision put on), I have these results:

That are was I'm expecting.

Now if I bypass the SUBDIVIDE sop and I use POLYGONS AS SUBDIVISION GEOMETRY OUTPUT under RENDER->GEOMETRY tab, I have this result:

As you can see, there's no more bump on the wrecking ball. How is it possible?

What I'd like to know too is what's more performing in terms of subdivision/render time for Mantra, if a SUBDIVIDE sop or the option in GEOMETRY tab.

Thanks in advance.

Edited November 25, 2011 by thinkinmonkey

[Fabiano Berlim]

They are different.

Turning on the "mantra subdivision surface" on geometry tab, makes mantra dice your mesh to the size of a pixel in render time. Of course this is controlled by a parameter, so you can make more or less polygons per pixel. Peter Quint have an introductory tutorial about it: http://vimeo.com/channels/54102#7612064

While the subdivide sop is "what you see is what you get". The "mantra compatible subdivision" is just to round polygons the same way mantra does when dicing. For example: If you want to use point clouds in render time, and you know that later on you will dice the mesh. It's a good idea to put a subdivide with "mantra compatible subdivision" turned on, so both shapes match.

About your problem with bumps. I don't have the same problem as you do. Please post the file.

[thinkinmonkey]

Hi Fabiano,

sorry for my answer so late, but I had a very hard weekend.

Anyway, this is the wreckin ball with the bump map:

As you can see, you were right and I was wrong, I mean, I had to put a bigger value (more than -0.1) for the bump in order to see something on wrecking ball when subdivide by Mantra (the last one) compared to the first twos.

I'd like to know why the last row of wrecking balls show a strange effect of bump map, i.e. it seems Mantra renders bumps only on very lit surface.

The scene file is downloadable here: http://www.sendspace.com/file/r11cue

Thanks in advance.

[Fabiano Berlim]

Oh! Nice! I would say that's almost a bug in the mantra surface material.

For the sake o customization they led normals from geometry plug in the 'displace along normals'. That forces mantra to pick normals from geometry, instead of the normals from micropolygons in render time. So you could use your own custom normals. But it may cause more problems then solutions.

To fix that you can go inside the wreckingBall shader in shop. There you will find a network box called "bump", on the top left corner. Just unplug the "globalNNormalBumpMap" from "displacenml2". Now everyhing will look the same!

The solution: wreckingball.zip

I think the idea of this shader is to use bump maps with "non-mycropolygon" geometry and displacements with "micropolygon" geometry. But, since you can do anything in Houdini, it's not very easy to manage all the possibilities.

I am not very fan of uber shaders like "mantra surface". I would advise you to make your own shaders, especially the simple ones.

Cheers!

[thinkinmonkey]

Hi Fabiano,

thanks for your solution, it works!

According to your suggestion, I wrote the simplest shader I could have, so I made this shader, but I have a strange effect:

As you can see there are those grid lines visible in SHADER VIEW and in render.

If I use a simple texture, like this one, it changes a lot:

What am I doing wrong?

wreckinBallShading.zip

[Fabiano Berlim]

Your bump is too strong. When you using bump only is hard to see how much is it affecting your normals. If you turn on the displacement (by pluging the position and turning off "bump only"), you will see how big it is. Don't take too much in consideration the shader view. It's a good openGL to look like mantra. But is not mantra.

I change a bit your shader and put micropolygon render instead of raytracing. It looks better to me now.

You need to take care with color space and ranges. But this is out of the scope for this thread.

Cheers!

wreckingball.zip

[thinkinmonkey]

Thanks again, Fabiano.

Using displacement to "debug" bump is very sly.

The POW and SUBCONST SOPs you used aren't really clear to me, I mean, I see they reduce the texture strength, the shapes of wrecking ball with and without displacement are very similar in size and displacement is very predictable, I think they have to do with the color space and ranges you are talking about and they are out of my knowledge... for now.

Why does the most simple thing in CG like using a displacement/bump texture become so elaborate in Houdini?

[Fabiano Berlim]

Why does the most simple thing in CG like using a displacement/bump texture become so elaborate in Houdini?

Well. Houdini is very precise and easy to guess.

First you need to take in to account that houdini use zero as no displacement.

(Some software use the mid-grey, so 0.5.)

You can also do negative texture values.

(I don't know if photoshop can do it. No matter what software you use, negative values will be displayed as black.)

Knowing that, is easy to guess the rest.

If your texture value is 1. Mantra will move the position of your surface in one unit. The same happen if your texture value is 0.5.

The problem start to happen if your displacement texture is in sRGB space. The 0.5 unit in linear space will be 0.73535 in sRGB space.

Since sRGB is very similar to a gamma 2.2, you can do the oposite with using pow 2.2 and transform your sRGB texture to linear again.

Cheers!

displace_measure.hip

[3dbeing]

That's great info Fabiano, i never thought about the srgb cuasing these subtle errors..

For the next level of recursive problem solving, one can create a lut via chops to pre-filter the image...

[thinkinmonkey]

Fabiano,

I didn't know that was a problem (sRGB <-> Linear), never worried about it, now I'll give it more attention.

Thanks again for the explanation and thanks a lot for the file.