MDenham <nomail@nomail> wrote:
> Since all of the primitives, except mesh/mesh2, can be represented
> fairly easily as an equation, or a relatively small set of equations, this
> method should be reasonable to implement.

  Meshes are not the only problematic primitives.

  Besides height_field (rather obviously, as it's just a "disguised" mesh),
you also have the julia_fractal object, which is traced iteratively rather
than solving an equation.

  Then there are the primitives which are generated using splines, such as
lathe, sor and, I think technically speaking, the text object. While you
probably can express the splines as single polynomials (rather than a group
of polynomials as splines usually are solved), they probably become really
complicated for larger splines. It might be possible to create specialized
code for transforming spline-based objects, though.

  Then there are the infinite surfaces, which do not present problems
from the transformation point of view per se, but from the raytracing
point of view. Rather ironically, the poly object might be hard to
transform freely if the poly object represents an infinite surface:
Yes, you can calculate the transformed equation, but how will you
trace it? Isosurfaces always need some boundaries to be traced. Only
if the transformed poly object is another valid poly object, it becomes
possible.

-- 
                                                          - Warp

Post a reply to this message