POV-Ray : Newsgroups : povray.pov4.discussion.general : rounded intersections? Server Time
25 Feb 2024 07:22:06 EST (-0500)
  rounded intersections? (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
From: Reactor
Subject: Re: rounded intersections?
Date: 26 Sep 2008 21:25:01
Message: <web.48dd8a66a8641a455355f0430@news.povray.org>
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

From: Warp
Subject: Re: rounded intersections?
Date: 27 Sep 2008 05:10:05
Message: <48ddf86d@news.povray.org>
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

From: scott
Subject: Re: rounded intersections?
Date: 1 Oct 2008 06:09:25
Message: <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.


Post a reply to this message

From: Rarius
Subject: Re: rounded intersections?
Date: 1 Oct 2008 06:53:34
Message: <48e356ae$1@news.povray.org>
"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

From: scott
Subject: Re: rounded intersections?
Date: 1 Oct 2008 08:33:19
Message: <48e36e0f$1@news.povray.org>
> 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

From: Warp
Subject: Re: rounded intersections?
Date: 1 Oct 2008 09:37:22
Message: <48e37d11@news.povray.org>
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

From: scott
Subject: Re: rounded intersections?
Date: 2 Oct 2008 09:11:16
Message: <48e4c874$1@news.povray.org>
>> >  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

From: Warp
Subject: Re: rounded intersections?
Date: 2 Oct 2008 11:54:57
Message: <48e4eed1@news.povray.org>
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

From: scott
Subject: Re: rounded intersections?
Date: 2 Oct 2008 14:11:09
Message: <48e50ebd$1@news.povray.org>
>  That doesn't change the fact that the CAD software tesselates the surface
> before rendering it.

That was nothing to do with my point though, my point was that CAD software 
creates rounds without tesselating first.


Post a reply to this message

From: Reactor
Subject: Re: rounded intersections?
Date: 2 Oct 2008 14:35:00
Message: <web.48e5143fa8641a457dda34760@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
> 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.

Warp, I wish you hadn't said that, as I spent many minutes trying to picture a
macro that would allow for rounded differences between boxes.  As it turns out,
that would actually be very simple, so I started thinking about differences
between boxes, spheres, cones, cylinders, and tori.  I think it could be done,
but I don't think I'd want to do it.



That doesn't mean I won't try, though.  As for intersections, that might be a
bit beyond me right now.


-Reactor


Post a reply to this message

<<< Previous 2 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.