Hi,

After working for a bit with CSG objects, there's one feature that I
want again and again, which would be massively, dramatically useful.

If I could round the edges on objects automatically, without patching
together lots of cylinders and spheres and toruses, life would be VASTLY
simpler.

For example:
  box { <0,0,0> <1,1,1> round 0.1 }

would create a box with all the edges and corners rounded with a 0.1 unit
radius curve.  To construct this from separate objects requires 3 boxes,
8 spheres, and 12 cyliners -- 23 objects in total.  This should not simply
be for shading -- it would need to change the outline of the shape.

Rounding out cones in particular would be helpful, because to smoothly
transition between a cone and a torus requires some manual calculations
from the cone slope angle to get both the position and diameter of a
rounding torus.

But I want more than simply rounding out boxes, cones, and cylinders.
To really be useful, round would need to work with all of the CSG
operators (union, difference, etc.)

Consider this:
difference {
  box { <0,0,0> <24,16,60> round 1 }
  cylinder { <12,16,6> <12,16,54> 8 round 8 }
  round 3
}

This makes a nice bathtub, with rounded everything.  The box of the tub
is rounded with a one unit radius.  The interior of the tub is a big
pill shape that if done with CSG would be two spheres of radius 8 
attached to a shorter cylinder of radius 8.  And finally, the transition
between the tub box and the interior would be rounded smooth with a
3 unit radius.  Just try to make this with just CSG - you're looking at
somewhere around 35 objects.

Even that's not the greatest help.  Suppose you subtract a tilted
cone from a box, and you need to round the resulting edge.  The
resulting shape is a parabola (or is it a hyperbola?).  This would not
be easy to round -- could a torus be stretched to match, or would you
need to match a sphere_sweep to the resulting edge?

And when unioning two objects together, any "inside" joints would need
to be filled in (gussetted) to the appropriate roundness.  This is even
more complicated to pull off with CSG, as anyone who has tried it
knows.  I thought maybe you could have separate "gusset" and "round"
values, but I haven't been able to think up a single CSG operation
which will create both inside and outside edges, so it probably
wouldn't be needed.

The default value for "round" would of course be zero.

Implementing rounding of exterior corners should not be terribly hard.
Once you've hit an object, see if you are close to an edge, you need to
do an extra calculation for the intersection point and normal, and in some
cases may need to decide that you actually missed the object.

Implementing gussetting would be tougher, since a gusset will enlarge the
outline of an object.  In this case, if you miss an object you need to
check to see if you missed it close enough that you need to check to see
if a gusset must be filled in.  Otherwise, once hit processing would be
very similar to rounding.

This could definitely slow down rendering substantially.  It's definitely
designed to reduce development time, not rendering time.  But given that
you'll end up with so many fewer CSG objects, it's still possible that it
would compete well at render time.

So, those who know the code inside and out, is this doable?  Fairly
simple change?  Nightmarish change, due to the order things are
processed?  I'm willing to work on the implementation myself, but I'm
not going to waste my time if the experts tell me that the code would
have to be completely restructured to support such a feature.

         tom

Post a reply to this message

Thomas A. Fine <fin### [at] head-cfaharvardedu> wrote:
> So, those who know the code inside and out, is this doable?  Fairly
> simple change?  Nightmarish change, due to the order things are
> processed?  I'm willing to work on the implementation myself, but I'm
> not going to waste my time if the experts tell me that the code would
> have to be completely restructured to support such a feature.

  You seem to think that it's just a question of syntax and automatically
generating the proper geometry from it. Well, it's not. What you are
trying to achieve is, in general, impossible.

  You might be confusing raytracing with scanline-rendering of triangle
meshes. In a mesh renderer this feature would certainly be possible
because you can always automatically subdivide triangles which form
sharp edges.

  Raytracing does not work this way. In raytracing each primitive type
is a mathematical surface, and the ray-surface intersection is calculated
with a specific mathematical formula.
  There's no generic way of smoothing sharp edges formed by these surface
formulas. The formula itself would have to be modified in a primitive by
primitive basis, and with many primitives this would not be very efficient,
if it's even possible.

  In a way this is a similar problem to not being able to apply non-linear
transformations to objects: Since this would require calculating the
intersection of a curve (instead of a line) and the surface, it starts
becoming prohibitively difficult and inefficient.

  You are free to make a suggestion on how this could be achieved in
raytracing.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Wasn't it Thomas A. Fine who wrote:
>Hi,
>
>After working for a bit with CSG objects, there's one feature that I
>want again and again, which would be massively, dramatically useful.
>
>If I could round the edges on objects automatically, without patching
>together lots of cylinders and spheres and toruses, life would be VASTLY
>simpler.

The problem is that such a facility is incredibly difficult to code in
such a way that it will work with all possible objects that can be
involved in a CSG. 

One thing that you might consider instead is to replace your primitive
objects with isosurfaces (perhaps using IsoCSG where necessary) and then
combine them by multiplying the surfaces and subtracting a small
constant.
See <http://www.econym.demon.co.uk/isotut/combine.htm#blob>

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Thomas A. Fine wrote:
> Hi,
> 
> After working for a bit with CSG objects, there's one feature that I
> want again and again, which would be massively, dramatically useful.
> 
> If I could round the edges on objects automatically, without patching
> together lots of cylinders and spheres and toruses, life would be VASTLY
> simpler.

Even if it was easy to implement (which it's not for all shapes), it
would be very slow (look at the roundbox isosurface, or the whole
ISO-CSG stuff by Christoph Hormann) and it would not
solve the problem of joints or holes in unions, intersections and
differences (you would still get hard edges at object encounters).

The all-CSG-days are over.  If you need round or beveled edges,
that's a job for a specialized modeler (there are some around,
like Wings3D), which makes this very easily.

Fabien.

Post a reply to this message

On Tue, 30 Nov 2004 09:30:23 +0100, Fabien Mosen
<fab### [at] skynetbemyshoes> wrote:
> it would be very slow (look at the roundbox isosurface

I do not have any measurements at hand but I'm pretty sure that while
isosurfaces are indeed slow in general, rounded box is one of fastest and
usefull application of them. Let's quote Gilles from making of
http://www.irtc.org/ftp/pub/stills/2001-12-31/gt_asia.jpg : "Rounded
isosurface boxes were used whenever possible."

ABX

Post a reply to this message

ABX wrote:
> 
> I do not have any measurements at hand but I'm pretty sure that while
> isosurfaces are indeed slow in general, rounded box is one of fastest and
> usefull application of them.

The idea that isosurfaces are inherently slow is completely wrong - in 
fact there are a lot of cases where isosurfaces are much faster than the 
analytical equivalent.  What probably makes people think this is that it 
is easy to make any fast isosurface very slow by using too large 
container, wrong max_gradient and accuracy or wrong function.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <41ab94b1$1@news.povray.org> , fin### [at] head-cfaharvardedu (Thomas
A. Fine) wrote:

> After working for a bit with CSG objects, there's one feature that I
> want again and again, which would be massively, dramatically useful.
>
> If I could round the edges on objects automatically, without patching
> together lots of cylinders and spheres and toruses, life would be VASTLY
> simpler.

This is the wrong group for this question.  This group is for discussion of
the POV-Ray source code.  POV-Ray feature suggestions should be posted in
povray.general. Platform-specific suggestions - that includes everything GUI
related or requests for GUI additions - should be posted in the group for
the appropriate platform.  Questions about using the POV-Ray should be asked
in either povray.general or povray.newusers.  Platform specific questions
should be asked in povray.windows, povray.unix or povray.macintosh .

    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message