Hey Fabricio, i'be bumped onto that also, in my case it was the Mesh
Splitting kicking in. It separates dense meshes into separate objects
before passing them on to MR. Therefore, some shaders get artifacts, like
volumetrics and bumpmapping also.

Real headache but easy fix...

Under MR > Optimizations, look for Mesh Splitting Factor, increase the
value up to infinity and be happy :D
Em 19/03/2014 19:20, "Ola Madsen" <ola.mad...@digitalcontext.se> escreveu:

> I can only confirm this nasty little bug as I experienced it a couple of
> years ago. If I remember correctly I managed to get rid of the artifacts on
> some objects by actually tessellating the geometry instead of using to +
> key. Some object still had the artifacts and I had to work around it by
> splitting the scene and rendering the objects in in different passes...
>
>
>
> Cheers
>
> Ola
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Fabricio Chamon
> *Sent:* Wednesday, March 19, 2014 11:05 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Mental ray volumetric shader errors
>
>
>
> ...forgot to say that I'm using "Particle_Volume_Cloud", which used to
> work fine on meshes since always.
>
>
>
> 2014-03-19 18:56 GMT-03:00 Fabricio Chamon <xsiml...@gmail.com>:
>
> Hi,
>
>
>
> I'm trying to do some volumetrics in mray, but the shader is giving me all
> kinds of wierdness on heavy meshes. Have anyone experienced this before ?
>
>
>
> For the sake of simplicity, I have this test scene with only one default
> sphere. If I crank up the sphere U/V subd to 200, it starts to show some
> strange black areas. At subd 300, it renders all flat.
>
> I'm guessing it's not a lookup table cell size problem...tried very small
> values, and the volume renders almost completely solid (when it works).
> here's some images to illustrate:
>
>
>
> [image: Imagem inline 1]
>
>
>
>
>
> I really need dense meshes because I want the fine control over the volume
> silhouette to be on the mesh itself, not through shader trees.
>
>
>
> anyone ?
>
>
>

<<inline: image001.jpg>>

Reply via email to