 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
