RiCurves and other Renderman Questions

[neuromancer1978]

Wow! Not a bad tree though. A large RIB is not too uncommon in the industry, I read some where during the new StarWars movies that ILM would often have 1 GB ribs for the droid armies. But that is ILM.....

Anyways, seems like what you want to do is procedural modeling of the leaves. I wouldn't begin to tell you HOW per se but I do have links...

http://www.fundza.com/
http://graphics.pixar.com/library/ look for Stochastic Simplification of Aggregate Detail (http://graphics.pixar.com/library/StochasticSimplification/paper.pdf)
http://www.renderman.org/RMR/Publications/sig01.course48.pdf

(you can also check out the rest of renderman.org for info on that)

You have the right idea but in this case it would be better to have each clump as it's own rib file, instead of one large rib. That way RenderMan can just call on the next one when it needs it as opposed to rendering the entire leaf rib file at once. I cannot say that rendering will be instant but I am pretty sure your render times will decrease this way. Just to clarify it can work with either polygon or curves (hair) - for that matter anything that RenderMan can render can be a procedural model. With RiCurves you can simply use NURBS or Bezier curves, and again using procedural modeling assign objects as the leaf object rib - RMan will then call on the leaf rib (you can have several types for variety), and then render that bucket(s) till it is done, call on the next and so on and so forth. However by using AO, that will greatly increase rendering times no matter what method you use. You can always do fake AO using spotlight depth mapped shadows too though.

Hope that helps

[2stepdmb]

Regarding displacement attributes should be saved in the Maya file, which attributes are you talking about? The displacement bound and displacement space attributes should be saved into the file, if not then it's a bug.

I just tried this with RMS2/RfM3 and it works as expected for me.

Ian

[rendermaniac]

You should definitely use some form of delayed geometry reading. How many variations do you have? (apart from scale and rotation which can be added later). If you have just a few then a simple way of doing this is exporting the geometry as RIB archives. Make sure the geometry is centered at the origin and that the transforms are frozen.

You can then read the geometry in with a preShape MEL script which calls RiProcedural "DelayedReadArchive" (run RiProcedural -help for the actual arguments). This can be called from a MEL function so you can choose random archives, add random rotations, or pick up attributes from nodes etc.

You can make this faster by reducing traffic to disk by using inline archives. This doesn't need a lot of extra work. You need a FrameBegin MEL script which adds the lines to to RIB file:

ArchiveBegin "archivename"
##include "filename.rib"
ArchiveEnd

If you keep the inline archive name the same as the name on disk then you do not need to change the ReadArchive calls. The double # is important as this dumps the RIB into the file during the render.

Otherwise if the needles are unique then you would want to use an RiProcedural "RunProgram" to generate the curves at runtime. This only gets expanded on bounding box entry - like Delayed ReadArchives. Fundza is definitely the best resource to work these out.

Whatever you do it is probably worth turning transmission off on the needles. A simple darkening towards the root would probably do fine, or bake the occlusion and read it in during the render. Baking to textures in Mental Ray will give you less headaches if going down this route. RenderMan deep shadows should help too - as already mentioned.

Simon

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.