Best modelling method for prman?

[erakesh]

Maya - Modelling, Animation
Renderman - Texturing(shading), Rendering

[mayax]

Nurbs is rendered the most fast.

And Subdiv is more smooth than pure polygon.

I feel polygon is very slow, especially while using displacement shader.

I think character model should use subdiv.It's smooth ,and can be coverted from polygon directly.(You can use it as a rendering-time polygon smooth operation)

But subdiv is slow while caculating raytrace.

[erakesh]

Hi Mayamax. Thanks for your reply. I agree with the methods. If I tend to use poly, I would render them as pixar SubDs. Thus making it easy to interact as polys but render as SubDs. But in this way, geometryPaint thru artisan is not supported. Only nurbs supports this I think. At one point, I even created a nurbs proxy for geometryPaint over my original Poly. But need to know a best method for using the features like geometryPaint, fur, easy to animate and texture (Shading thru renderman using renderman shaders) and smooth render.

thanks
Rakesh

[mayax]

Originally posted by erakesh
Hi Mayamax. Thanks for your reply. I agree with the methods. If I tend to use poly, I would render them as pixar SubDs. Thus making it easy to interact as polys but render as SubDs. But in this way, geometryPaint thru artisan is not supported. Only nurbs supports this I think. At one point, I even created a nurbs proxy for geometryPaint over my original Poly. But need to know a best method for using the features like geometryPaint, fur, easy to animate and texture (Shading thru renderman using renderman shaders) and smooth render.

thanks
Rakesh


you can use artisan on subdiv object.

In fact, artisan paint information will be treated as primitive variables in RIB.

For example, vertex[1] carry 5 primitive variables:point P, normal N, color Cs, color Os , and artisan paint variable "float bumpy".

Then you can use the primitive variable float bumpy in your shaders as a "output varying float bumpy" variable.

Just like the vertex carry an additional variable and can be used in you shaders. That looks like you paint it on the surface directly.

Subdiv also can carry additional primitive variables , like polygon.
So does nurbs.

[erakesh]

Wow thats a pretty neat info. But SubDs are really slow. :)

Thanks
Rakesh

[Dipesh (India)]

hey rakesh, mail me

[Mauritius]

NURBS are rendered equally fast as SDS in PRMan. So are polygons. Everything gets converted to micropolygons after gridding and before gridding everything has become bicubic or bilinar subpatches already.
The disadvance is that you can only approaximate curved shapes with polygons; and you'll need a lot more of them in such a case than with high-level primitives. Furthermore there will always be a pov imaginable where still the image will exhibit the faceted nature of the geometry depictured in it.
The rule of thumb is to avoid polygons at all costs, if using a RMan compliant renderer.

Regarding primitive variables: there's neither need nor reason to declare the resp. artisan-painted variable in the shader making use of it as 'output'.


.mm

[erakesh]

Hey mauritius.

You have been like a solution finder in many of the threads. Thanks for being here too. :)

Nurbs is definitely good. Agreed, but what about Nurbs in Renderman. I mean how does it render the seams. The other question lies in texturing. Applying renderman shaders to Nurbs geomtry. Should it be applied to each patch ot is there anyway easier in renderman. Polygons are easy to model, animate and texture. Can you pls compare the importance of both with aspect to renderman.

Thanks
Rakesh

[Mauritius]

Seems can pose problems under sudden circumstances but they usually don't
Imagine that ILM uses PRMan since 1982 (ok, that was REYES, not PRMan yet). All the organic stuff they model is made of NURBS patches. The same is true for most other big studioes up until recently when subdivision surfaces got rediscovered. But since many studios have a very nice pipeline that is build around NURBS, they still seem to be the geometry type of choice.

Seams can only pose a problem in PRMan if a displacement shader is attached or the wrong texture filter is choosen (you usually want 'clamp').
If you use subdivision surfaces in PRMan 11, you can stitch them together. I think MTOR does this automatically, if you attach shaders to faces or face groups which results in one sdsMesh primtive written per shader.

Speaking of elegant texturing via RAT -- you can use the NURBS' patch's name in Maya via a parameter expression in Slim to switch the texture map per patch automagically from the shader:

In your Image File node, enter st. like this into the 'File' parameter:
[txmake textures/$OBJNAME.tif]
(Add any parameters like resize -up etc at the end before the closing bracket.)

If the resp. appearance is attached to a node named 'nurbsShape2' then this should "look" for a texture named e.g. 'nurbsShape2.tif' in your current project's 'textures' folder and convert it to a Pixar Texture (.tex) file that gets placed in the rmantext folder under your current project.

Cheers,

.mm

[playmesumch00ns]

Ahhh nice method mauritius. I had wondered how they dealt with the 10,000+ textures for hero characters in film!

[erakesh]

Wow thats great. :bounce:

But Nurbs are tedious to model and manage as to Polys. Why are polys bad for renderman?

Thanx
Rakesh

[Mauritius]

Polys are bad for any clever renderer (ok, most renderers aren't clever).
A polygon mesh is never curved, it can only approximate a curved shape.
This approximative nature is exhibited once you get too close to the geometry or look at it fomr the 'wrong' pov; that is: the orginal geometric resolution of the geometry puts a severe constraint on your viewing angle and distance.

Second, if you get away from the geometry the opposite may become true: the geometry is too high res for the image being rendered; this results in a lot of memory and time being wasted transforming and shading polygons that don't contribute to the image in the least way. But the worst thing is that this can and will create geometric aliasing as soon as the frequency at which the image is being sampled is less than twice as high as the frequency (aka density) of the polygon mesh under the resp. pixel. In such a case, you will get flickering during animation; in particular if your geometry catches a specular highlight somewhere. Same goes for displacement shaders which btw. need special treatment if applied to polygon geometry.

For closeup shots the same is true -- 'who' knows best how many micropolygons must be created for any surface to look perfectly curved in the image being rendered? Only the renderer itself does.
Look at this image:
http://www.suurland.com/image_x.php?image=images/gallery_stills_newbeetle_hood.jpg

Nice modeled Beetle using NURBS but rendered with the poor 'finalRender'. The geometry was converted to polygons then send to the renderer (finalRender doesn't know higher order geometry). At the lower right side of the image, where the engine hood meets the fender you can see bad shading artifacts in the reflections, caused by the fact that it's all polygons.

Had the NURBS data been piped into a RMan renderer as high level geometry directly, the renderer would have taken care, that an appropriate number of micropolygons would have been created, avoiding any such artifacts.

Speaking of memory consumption, higher order surfaces are much more compact. RIB sizes in the high-end can easily reach gigabytes. Imagine these multiplied by 10 to 1000 for an appropriate number of polygons to create images of close or equal quality.

Displacement shaders are completely unimaginable w/o the renderer deciding on tesselation. What Max and Maya offer as "displacement mapping" has nothing in common with how this term is defined in the RMan universe for 15 years (and by its inventors btw., not some marketing mongos working at A|w or Discreet).
In RMan renderers the resolution of the displacement is arbitrary. In Maya or Max, you must take care that the geometry gets tesselated in an appropriate number of polygons for the resp. view being rendered -- aargh!.

I can only suggest that you read the ARMan book and download the SIGGRAPH 2000 coursenotes form renderman.org. Read the chapter "Rendering Related Issues on the Production of Disney’s Dinosaur", in particular p.76ff (84 in the PDF) to get some explanations about the displacement and geometric aliasing issues in greater detail.


Cheers,

.mm

[joconnell]

Heya Mauritius,

In this case it's not the fault of the renderer ****ing up the reflection, it's actually the model itself - Thomas exported the nurbs data from rhino as a mesh since 3dsmax has pretty bad iges support for trims & fillets etc so he saved out the bits as mesh files - You can see the exact same problems in the reflections in this image:

http://www.suurland.com/image_x.php?image=images/gallery_stills_newbeetle_headlight.jpg

You'd get the same issues in any other renderer (not that I'm defending final render - I'm not that impressed by it) seeing as the fault is in the model. And 3dsmax for having crap nurbs support in the first place... :hmm:

[Mauritius]

If you read my post carefully, you'll notice that I was explicitly referring to the fact that the user had no choice as finalRender wants its geometry as polygons:
(finalRender doesn't know higher order geometry)

So it is exactly the renderer's fault in this case, regardless of the prequisites that led to the geometry being polygons beforehand. Even if Thomas had imported the model into Max as trimmed NURBS surfaces, the renderer still would have gotten the pre-tesselated geometry from Max as it depends on Max in this way. It doesn't make a difference here -- just not clever ...

You can also read an interesting discussion some people, including me, had with Edwin Braun, lead developer of fR on this very subject matter on the highend 3d rendering theory mailing list, about 18 moths ago.

.mm

[erakesh]

Hey guys thanx for the quick debate. It was helpful :) Now that SubDs have been rediscovered, what is their stand against Nurbs as Polys are ruled out? Why is there so much hype for SubDs. Is it just becoz of the blending nature of Polys and Nurbs or anything other than that. SubDs are slow, sometimes real slow. Maybe some light can be thrown on that. But I think lightwave SubDs are really fast compared to Maya's, Isn't it?

[Mauritius]

Sds aren't slow in the least way! I dunno where people get this from.
If you use MTOR, you do not use Maya's hierarchical sds but plain polygon meshes that are tagged to be rendered as sds. Not slow at all. As long as it has a manifold topology, you can use any polygon mesh and render it as a Catmull-Clark sds.

And at rendering time anything gets converted to bicubic patches pefore dicing. So sds and NURBS render equally fast (as do polygons), but I already wrote that in another reply to this thread.


.mm

[erakesh]

Yes I understand and this where the problem is. I model in maya as polys and render as Sds thru MTOR.

Point 1 - Model as Polys and render as subds thru MTOR

Point 2 - Model as Nurbs and render as is

Point 3 - Model in SubDs and render as is

Which is the best? Please mention.

I have read all your replies and am quite comfortable about the answers. but each of them have their own advantages and disadvantages, so unable to decide.

Thanks
Rakesh

[Mauritius]

1 and 3 are one and the same. PRMan only knows one kind of sds, so Maya's hierarchical sds get (losslessly) converted to PRMan sds during RIB generation, then rendered.

The only difference is the handling inside Maya. I dunno if MTOR allows you to add tags for creases, corners and holes to Maya's sds (I don't use them).
If not, I'd prefer 1, otherwise it doesn't matter but most people don't use the hierarchical sds stuff in Maya anyway as other packages don't offer it and it therefore makes the resulting geometry Maya dependant.

The advance of NURBS is their implicit parameterization. If you're comfortable with assigning (multiple) uv sets to polygon meshes, use these and render as sds.


.mm

[joconnell]

Originally posted by Mauritius
If you read my post carefully...

So it is exactly the renderer's fault in this case, regardless of the prequisites that led to the geometry being polygons beforehand.

Even if Thomas had imported the model into Max as trimmed NURBS surfaces, the renderer still would have gotten the pre-tesselated geometry from Max as it depends on Max in this way. It doesn't make a difference here -- just not clever ...

I did indeed read it carefully and what I'm saying is that the errors in the model were caused by the parameters that were used to export the mesh and although max couldn't take in the trims I'm sure that if it theoretically did the tesellation it would apply wouldn't cause this **** up in the mesh. I've rendered nurbs in max before and you wouldn't get that type of shading error with the curves that make up that shape. I'd say if thomas tried using something like power solids to bring in the rhino data directly it'd render without those problems in the fender even when tesselated for use in a max renderer.

Again in max you set the level of tesselation for nurbs surfaces so you could have some discontinuity with low tesselation settings. I'm in total aggreement that the renderman or any micropoly renderer would make far more sense and be higher quality than the nurbs / subdivs in max and sorry to go off on a tangent to the thread :)

[erakesh]

Hey Mauritius.

That was quite bugging from me. ;) Thanks. Now I feel comfortable with the process. Even I prefer point 1, due to the quality of the output and ease of shading using Maya UV set.

Cheers :thumbsup:

Rakesh

[rohithtalk]

hello anna i am testing my account.
did we find a solution in modeling for the nurbs well i have an idea, i'lll telll when i come home..



bye annna.

[jeremybirn]

Originally posted by erakesh
Point 1 - Model as Polys and render as subds thru MTOR

Point 2 - Model as Nurbs and render as is

Point 3 - Model in SubDs and render as is

Which is the best? Please mention.

The only plus to #2 is that you don't need to do any work in the UV Texture editor, because NURBS have built-in UV coordinates. For complex organic models where you'd need a lot of NURBS surfaces, #2 is a lot of extra trouble to set-up and maintain continuity on. Things like blendshapes are slower and harder to design on multiple NURBS surfaces as well. So, #2 works, but it could turn into lots of extra trouble. Things that are simple in poly or subd, like adding extra points and details in a local area, are hard with NURBS.

#1 requires that you'll need to work out UV parameterization before you can paint textures onto the model, but that's often worth it, because you save alot of time on the modeling and are free to put detail wherever you want in a mesh.

Important: Model in mostly 4-sided polys, and 5-sided polys where needed (not 3-sided), and your results are more efficient when rendering as subdivision surfaces.

#3 isn't really that different from #1, you can always link a proxy subd or smoothed polygon model to display in another window as you work on your mesh if needed. I guess I prefer keeping the source model clean and not subdivided, and letting the renderer do the smoothing, but that's a matter of personal preference.

-jeremy

[DominikSusmel]

Since PRMan dices geometry, it doesn't really matter what you use on the rendering side...that being not entirely true (cough)..

With polys you provide as-is geometry to the interface (I'm talking RIB here)..so there is overall potential growing that your rendered result will look "blocky" if not subdivided properly (smooth etc)...
- There is also an issue with UV maping, which you don't get by default like you do with NURBS..

With NURBS, you have control over tesselation, and auto-UV...but patch-modelling can give a headache if you're not used to..

I myself am not a modeler, nor do I pretend to be one, so I just choose based on the application..

Generally speaking, SubDs are all the rage today as being user friendly and all, adding detail in is also easy, as opposed to patching, but, you should stress test which one yields results for you better, Pixars SubDs or Maya SubD->Poly translation...I know people that use each.

I tend to somewhat generalize things into sections of usage:

- Blocky shapes, rigid look.. I tend to go with polys if I don't use deformations-> in which case I tend to lean over to NURBS

- Character, organic, etc., I lean over to poly, and then I test which method will be used to cut corners loose..either Pixars SubD, general smoothing, or Maya SubD->polygon translation.. final decision is a ratio between the final result and tweaking needed for final output

- Landscapes (like I do that all the time, heh), Special control geometry, special FX geometry (for example, soft bodies, hair control systems, etc..).. I tend to use NURBS for these, beacuse of their parametric nature...though it all depends on case-by-case basis

This is only my view of the things.. also, I should mention that most of the modeled stuff I get into my pipeline are being imported as polygons (due to the translation process from certain other packgage)...

[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.