Warp <war### [at] tagpovrayorg> wrote:
> Dan Connelly <djc### [at] yahoocom> wrote:
> > The #1 feature I'd like to see is support for "rounded corners".
>
>   Their problem is that automatically creating rounded corners for any
> given object:
>
> 1) is impossible in the general case,
>
> 2) in many cases where it's possible it results in extremely slow renders,
>
> 3) would require tesselating the object and rendering the resulting mesh
>    (with the corner modifications).


I agree for the general case, but it wouldn't be a bad or difficult thing to
have a new keyword that would allow for beveling and rounding the edges of a
few specific primitives.  Upon reading the original posting, I was only
thinking of things like the use of spheres and cylinders to produce a rounded
box or the use of tori to round a cone/cylinder.  I have seen (and written) a
few macros for that sort of thing, and I think it would be fairly simple to
implement edge rounding for boxes and cylinders.  Cones would also be simple,
but certain edge cases of large radii bevel combined with a short cone that has
a large difference in the radii of endpoints could get strange.  Prisms and text
could also be done if one has access to a lot of the internals that must be
calculated.

In reading your (Warp's) response, it occurred to me that I may have
misinterpreted the OP, as I hadn't considered the idea of smoothing arbitrary
objects as a built in  facility for POV-ray.  It does remind me, though, of a
discussion I had with my brother for a modeling tool that would allow one to
"meld" objects together by generating a mesh to connect between primitives.
The triangles and normals closest to the primitive would match the shape and
normal of the primitive and (assuming the mesh is of high enough resolution)
would allow smooth blending between most "simple" primitives.

Of course, as was mentioned above, the tessellation would be done prior to
rendering, and any changes in the objects would also require adjusting the
mesh, and then there are the issues of mesh resolution, etc.  That's not to say
that it isn't a usable technique, but it is a consideration.

This originally came about as an idea for supplementing height_fields with
meshes to overcome the limitations of a height_fields, and how one might make a
mesh that blends smoothly into the contours of the height_field.


>   One possibility for POV-Ray 4 would be to drastically increase its
> support for creating and handling triangle meshes (by scripting). If
> most of the primitives and CSG could be automatically converted to
> triangle meshes (by cleverly designed scripts), it would then be
> relatively easy to create other scripts which would perform subdvision
> and transformations (non-linear transfromations, edge rounding, etc)
> of those meshes.
>
>   This way you still can't round the edges of existing objects, but at
> least you would have better tools to re-create those objects as meshes,
> and then transfrom those.

Personally, I lean more towards a larger amount of non-image output for POV 4 -
the storage of certain information in a binary format to allow quicker
rendering.  I don't know enough about the current or proposed architecture, but
I've wondered about this, particularly for animations (of course, if the
animation references something that may change externally, this could require a
volatile qualifier or the like to force re-parsing of certain things).

-Reactor

Post a reply to this message