PDA

View Full Version : Renderman & Nurbs


substyle
09-24-2003, 06:19 PM
Hey Guys.

Had a bet with a friend of mine .. :p

Does Renderman need to tesselate NURBS Surfaces before
rendering them ?
By the Way .. is there anyway an other renderer who doesnt
need to ?

Thx

subby

artistx
09-24-2003, 07:26 PM
I don't know about PRman and other renderman compliant renderers. AIR drops everything to polygons at render time. It says this in the software documentation.

stew
09-24-2003, 07:54 PM
First, RenderMan is not a renderer, it's an interface (see http://www.renderman.org/RMR/index.html#what).

So, assuming that you are speaking of Pixar's PRMan: Following the REYES idea, it is breaking up everything into micropolygons. Micropolygons are typically smaller than a pixel (the exact size of a micrpolygon is determined by the shading rate parameter) and therefore PRMan does not produce any visible tesselation artifacts like some other renderers do. So, where in other renderers, you have to set a fixed tesselation rate for your NURBS objects, PRMan is automatically breaking them up just fine enough to render perfectly smooth.

You could in theory build a renderer that doesn't tesselate at all. Just like many raytracer render quadrics using their mathematical equation (e.g. r = x^2 + y^2 + z^2 for a sphere), you could render NURBS by intersecting a ray with the equation of your NURBS. Wether this is an effective way of rendering NURBS is a different question... especially since there would not be any visible difference to a REYES renderer with a shading rate <=1.

gga
09-24-2003, 08:29 PM
Originally posted by substyle
Hey Guys.

Had a bet with a friend of mine .. :p

Does Renderman need to tesselate NURBS Surfaces before
rendering them ?
By the Way .. is there anyway an other renderer who doesnt
need to ?



Renderman being the scene description/shading language allows renderers flexibility to render their primitives in any way they may want as long as they adhere to the RIspec specification... or else they are not officially renderman compliant.

The original implementation of Renderman, Prman, does indeed render all its primitives with polygons (albeit they are also sometimes referred as bilinear patches of 1x1 dimension - the difference is likely more theoretical and abstract than anything else). More commonly, the final primitive rendered is referred as micropolygons since those pieces end up being smaller than a pixel in size by default, making the result for all visual and practical purposes, identical to a direct evaluation of the surface.

AFAIK, most if not all other popular renderers (renderman compatible or otherwise) follow a similar approach, but the algorithms used for tesselation may vary (offering more or less control, speed and/or quality).

You might be able to find some renderer that renders using some form of direct evaluation of surfaces. However, it is not likely to be 100% renderman compliant, since direct surface evaluation likely becomes impossible once you allow for displacement mapping on surfaces using an unrestricted shading language.

substyle
09-24-2003, 08:33 PM
Well first thank you for the detailed Information ! :thumbsup:

Sorry bout the mistake with Renderman an PRman ..
So far I "only" used MR and the Maya Software Renderer. :)
Well I will search googel for "REYES idea" seems to be am
interessting topic ..

So lets say both won .. hehe

subby

Mauritius
09-24-2003, 09:22 PM
You could in theory build a renderer that doesn't tesselate at all. Just like many raytracer render quadrics using their mathematical equation (e.g. r = x^2 + y^2 + z^2 for a sphere), you could render NURBS by intersecting a ray with the equation of your NURBS. Wether this is an effective way of rendering NURBS is a different question... especially since there would not be any visible difference to a REYES renderer with a shading rate <=1.

Realsoft3D's renderer uses this approach. Albeit, as there is a discretization error which is a function of Shading Rate in a REYES renderer, there is a discretization error which is a function of the precision of the Newton solver for the ray intersection test in a renderer using that approach.
Realsoft shows shading errors similiar to low poly tesselation artifacts, when their solver's precision is too low. As their solver's precision is independent of raster space size of the rendered geometry (that is: the error gets bigger and becomes obvious, when zooming, dollying into geometry, just as with polygons), tesselation into micropolygons seems to be the better approach.
Additionally, a bunch of other advances, shading wise, that come with micropolygons, are not as straightforward to implememnt using a Newton solver (think of derivatives needed for proper antialiasing in Shading Language).

Another downside is that a ray-intersection test for the camera means your renderer will always ray-trace, whereas a REYES renderer scanline converts its geometry -- part of the reason it is so fast and supersampling is so cheap.

AIR btw. is not a true REYES renderer. It has curvature / min-distance based tesselation density controls to tweak quality. Lowering Shading Rate results in a blocky image, not blocky tesslation artifacts. Hence, Shading Rate in this renderer, truly only means the frequency at which shaders are called (which is its intended meaning, if you look at the RI spec) and is completely independent of tesselation (as far as I know).


Last but not least, since this debate is rather philosophical, I'd suggest you read this loosely related thread (http://www.highend3d.com/render/archive/sp.3d?mail_id=1295), which emerged on the highend3d rendering therory list two years ago. The questoin was whether a renderer can truly render NURBS, Subidivison Surfaces, etc.; or whether it can't.

Larry Gritz, all time RMan guru came up with a nice definition of 'true' (http://www.highend3d.com/render/archive/sp.3d?mail_id=1521). While you didn't loose your bet, since -- as someone else mentioned already -- "RenderMan" isn't a renderer per se anyway, you could bet again after rephrasing the bet's topic a bit. ;)

There is also some quite related 'essay' I wrote for the Wings RIBBit manual (io.plastickitten.net/Wings%20RIBBit%20Manual%20w-i-p.pdf). It is called "Primitives & Some Philosophy" (pp. 10).


Cheers,

Moritz


.mm

substyle
09-24-2003, 10:02 PM
@Mauritius

Jesus man! , - you scare me ..

"I'd suggest you read this loosely related thread, which emerged on the highend3d rendering therory list two years ago"

This is SICK , total SICK. I'd never mentioned this to be come out
as such an discussion. Anyway great links .. I love philosophical Themes. Bet my freind doesn't anymore after this hehe.

subby :beer:

jeremybirn
09-25-2003, 10:13 AM
A major issue is memory use. PRMan doesn't tesselate NURBS or Subdivision Surfaces _before_ rendering, so there's never a time when the whole surface needs to be converted to polygons and held in memory at once.

The number of micropolygons that are sampled is controlled by the shading rate. At a shading rate of .25 there are 4 micropolygons per pixel, at .1 there are 10 micro-polygons per pixel. So, if a surface filled the screen on a 2048x1108 render at .1 shading rate, that would be over 22 million polygons getting rendered from that surface - programs that tesselate ahead of time couldn't hold all of that in RAM on most computers.

-jeremy

beaker
09-25-2003, 11:18 AM
Blue Sky's in house renderer CGIstudio doesn't tesselate nurbs but instead directly remders them like martius & stew mentioned.

stew
09-25-2003, 11:36 AM
How fast is it (or Real3D, for that matter)? My math classes lie a few years in the past, but it sounds to me like approximating through recursive subiding should be more efficient than a Newton solver. How do these renderers handle the precision problem? Do you give it a fixed number of iterations to run through or is there a minimum error (in pixels) setting?

Mauritius
09-25-2003, 12:04 PM
It is unbelievable fast, when rendering plain geometry.

As I wrote, you set a fixed number of iterations which means the precision is independent of the resp. geometry's raster space size. As soon as you get too close to the geometry, artifacts show up.

Another problem is their shading VM (yes, Realsoft has programmable shading, although through a rather strange "artist friendly" interface). The VM is so slow that as soon as you attach any shaders, the solver's evident speed advantage over tesselation is nullified or worse.

Their "Shading Rate", as in AIR, is independent of the geometry's resolution (or the solver's precision in this case, which makes sense). Lowering the frequency at which shaders are called results in a blocky image. They do allow though to do st. like Shading Interpolation "smooth" aka Gourad shading. The problem again is that artifacts are always raster space aligned. Ok for stills, but unusable for animation work.

I also haven't really looked at their renderer for almost a year. But as I have been an alpha and beta tester of RS3D for years, and hence know their 'speed of implementation', I doubt anything I said above has recently been invalidated by newer releases.

Cheers,

.mm

altmeister
09-25-2003, 12:24 PM
the friend (hehe):

as i say to you substyle, no need to tesselate to polys, only approximation of curves ...

the only problem when you approximate is the precision of your tangent in your actual pixel, you can't compute all pixels (it never ends). bmrt, prman and exluna use micropolys, but i don't know the tec behind mantra.

very interesting is the fact sony's ps3 will support nurbs rendering, so let's wait until late next year.

stew
09-25-2003, 12:37 PM
Originally posted by Mauritius
As I wrote, you set a fixed number of iterations which means the precision is independent of the resp. geometry's raster space size. As soon as you get too close to the geometry, artifacts show up.
It would be interesting to try a max error setting for such purposes, telling the renderer to "err not more than by .5 pixel". That way the solver would chose the number of iterations depending on the distance, comparable to the shading rate. But that could become very slow for close-ups, I guess.

Mauritius
09-25-2003, 01:38 PM
VMantra is a micropolygon renderer too.

altmeister
09-25-2003, 02:27 PM
thx Mauritius

somebody allready worked with houdini ?
mhm i think i try the trial, hoping for tutors :)

substyle
09-25-2003, 02:47 PM
Ok .

First Rule:
subSTYLE is always right.
Second Rule:
If subSTYLE isn't right anyway - rule one has to be automatically
applied.

Ergo - subSTYLE is always right.

Man I hat somebody to be more "right" than I am :p

Ok Altmeister. There is Nurbs Rendering only through approximation of curves.

"As soon as you get too close to the geometry, artifacts show up.
" Well therefore I love to have traditional controll of my Tesselation.

subby

P.S.: Altmeister you just won a big Beer - I'll contact you the next
time i'm over to berlin.

stew
09-25-2003, 02:57 PM
Originally posted by substyle
Ok Altmeister. There is Nurbs Rendering only through approximation of curves.
Of course. Everything we render is an approximation and will be as long as we have digital computers and pixel-based output.
"As soon as you get too close to the geometry, artifacts show up.
" Well therefore I love to have traditional controll of my Tesselation.
Well, not in a micropolygon renderer with a shading rate of less than one. There are imprecisions, of course, but since those are smaller than a pixel there are no visible artifacts. The old law of computer graphics: If it looks right, it is right. There is no need to be more precise than that.

altmeister
09-25-2003, 03:18 PM
k
:beer:


ps: haptic rendering with some optimisation should not come up with artifacts, read something about it in a sg 2003 paper

Mauritius
09-25-2003, 10:34 PM
"As soon as you get too close to the geometry, artifacts show up."
"Well therefore I love to have traditional controll of my Tesselation."

First this is an restriction imposed by the resp. implementation (Realsoft).
Second, it is not true for a micropolygon renderer.
Third the time spent setting tesselation for thousands of objects, on a per shot, sometimes on a per frame basis is better being spend elsewhere.

This is a tiny part of the reason why PRMan is the renderer for high-end work. Only non-adepts think control over tesselation has advances.
The party who knowns best what tesselation is appropriate for a resp. image is the renderer, that was asked to generate it -- not the artist. ;)

Cheers,

Moritz

dmaas
10-02-2003, 03:20 AM
I've always wondered if there would be any use to independently varying "micropolygon-tessellation" shading rate and "shader evaluation" shading rate in PRMan. When I have very complex geometry with a simple shader, it seems redundant to evaluate the shader at every micropolygon vertex; with simple geometry and a complex shader, it seems reduntant to tessellate the surface so finely... But then again the savings would have to compete with the extra cost of managing shader samples and micropolygons separately.

But still, PRMan is light-years ahead of all the renderers that do not let you vary spatial/temporal sampling and shader evaluation separately (e.g. Lightwave)...

Mauritius
10-02-2003, 03:23 PM
In theory, you could render that geometry with a low shading rate, then use an unfiltered texture lookup in NDC space into this image to render a densely tesselated version w/o the expense of calling the original shader at all.
.mm

agreenster
10-02-2003, 07:07 PM
You guys are way too frikkin' smart. :eek:

(this coming from, of course, an animator):thumbsup:

CGTalk Moderation
01-16-2006, 05:00 AM
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.