Hello,
When using an mental ray shader with an miTag for texture input, the output .mi has the texture call but it has double quotes around the filename, resulting in a syntax error. Looks like removing the quotes from the filename in Texture in the MIapi.py fixes this…just for future builds, if possible.
Thanks,
Chris
Found 14 posts.
Search results Show results as topic list.
Technical Discussion » BUG: mi texture output
- drexel
- 41 posts
- Offline
Technical Discussion » mr ccmesh/tessellation
- drexel
- 41 posts
- Offline
Technical Discussion » mr ccmesh/tessellation
- drexel
- 41 posts
- Offline
Hello,
Outputting a polygonal mesh with the mi_rendersubd appends the ccmesh block to the geometry, but the overall tessellation is being regulated by the mental ray ROP. By default this is using “fine length 1 angle 5 all” which goes for the whole scene. (Changing this to grid prevents anything from being put into the .mi, which is a step in the right direction)
However, it would be better not to be specifying a tessellation for the whole scene, rather allowing a per object setting. Unfortunately, applying the tessellation parameters to a Geometry object does nothing in the resulting .mi file.
Even more important is outputting the correct ccmesh tessellation settings, otherwise the ccmesh block isn't really being used correctly.
For example, with a simple cube, the block should be:
ccmesh “name” polygon 6 vertex 24 # {
p 0 1 2 3
p 4 5 6 7
p 8 9 10 11
p 12 13 14 15
p 16 17 18 19
p 20 21 22 23
end ccmesh # }
approximate ccmesh fine angle 5 “name” <—missing
Is there any way to get the approximate ccmesh tessellation appended to the geometry?
Thanks,
Chris
Outputting a polygonal mesh with the mi_rendersubd appends the ccmesh block to the geometry, but the overall tessellation is being regulated by the mental ray ROP. By default this is using “fine length 1 angle 5 all” which goes for the whole scene. (Changing this to grid prevents anything from being put into the .mi, which is a step in the right direction)
However, it would be better not to be specifying a tessellation for the whole scene, rather allowing a per object setting. Unfortunately, applying the tessellation parameters to a Geometry object does nothing in the resulting .mi file.
Even more important is outputting the correct ccmesh tessellation settings, otherwise the ccmesh block isn't really being used correctly.
For example, with a simple cube, the block should be:
ccmesh “name” polygon 6 vertex 24 # {
p 0 1 2 3
p 4 5 6 7
p 8 9 10 11
p 12 13 14 15
p 16 17 18 19
p 20 21 22 23
end ccmesh # }
approximate ccmesh fine angle 5 “name” <—missing
Is there any way to get the approximate ccmesh tessellation appended to the geometry?
Thanks,
Chris
Technical Discussion » Massive RIBs to Houdini
- drexel
- 41 posts
- Offline
Technical Discussion » Massive RIBs to Houdini
- drexel
- 41 posts
- Offline
If you look on the massive community forum, there's an otl I put together for rendering massive sims via Houdini (PRMan). One caveat, I used our edu license, so it comes in as non-commercial…easy enough to dissect though. It'll also load in stand in geometry for your agents for blocking.
Chris
Chris
Houdini Lounge » Queue Poll
- drexel
- 41 posts
- Offline
Use Alfred here to handle Houdini and all other jobs (Maya, Nuke, RealFlow, etc.). And, it was simply because we had Alfserver nodes around and it's really easy to script.
~140 procs.
Chris
~140 procs.
Chris
Technical Discussion » mental ray GI/FG
- drexel
- 41 posts
- Offline
A couple of issues with the GI/FG translation…
When adding GI photon emission to a light, exponent and photon count get correctly passed, but energy is passed as a single float value (true to the nature of the single slider in the parameter), but mr is expecting distinct r g b values for the energy.
Global scene controls for GI and FG seem to be missing, one can add mi_finalgather/mi_globillum and mi_finalgathermode/mi_globillum mode to the object and that gets parsed. But, if added to the ROP, it doesn't add anything to the scene option block, so no GI or FG takes place. (The same .mi rendered with -finalgather on -globillum on command line flags renders as expected.)
RFE: Along with the last point, it'd be nice to have GUI controls for setting GI accuracy and radius, as well as finalgather accuracy, there don't appear to be any rendering parameters for those.
Also, while poking through the generated mi file, it looks like the options in the material instance blocks are being passed twice.
All this happens with 9.1.264, mr 3.6.51, both x86_64
Chris
When adding GI photon emission to a light, exponent and photon count get correctly passed, but energy is passed as a single float value (true to the nature of the single slider in the parameter), but mr is expecting distinct r g b values for the energy.
Global scene controls for GI and FG seem to be missing, one can add mi_finalgather/mi_globillum and mi_finalgathermode/mi_globillum mode to the object and that gets parsed. But, if added to the ROP, it doesn't add anything to the scene option block, so no GI or FG takes place. (The same .mi rendered with -finalgather on -globillum on command line flags renders as expected.)
RFE: Along with the last point, it'd be nice to have GUI controls for setting GI accuracy and radius, as well as finalgather accuracy, there don't appear to be any rendering parameters for those.
Also, while poking through the generated mi file, it looks like the options in the material instance blocks are being passed twice.
All this happens with 9.1.264, mr 3.6.51, both x86_64
Chris
Technical Discussion » mental ray area lights
- drexel
- 41 posts
- Offline
So, it looks like the problem lies in material overrides, rather than per-primitive materials; everything is fine with multiple materials, but nothing happens with the overridden parameters.
Technical Discussion » catmull-clark Subdiv parameter problem mray3.6
- drexel
- 41 posts
- Offline
We're on 3.6.51 here (Linux x86_64), and motion blurred ccmeshes aren't crashing, nor do we get an error message.
Technical Discussion » mental ray area lights
- drexel
- 41 posts
- Offline
In my experience, enabling the “direction” option turns the light into an infinite/directional light source, and so, there doesn't seem to be any difference between that light and a directional/infinite light source.
Absolutely…this was my knee-jerk reaction to a completely unrelated issue (and rusty mi syntax), apologies.
Another unrelated issue has to deal with materials, though. First, when creating a material with both surface and photon shaders, the photon shader is placed first in the material block, so mr seems to ignore the surface. And, when using material SOPs to provide material changes on a group basis, a “# Per-primitive material” line is placed in the mi, but it doesn't seem to respect any material after the initial one.
Sorry for the flurry of issues,
Chris
Technical Discussion » mental ray area lights
- drexel
- 41 posts
- Offline
Is there any way of passing the direction option from area lights to mental ray? This is especially problematic in the case of discs and grids where you really don't want them shooting rays in all directions. Also, as a note, when selecting a disk area light the wrangler passes “disk” rather than “disc” to the mi file, creating a syntax error.
Chris
Chris
Technical Discussion » BUG: mental ray Shadow Map generation
- drexel
- 41 posts
- Offline
It looks like (default) shadow map generation is broken using mental ray, mr throws a syntax error with the resolution (it's being fed x and y, when it expects a single int) and the file name (which expects to be quoted). In HoudiniLightMI.py, lines 178 and 179 read:
if not obj.evalInt('res', now, value):
value =
and should read something like:
if not obj.evalInt('resx', now, value):
value =
and 200 reads:
value =
and should be:
value =
Also, since the optional rendering parameter mi_opt_shadowmap defaults to “on”, nothing gets put in the Option block of the mi, when it should get the option “shadowmap on”. Same goes for mi_opt_shadowmap_rebuild…
Chris
if not obj.evalInt('res', now, value):
value =
and should read something like:
if not obj.evalInt('resx', now, value):
value =
and 200 reads:
value =
and should be:
value =
Also, since the optional rendering parameter mi_opt_shadowmap defaults to “on”, nothing gets put in the Option block of the mi, when it should get the option “shadowmap on”. Same goes for mi_opt_shadowmap_rebuild…
Chris
Technical Discussion » mental ray light shaders
- drexel
- 41 posts
- Offline
Sure thanks, that's how we've always handled PRMan lights…I was simply thrown by the lack of Light Shader (shop_lightpath) in the mental ray Rendering Parameters. (But, of course, it's all the same parameter).
Technical Discussion » mental ray light shaders
- drexel
- 41 posts
- Offline
We're just going through some setup with mental ray and Houdini, and there doesn't seem to be a rendering parameter for Light Shaders. Given, I'm not that familiar with mental ray and Houdini integration (we've been on PRMan for a long while), but I'm used to just to adding a Light SHOP and being done with it.
Chris
Chris
-
- Quick Links