mr displacement

[Anonymous]

Hi all,
it's just me going nuts or MR displacement in 6.x is totally broken...
what I mean is this:

try do some nurbs (or poly) surface, put it some bit advanced procedurals texturing (but nothing extreme), and start to tweak the geom approx of the surface, expecially going to Fine - view dependent, and tweak the length, after some tries it just stops doing the Fine displacement in the region and switches to very low displ. setting (like parametric) and after that there's no way to turn it good again, it's just stuck.
I tried all thing, flush cache, reload scene, etc.. nothing happens, sometimes only way is to create a new primitive and assign again the material, but that's nothing useful ofcourse..
Also I'm not going out of memory or anything, tried also split mesh and all, but no results.
ok I stop ranting now:) I hope v7 will have more consolidated stuffs... rendering is becoming crashy... (region+couple of texture viewers and when u close the texture viewer it hangs xsi...for example)

[Anonymous]

what amount of ram do you have?

[Anonymous]

quadcore 4gb... but it does the same with a simple sphere, eating up 300mb at most...

I'm doing a bit more in depth tests now, and it behaves really randomly, something in the logic of the thing is broken.
apply a simple spherical rock procedural to a 16by16 nurbs sphere, then set geo approx to fine, view dependent, and put the length to 2, and max division to say 4, it should render ok.
then set max to 6 and length to 0.5, it should break (break=switch to a very low res), yet if u switch to rasterizer it would render (samples about 16 shading and 4 pixel).

and usually when you switch back to scanline or raytracing it 's still broken, but sometimes instead it works the same as with the rasterizer.... pretty random...
dunno if i'm doing somethin weird...

cheers
val

[Anonymous]

Ok...
now.. or my machine/install is b0rked totally or softimage should check something.. i guess...

looks at this:

no displacement node attached....yet... i've cache flush all on, even if I close region and retry..same result...

[Anonymous]

A while back I did a short videotutorial on quick-rendering displacement from ZB3 in XSI:
community.softimage.com/showthread.php?t=303

It was done in XSI 6.02 and displacement was working just fine. You can try following the steps and if yours doesn't act the same, perhaps it's bugged?

[Anonymous]

Ok...
now.. or my machine/install is b0rked totally or softimage should check something.. i guess...

looks at this:

no displacement node attached....yet... i've cache flush all on, even if I close region and retry..same result...

it looks like that you have applied the displacement to the default scene material and that you didn't applied the one with no displacement to the grid

[Anonymous]

quadcore 4gb... but it does the same with a simple sphere, eating up 300mb at most...

I'm doing a bit more in depth tests now, and it behaves really randomly, something in the logic of the thing is broken.
apply a simple spherical rock procedural to a 16by16 nurbs sphere, then set geo approx to fine, view dependent, and put the length to 2, and max division to say 4, it should render ok.
then set max to 6 and length to 0.5, it should break (break=switch to a very low res), yet if u switch to rasterizer it would render (samples about 16 shading and 4 pixel).

and usually when you switch back to scanline or raytracing it 's still broken, but sometimes instead it works the same as with the rasterizer.... pretty random...
dunno if i'm doing somethin weird...

cheers
val

in you are in view dependant mode that mean the length parameter will determine how many triangle you will get per pixel.
length should to be lower 1 otherwise you are creating a lot of poly that are unnecessary.


For the max subdiv I am following this rule :
If you are using polymesh subdiv don't forget that the result tessellation will be added to displacement max subdiv. if you get a polymesh subdiv at 2 and disp max subdiv to 6 you will end up with a total subdiv of 8 which can be overkilling.
I am simplifying a lot here but I think you get the idea.

[Anonymous]

Harry, the length parameter determines the maximum length of tessellated polygons, so making the number larger decreases, not increases the the number of polys. A value of 1.0 is the equivalent of the diagonal length of a pixel. Increase this value if you have a lot of fine detail in your map, lower it if it tends to be smooth.

I think I've seen something like this a couple of version back, Val. I'd get the scene off to support, have them take a look at it.

[Anonymous]

Absolutely.

By re reading my post I realise that I forgot to write a very important word.

You should have read :

If you are in view dependant mode that mean the length parameter will determine how many triangle you will get per pixel.
length should NOT to be lower than 1 otherwise you are creating a lot of poly that are unnecessary.


Thanks Kim for the correction.

[Anonymous]

hehe .... kind of. if you set this value to one then you're only getting, more or less, one poly fragment under a pixel. Unless you've a very smooth displacement map the odds are good that you'd want to set this value to less than 1.0 if you want to pick up the detail and have it render to a good quality. high frequency details, sharp transitions in value, none of these will look good if you're only sampling one polygon fragment per pixel. You're also chucking away a good deal of the hard work you're doing with your anti-aliasing settings set to sample more than one ray per pixel.

Never, ever advocate absolutes. 😉

[Anonymous]

Hi,
I agree with Kim, length less than 1 is sometimes necessary, anyway, the material is applied to the object, I'm sure about it. I'm getting lots of this displacement hangs in my scenes. I will try to write a script that replicate the error. let's see what happen.

cheers
v.