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.
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
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.
This is NOT correct. AM does NOT tesselate to polygons at rendertime. Where have you heard that?
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.
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.
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.”
you know, untill right this minute I had spaced on that post from Yves. Thanks everyone for jogging my memory 
I think my brain filed it way under some of my cheese knowledge 
but honestly the point that patches are not rendered directly is still valid.
-David
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?
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).
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
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.
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.
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?
I think we are all in out of our depth here
nope. 
I may or may not be right, but my feet are still firmly touching the bottom of the pool.
I sent of a message to Ken Baer at Hash, and here is his response:
The answer is “No,” and maybe. Like Renderman bicubic surfaces, what finally gets sent to the renderer can do a ray/surface intersection using a triangle intersection routine, but those aren’t really polygons. One way you can tell is that if you make a single 4-sided patch with “peaked” corners, so that it looks like a rectangle, then decal that. If you pull one of the corners during an animation, the whole decal distorts, not just one side of the decal would if the
flat patch was composed of two triangles. Also, when CG guys talk
about polygons, they’re talking about vertex numbers, and edge lists, which A:M definitely does not have. And the u-v values of Hash patches don’t match polygons either. We used to be straight bicubic intersection, but for speed reasons, we now do this compromise solution.
It appears that David and I were wrong…sort of. The patches are subdivided but not technically into polygons. So the patches aren’t directly rendered as patches, there is subdivision of some sort going on.
I will now bow out of the discussion, because I am clearly NOT touching the bottom of the pool.