Patch based character animation.

#2

I believe PRRenderMan (Pixar’s flavor) converts to micro-polys at rendertime, whereas some other RenderMan compliant renderers actually render parametric surfaces directly.

Like these, AM renders parametric “Hash-splines” directly without ever having a “convert to polys” stage.

Alternatively, Mental Ray, another commonly used production renderer expects polys, no matter if the source geometry is polys, subdivision surfaces, nurbs, displacements, etc. It’s ALWAYS converted to polys at rendertime.

There are advantages to parametric modeling, especially since Hash-splines are completely WYSIWYG.

However, a lot of model work these days is done with subdivision surfaces because they retain many advantages of both poly modeling AND parametric surfaces.

My personal choice is usually sub-d modeling, but in this area, personal preference and project requirements are king.

#3

This is incorrect, A:M converts to polys to render. The benefit of A:M’s renderer is it knows how much to tesselate the patches so you wont see facets.

#4

My understanding is that the A:M renderer is a hybrid scan-line a-buffer and raytracer that works directly with parametric surfaces defined by Hash-splines. In fact, I remember the marketing hype that went something like “Death to Polygons”.

Has this changed?

edit one of the current product blurbs says “Spline based modeling, animation, and rendering.”, so I’m guessing that rendering is still spline-based. Excluding any D3D/OpenGL output, of course.

#5

Nope,

A:M has tesselated to polygons at rendertime since at least v5. it’s like mike said. the main benefit is that it tesselates only when it renders a frame, and re-tesselates for every frame. So that a deformed surface, say an elbow, can have an exactly the density needed for any given deformation at any frame at rendertime. This is the core of A:M’s animation tools.

-David

#6

lol - I guess I learn something new every day… I got into Hash software back when it was “Playmation”. Maybe that’s where I picked up that idea.

#7

This is NOT correct. AM does NOT tesselate to polygons at rendertime. Where have you heard that?

#8

Umm from the programmers at Hash inc.

-David Rogers

#9

They don’t call them polygons, they call them something else (blocks, squares, quads… or something). I don’t know what the difference is. However, they must tessalate to polyons for the hardware renderer. The important point I guess is that they arn’t rendered directly (as they used to be) as this is very slow to do.

#10

That’s strange because that’s not the case.

#11

I saw a post by Yves Poissant on the Hash forum and he did a good job clearing this up.

I’ll see if I can find it.

#12

It was probably this thread: http://www.hash.com/forums/index.php?showtopic=10871&st=30

“Hash splines or Hash patches are not converted to polygons at render time. Hash patches are converted to tiny planes or flat surfaces. This is not the same thing as a polygon. A polygon is a plane delimited by edges joined by vertices. In A:M, at render time, the planes are just planes. They are not delimited by edges. Thus they are not polygon. We don’t need to convert them to polygons because the planes are computed dynamicaly for each pixel. And because a pixel is infinitesimal in space, we don’t need to know if the plane is delimited by edges or not. We only need to know the plane equation at that infinitesimal point.”

:thumbsup:

#13

Thanks for the link, Veehoy. That’s the very one.

#14

you know, untill right this minute I had spaced on that post from Yves. Thanks everyone for jogging my memory :slight_smile: I think my brain filed it way under some of my cheese knowledge :stuck_out_tongue:

but honestly the point that patches are not rendered directly is still valid.

-David

#15

Honestly and with all due respect, I think it isn’t. I believe the Hash splines are rendered as directly as possible in A:M or could you think of a more direct way?

#16

A more direct way is to render each and every pixel (or sub-pixel) according to the spline fomula. At the moment, this isn’t the case. There was a time in an alpha version where the little squares were visible (they had outlines). The geometry is divided more where it has more curvature and is closer (I think).

I believe the same kind of algorithm is used when hardware rendering in adaptive mode and it is this technology that allows AM models to be shared over low-bandwidth connections but still appear perfectly smooth (as if made from an infinite number of polys).

#17

and, in v4 and v3 (at least not 100% about v2 ) the surface was indeed renderd as john said, by raytracing the spline patch, it wasn’t divided into anything at all.

-David

#18

Hash splines or Hash patches are not converted to polygons at render time.

the planes are computed dynamicaly for each pixel.

If a plane equation is dynamically calculated from the spline surface at the pixel or sub-pixel level, with no bounding vertex/edge information, this seems to me like direct scan-conversion or raytracing of parametric surfaces. I don’t see how this could be construed as converting to polygons. If I’m wrong, please enlighten me.

#19

With Bezier patches yes, but with Hash patches I don’t think this is even possible. If I have the correct information, Hash patches are defined by its subdivision algorithm and using that is rendering as direct as possible.

#20

OK… I think we are all in out of our depth here… not to mention that the discussion has been knocked off it’s original course.

But, for what it is worth, there is a formula for hash patches (I’v seen it) so they could be rendered directly, but I’m pretty sure that they arn’t these days for speed reasons. This is just what I remember.

Also, I remember reading that shading, shadow and reflection operations are handled differently with the mesh been divided differnetly for each… complicated stuff!!

Anyway… where were we?

#21

Click here for Martins Tech notes.

Maybe this clears things up?