Do all render engines only use polygons?

[Reggie]

lmfao are you for real? So you are saying that, because Renderman uses an internal process such as micro-polygon tesselation for rendering Nurbs, it does NOT render nurbs??

Yes, Renderman does NOT render Nurbs, it ONLY renders polygons. Why can't you get that through your head? What are you trying to say, because you can provide it with a nurbs surface and have it tesselate the geometry at rendertime that it's still being rendered as a NURBS surface?? If that's the case, then mental ray and maya software renders are exactly the same, because they convert the nurbs surface at rendertime too, so clearly, they also render NURBS surfaces natively right!?!?

If you try to render a Nurbs surface, will Renderman do it? YES. Therefore, is Renderman capable of rendering Nurbs surfaces? YES.

This includes almost any renderer, including mental ray. If this were the case, then what is the point of the original question? Renderman is just far more efficient than any other renderer. Is it the best at rendering Nurbs? Yes, definitely, I'm not at all talking about the quality of the render because I'll be the first person to tell anyone that Renderman is the best piece of 3D software commercially available. That doesn't change the facts though.

[Reggie]

Arent NURBS a mathematically defined "infinite" surface? If yes, then it's not possible to render them without first evaluating them discretely. That would mean they need to be converted to a "finite set", before rendering, be that polygons or voxels or whatever...

(just a thought, I'm no expert, please don't kill me )

Yea, that might be why there are no renderers that render true curved surfaces. Everything that I've googled and everything that I've used has to convert the surface into polygons at one point or another.

[enthewhite]

I asked the question being curious about efficiency: Right now I take nurbs from Solidworks and convert them to .obj, which creates pretty dense polygon meshes to capture the details. Obviously, I could spend a lot of time modeling these objects natively in a poly-modeling software to optimize the number of polygons, but that would be highly inefficient with my workflow, since I use solidworks to design. So, I wondered if there is rendering software that either "natively" (whatever that means ) renders nurbs, or just more efficiently converts nurbs to polys before rendering.... Sounds like Renderman might be what I am looking for. But is it good for photo realistic product renderings? Or is it mostly optimized for pixar-esque toon rendering?

Any product rendering wizards out there that care to comment on their own workflows?

[Reggie]

No one can tell you what renderer is best for your personal needs, but I will say this: The best renderer for anything animated is Renderman. When you're just rendering still frames, you won't necessarily see the full benefit of using Renderman, but I personally would still use it if you care about quality. However, a renderer like Mental Ray, Vray, Octane or Final Render would be more suited to rendering still frames. However, on this topic, the relatively new release of Renderman 16 added physically based lighting, which will provide more photo-realistic ray-tracing options if you want them, but that's something that I've never used so I can't vouch for it personally. I have used Renderman's ray-tracing in the past though, and it was always highly under-rated. As a ray-tracer, Renderman was already better than all other renderers in both quality and speed. Take a look at movies like Transformers, Avatar and Guardians of Ga'Hoole, all those were rendered pretty much entirely in Renderman.

All things considered, I'd still personally prefer Octane over these renderers if your time is very limited (this is why I chose to buy Octane myself). I work full time and in my spare time, I'm using Octane for my own renders just because it's Very fast and its based on GPUs, so if I need to build a "renderfarm", I'm looking at maybe a single $2k machine instead of a monster $10k-$20k setup. Octane is very cost/time efficient for still frames.

[Proupin]

Good job overcomplicating the subject bro. This was much simpler, as what enthewhite initially asked for and later repeated is finding a rendering solution that takes care of nurbs curvature in a more wysiwyg manner. I said Renderman and you jumped because you are a great conossieur of this subject and had to let us know...

Matej, you seem to find the way to get to the point in the shortest and therefore most meaningful manner, something that I can't do. That was exactly what I was trying to say, stuff has to be transformed inevitably into discrete chunks, specially when the input is parametric but the output isn't. It is implied (OBVIOUS) that Nurbs need to be transformed in order to be represented in a finite grid whose primary elements are pixels.

enthewhite, if you don't mind using Maya, Renderman will render those Nurbs like no other, at least that I know of. You can trim your way to success that it will -should- look as one piece. One thing, have you considered not using Nurbs for rendering purposes?

[enthewhite]

I appreciate all the opinions posted here. Aside from the ambiguous "native nurbs rendering," I think I now have a better understanding of the real-world options:

• I can use bunkspeed shot with solidworks and give up animation and texturing capabilities
• I can export from solidworks to nurbs in rhino and use vray, and give up animation capabilities (Not sure about this one. I assume vray works with nurbs surfaces in rhino)
• I can export from solidworks to nurbs in maya, and use renderman (requires learning maya and renderman)
• I can export from solidworks to .obj and use my program of choice (softimage) with octane

Switching to poly modeling for rendering purposes is not really an option for me since I was raised on solid modelling and I find it so intuitive for mechanical and industrial design. I would end up modeling everything twice, which I think would far outweigh the extra time it takes a render engine to compute all those unoptimized nurbs->polygon exports.

[Reggie]

Good job overcomplicating the subject bro. This was much simpler, as what enthewhite initially asked for and later repeated is finding a rendering solution that takes care of nurbs curvature in a more wysiwyg manner. I said Renderman and you jumped because you are a great conossieur of this subject and had to let us know...

I have absolutely no interest in letting you know of my experience with Renderman or anything else for that matter, unless you specifically request it. I only corrected your mistake, which does carry its own implications and complications, ESPECIALLY when it comes to ray-tracing. I still clearly stated that Renderman is the best renderer for anything animated, but there is no doubt that it is not optimized for still frames. I'm sorry you mis-interpreted my knowledge of Renderman as simply me boasting, but the good news is that now you know atleast one more thing than you did previously.

enthewhite: Just use Mental Ray. Yes I absolutely hate Mental Ray like you would not believe, but for still frames and basic animation it should be fine. If you want to use Renderman, you don't need Maya, but that would definitely be the easiest way to interface with it.

[acc24ex]

also there is this..
http://www.youtube.com/watch?v=QlMCToxlt1c
2 years ago?

yes there are other ideas/technologies

[enthewhite]

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?

[Proupin]

I have absolutely no interest in letting you know of my experience with Renderman or anything else for that matter, unless you specifically request it. I only corrected your mistake, which does carry its own implications and complications, ESPECIALLY when it comes to ray-tracing. I still clearly stated that Renderman is the best renderer for anything animated, but there is no doubt that it is not optimized for still frames. I'm sorry you mis-interpreted my knowledge of Renderman as simply me boasting, but the good news is that now you know atleast one more thing than you did previously.

you are assuming I didn't know that shit before you said it for some reason . Because I used the term 'natively', only to mean it's 'setup free'?... when in fact it renders nurbs FASTER than regular polygons, it actually converts EVERYTHING into micro-polygons, even plain geometry. That Renderman renders everything as polygons argument is just BS since Curved surfaces and polygons get the same treatment, get sliced into micro-polygons. 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?

But, again, that was not the topic, nor is deciding what is better for stills or animation. You started that line of thought, which is not only off topic, but tried to make me look like a damn fool, and that kind of pisses me off... and I still haven't read your contribution to the topic, the TOPIC, is it convenient for Nurbs, or is it not! What are "the implications/complications" lol that from your point of view would arise from using Renderman, which was designed and optimized for curved surfaces, yes kid, curved surfaces, faster than polygons. "PhotoRealistic RenderMan accepts and processes curved surfaces directly, and very efficiently. A single sphere primitive will render faster than 30 polygons approximating a sphere, and significantly faster than 1000 polygons approximating a sphere." * I should have used the term 'directly' instead of 'natively'