The #1 feature I'd like to see is support for "rounded corners".

Blobs are a step in the right direction, but they have obvious issues.  For example,
they bulge at intersections.  Further, the number of primitives (cylinders and
spheres) is too small.

I wonder if there's a way to more specifically model the interface between objects, or
the interface between faces.  Sharp corners are so rare in life, yet so hard to avoid
in POV.

What I love about POV is that it's parametric.  For example, I can design a bicycle
crankset, then instantly generate a crankset for any reasonable crank length and
chainring tooth counts -- it's a matter of changing a single parameter passed to the
macro.  I'm not sure how easy that would be in blender.... (then, I don't know
blender).

There are two ways this could be done, it seems.  One is for actually modifying the
boundary, the other is the smooth the normals but keep the boundary intact.  The
smoothed normal might look fairly good.

For pathological objects like fractals, this may be hopeless. But for simple objects,
perhaps it is manageable.

//-------------------------------------------------//
#include "colors.inc"

background {
   color Black
}

light_source {
   -10 * z
   White
   rotate 15 * x
   rotate 15 * y
}

blob {
   threshold 0.5
   cylinder { -y, 0, 1, 1 }
   cylinder { 0, y,  1, 1 }
   translate -x
   pigment { color Green }
}

blob {
   threshold 0.5
   cylinder { -y, y, 1, 1 }
   translate x
   pigment { color Yellow }
}


camera {
   location -8 * z
   look_at 0
   angle 30
}

Post a reply to this message

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).

  In mesh/NURBS modellers rounding corners is an extremely trivial thing
to do. That's because they only handle triangle meshes (or NURBS, which
are equally easy to handle) and can subdivide and modify the vertices
freely.

  POV-Ray, however, handles mathematical primitives (such as boxes and
planes) and their CSG. Rounding their corners is a problem which is
several orders of magnitude harder.

  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.

-- 
                                                          - Warp

Post a reply to this message

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

Reactor <rea### [at] hotmailcom> wrote:
> 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.

  The problem is that the usability of that would be very limited. It
wouldn't help rounding edges of CSG constructs, for example.

> 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.

  In fact, there are rounded box and rounded cylinder macros in the
standard include files.

-- 
                                                          - Warp

Post a reply to this message

>  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,

Those first two are not really problems though - ie we shouldn't say not to 
include a feature because it won't work with all possible objects and might 
result in extremely slow renders sometimes.

> 3) would require tesselating the object and rendering the resulting mesh
>   (with the corner modifications).

That's not the only way to do it.

>  POV-Ray, however, handles mathematical primitives (such as boxes and
> planes) and their CSG. Rounding their corners is a problem which is
> several orders of magnitude harder.

But not impossible, look at any CAD software that manages it with 
mathematically defined CSG.  The problem I see with POV, is how to specify 
which edges you want to be rounded, so far we have no way of specifying 
edges in the SDL.

I have no idea how CSG objects are stored internally in CAD software, but at 
each stage of the CSG you can somehow specify edges and faces etc to apply 
rounds and chamfers to.  I don't know how you would attempt to replicate 
this in a text-based way.

Internally, the POV engine would need to see what faces were connected to 
the specified edge, and remove/generate the correct geometry to round that 
edge.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote in message news:48e34c55@news.povray.org...
>>  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,
>
> Those first two are not really problems though - ie we shouldn't say not 
> to include a feature because it won't work with all possible objects and 
> might result in extremely slow renders sometimes.
>
>> 3) would require tesselating the object and rendering the resulting mesh
>>   (with the corner modifications).
>
> That's not the only way to do it.
>
>>  POV-Ray, however, handles mathematical primitives (such as boxes and
>> planes) and their CSG. Rounding their corners is a problem which is
>> several orders of magnitude harder.
>
> But not impossible, look at any CAD software that manages it with 
> mathematically defined CSG.  The problem I see with POV, is how to specify 
> which edges you want to be rounded, so far we have no way of specifying 
> edges in the SDL.
>
> I have no idea how CSG objects are stored internally in CAD software, but 
> at each stage of the CSG you can somehow specify edges and faces etc to 
> apply rounds and chamfers to.  I don't know how you would attempt to 
> replicate this in a text-based way.
>
> Internally, the POV engine would need to see what faces were connected to 
> the specified edge, and remove/generate the correct geometry to round that 
> edge.

The main problem, scott, is that POV generally doesn't work with 
faces/surfaces. It works in solids.

As far as I can see, the only generalisable methods of doing this are:
    1) Use CSG to break up the intersection into parts and build the rounded 
bits by hand or
    2) Create an isosurface that closely follws the outline of the CSG 
objects but smooths it out.

I beleive there are attempts at both in the POV object library.

Rarius

Post a reply to this message

> The main problem, scott, is that POV generally doesn't work with 
> faces/surfaces. It works in solids.

I know, you would need to expand the CSG algorithms to keep track of 
edge/face data.  Note that by edge/face I don't mean it in the triangulation 
way, but in the mathematical way - ie an edge could be a curve, and a face 
could be a section of a sphere, cylinder etc.

> As far as I can see, the only generalisable methods of doing this are:
>    1) Use CSG to break up the intersection into parts and build the 
> rounded bits by hand or

This is what I had in mind (but not doing it by hand).  If POV kept a list 
of faces/edges with each CSG object, it should be then possible for the user 
to identify edges to round.  Of course more code would need to be added to 
generate internally the geometry necessary for the round.

As a side-effect, having the face/edge data available would make 
triangulation easier for other purposes...

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  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,

> Those first two are not really problems though - ie we shouldn't say not to 
> include a feature because it won't work with all possible objects and might 
> result in extremely slow renders sometimes.

  However, what those two things do tell us is that the problem is very hard.
In other words, it's very hard to come up with a good implementation (even
if we completely disregard rendering speed) which will work well and look
good (eg. doesn't suffer from visual artifacts).

> > 3) would require tesselating the object and rendering the resulting mesh
> >   (with the corner modifications).

> That's not the only way to do it.

  But it's the best alternative. After tesselation you can do almost anything
you want with the objects with little limitations. The only hard step in this
process is the tesselation itself.

> >  POV-Ray, however, handles mathematical primitives (such as boxes and
> > planes) and their CSG. Rounding their corners is a problem which is
> > several orders of magnitude harder.

> But not impossible, look at any CAD software that manages it with 
> mathematically defined CSG.

  CAD software always tesselate their geometry before rendering. They do not
render untesselated mathematical surfaces.

-- 
                                                          - Warp

Post a reply to this message

>> >  POV-Ray, however, handles mathematical primitives (such as boxes and
>> > planes) and their CSG. Rounding their corners is a problem which is
>> > several orders of magnitude harder.
>
>> But not impossible, look at any CAD software that manages it with
>> mathematically defined CSG.
>
>  CAD software always tesselate their geometry before rendering. They do 
> not
> render untesselated mathematical surfaces.

That's only to render quickly though, internally all surfaces are stored as 
mathematical descriptions.  In theory you could write a raytracer to render 
these surface descriptions directly with no tesselation.  In fact, if you 
create a shape with rounded edges in a CAD program, you can export it to a 
common interchange format (STEP) which is plain text.  In that you will see 
that the solid is completely defined by mathematical curves and surfaces, no 
tesselation.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> That's only to render quickly though, internally all surfaces are stored as 
> mathematical descriptions.  In theory you could write a raytracer to render 
> these surface descriptions directly with no tesselation.  In fact, if you 
> create a shape with rounded edges in a CAD program, you can export it to a 
> common interchange format (STEP) which is plain text.  In that you will see 
> that the solid is completely defined by mathematical curves and surfaces, no 
> tesselation.

  That doesn't change the fact that the CAD software tesselates the surface
before rendering it. Or have you seen one which doesn't?

-- 
                                                          - Warp

Post a reply to this message