Proupin wrote:But, again, that was not the topic, nor is deciding what is better for stills or animation.
First of all, I'm going to start by highlighting this line of yours. 1) Rendering for animation vs still frames is ALWAYS important to consider when discussing renderers advantages and disadvantages. All renderers have their quirks with either one or the other. This is the basics of all rendering, so don't even start by trying to say that I'm veering the discussion off topic. Renderman, as I previously mentioned, is the best renderer available if you're doing something that is animated, but rendering still frame images is its biggest downfall, so the obvious should be stated.
You have gone off on a completely different tangent and have not even attempted to recommend a legitimate suggestion as an alternative, efficient renderer. The op retracted his "ambiguous" statement about "native nurbs" rendering, so he obviously doesn't care that much about the specifics of what is going on underneath the surface. The only suggestion you've given so far is "renderman for maya". The OP has stated that he does not want to learn Maya and would rather stick to his native program of XSI. Meanwhile, there are other Renderman compliant renderers
out there and I don't see you saying anything.
Proupin wrote:Renderman was DESIGNED to render curved (yes, NURBS, parametric primitives as well), MORE efficiently than plain geometry. Renderman does NOT render anything as polygons (polygons =/= micro-polygons
) See I can get nitty-picky with the semantic side of things too, the result? idk, confusion? looking cool? a shiny new reply?
Hahaha, this is funny. You really know how to waste my time don't you? Aside from the aforementioned fact that "native nurbs rendering" has already been DISMISSED by the OP as unimportant... I'm going to answer this question anyways just for you. Firstly, were you trying to say
micro-polygons do not equal polygons? Were you trying to use the not equal != symbol? Because that's incorrect: micro polygons are polygons... do I even need to state that?
Wrong again. Parametric primitives and Nurbs surfaces are not more efficient than polygons. I hate to break the news to you (again) but Renderman is NOT any faster with curved surfaces (nurbs or parametric primitives) than it is for standard geometry, they are just not that different in speed to clearly state which is faster. The only advantage that curved surfaces hold is that they don't require hundreds of thousands of points to define a smooth surface, and this would be more efficient for any renderer. The actual rendering is almost identical. And once ray-tracing is thrown into the mix, things get a lot more complicated and actually the polygons can be more efficient because the renderer doesn't constantly have to recalculate the surface for each ray hit. Anyhow, if you want to check this out yourself, take a real world object with 100,000 points and render it.... then take that same object and turn it into subdivisions and render it. You will notice that Renderman is NOT faster with curved surfaces. In fact, it's sometimes 3x slower than the standard polygon mesh.
Maybe you meant to say procedural primitives? Yes, prodedural primitives are more efficient than standard geometry but only hardly and besides what does that matter? The OP is clearly not asking about using procedural primitives if his geometry comes from Solidworks is he? And still, you're talking about a fraction of efficiency gained in scanline rendering only. And again, it's not the
rendering being more efficient, we're just talking about the memory footprint of the description of a sphere with a table of 100+ vertices + faces + UVs being far less efficient than the description of "Sphere 1 1 1 360". Yea, there's no surprise there that there will be a tiny bit of efficiency gained, but this is not relevant.