Do all render engines only use polygons?

[Proupin]

I too admit that the thought of using mentalray makes me cringe. One of the main reasons I started using octane was to get away from all the hundreds of settings, tweaks, and tricks that are required to make renderings look good in mental ray and vray. I have come to realize that even an unbiased renderer like octane comes with its own set of tricks necessary to fake reality, but I think it is still much less of a learning curve than mental ray. I wonder if the integrated softimage plugin that is being developed will work with nurbs surfaces? Does the integrated 3dsmax plugin render nurbs?

3ds max won't do Nurbs better than any other, in fact they are pretty sub par, and if using the plugin you still have to 'convert' to polygon mesh. If you are going to keep using nurbs as usual (polygon-converted surfaces), you might as well keep using Octane, or learn Vray which I find easier to get things done than MR; Octane (standalone or plugin) being the easiest of course. I seriously doubt that the future Softimage plugin will adress anything related to this subject, first the Octane engine should adress Nurbs rendering, and that won't happen anytime soon. If anything I wouldn't be surprised if they implemented subdivision rendering from poly meshes first.

[Reggie]

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.

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.