View Full Version : Nodes: Normal Direction Surface Displacement

03-08-2007, 12:03 PM
I don't seem to recall having this problem before. Yet in this example the procedural texture (Crackle) seems to be displacing along a vector.

I am displacing using the surface nodes.

If using the object displacement, I know how to hook it up so that the texture displaces along the surface normals, however I don't know how to set that up using the surface nodes.

In using surface displacement in the past I was testing on cubes, sheres and planes. I never had this issue.

The texture below seems to be heading in the direction of the arrow and not displacing evenly like it would on a sphere or Cube. To be sure, I tested this with a brick pattern and got the same result so this is not due to the texture postion or center and the size is set to smaller than the surface anyway.

Anyway to solve this?

I suppose I could use weightmaps on the object displacement but it seems so much simpler to do it on a surface by surface basis, as I want to control each portion of the object.

03-08-2007, 12:26 PM
Since a sphere object has all normal directions,
it is a good example to compare node vector displacement for
object and surface scalar displacement.
With a 3D procedural you will get exactly same
effect directly input its alpha in surface editor displacement
(with a 1m distance in Bump),
and used it as scale factor (Math Vector Scale) for scaling the "Smoothed Normal" of the spot for displacement editor,
and this is a Normal displacement in both case.

Did you use a subdivided object? could you post it?


03-08-2007, 01:23 PM
When I set up a vector for the surface it does not seem to do what I expect.

It is a pretty big object, so you might want to load it up in the scene which has display subpatch to 0 and APS set up.

The surface you want is "Planetinner"

03-08-2007, 02:23 PM
Interesting model really...
I don't think there is a problem with your surface displacement,
(along normal as it should does)
but may be something related with uniformization of poly areas,
polygon on top of image are bigger than extremities and
even with "Per Object Level" set to 6 they don't get
efficient procedural displacement, sorry but can test
more APS setting with my RAM here.

(You have also polys with more than 4 points in Subpatch mode, I tripled them and flipped some polys)


03-08-2007, 02:49 PM
I am using CC for subpatch. No need for tripple.

I thought to discredit the mesh issue but forgot, I have all ready done tests on the uniformity of the mesh and that is not the issue. In open GL, the mesh willl deform based on poly density but not on a render.

Here, the model is rotated 180 degrees IN MODELER and then I rotated it back in layout to show that the side that was once smooth is now displaced.

This proves it is not a mesh issue but it is choosing a vector to displace the surface.

Like in this video here:


But in this video the displacement is on the object. For some reason I am getting the same effect on the surface, yet, with a sphere or cude it does not do this.

03-08-2007, 03:07 PM
Ok for CC, ok uniformization was a comment
about my own sample.
But I spoke also about APS setting, here is a comparaison
between Object Level set to 6 and Pixel per Poly set to 1:
43558 43559

But to clarify this, we should render the wireframe.


03-08-2007, 03:14 PM
A better angle.

Also an explanation:

The intent is to create 3 areas of displacement:

1) the planet surface

2) the planet top rock layer (edges along the top just below the surface)

3) The inner planet surface.

I have set up 3 surfaces for this so I can controll the displacement for each area of the object wihout having to try and split up the displacement on the object using weightmaps which will be mush more complex to set up.

Pics 2 and 3 only difference in surface is a 90 degree rotation in modeler to make the surface match up with the vector that is being displaced in layout. In those two images the same settings were used on the crumple texture.

03-08-2007, 03:19 PM
Sorry Did not see your post.

But do you see what I mean now? Those last two pictures are very revealing as to the problem. Is there a way to control the vector on the surface node displacement?

03-08-2007, 03:24 PM
I don't think we could compensate such issue in
displacement but I'm not a specialist for APS.

So if there's a normal polygon issue, this could be related
to CatmullClark through the APS system, may be a more simple model
like a CC sphere compared to a Subpatched Sphere?


03-08-2007, 03:49 PM
You are right.

CC sphere is one direction, but the front looks way better than the subd front. :)

This is not good. What now?

1) SubD Sphere 2) CC sphere 3) CC sphere backside

03-08-2007, 03:52 PM
SubDSphere backside.

03-08-2007, 06:31 PM
OK, That was odd. What happened to my post?

And its the twilight zone as it is back again...

03-08-2007, 09:59 PM
Sorry but I seem to be having brouser problems. Recent posts only show up if I post again and things are all haywire here, threads missing etc.

03-21-2007, 11:53 AM
the reason that the cc sphere looks "better" is because it has many many many more subdivisions. Check the render status panel and you'll see.
CC subdivides in a exponential fashion (each polygon splits into 4 for each subdivision so a cc subdiv of 4 means 1*4*4*4*4 = 256 polys and a cc subdiv of 7 means 1*4*4*4*4*4*4*4 = 16384 polys) while subpatches subdivide in a linear fashion (each polygon splits into the number you choose in both U and V directions, so a regular subpatch division of 4 means 1*4(U)*4(V) = 16 polys, and a subpatch division of 7 means 1*7*7 = 49 polys)
As for the vector issue, I don't have a clue. It has to be something with the way Layout handles CC geometry...

03-21-2007, 01:10 PM
Interesting info. Thanks. Seems that the best have been stumped on this one. Still not sorted out. I had to make the thing into a subd object.