 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can I revive the request for a fillets and rounded corners tool?
These are standard issue in mechanical CAD packages, so can't be that difficult!
I think they are generally invoked by selecting specific corners or adjacent
pairs of faces and specifying the radius. The programme tells you if it can't be
done.
Even a very limited tool would be useful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.08.2016 um 18:55 schrieb John Greenwood:
> Can I revive the request for a fillets and rounded corners tool?
>
> These are standard issue in mechanical CAD packages, so can't be that difficult!
Oh yes, they can!
Internally, mechanical CAD packages typically translate each and every
shape into some single type of boundary representation model (based on
e.g. triangle meshes or NURBS surfaces), and work with those instead of
the underlying primitives.
Once translated to this b-rep model, it is more or less trivial to:
(1) find edges where shapes meet;
(2) describe those edges in a standardized fashion; and
(3) apply modifications to the b-rep geometry, such as rounding a given
edge.
POV-Ray does not go via such a b-rep model, but directly uses the very
fundamental geometric shapes, making /every/ of the above steps
virtually impossible. (Quiz: how would you find the edge between an
isosurface and a sphere? How would you describe it? And how would you
modify the isosurface and sphere to actually generate the rounded edge?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Am 27.08.2016 um 18:55 schrieb John Greenwood:
>> Can I revive the request for a fillets and rounded corners tool?
>>
>> These are standard issue in mechanical CAD packages, so can't be that difficult!
>
> Oh yes, they can!
>
> Internally, mechanical CAD packages typically translate each and every
> shape into some single type of boundary representation model (based on
> e.g. triangle meshes or NURBS surfaces), and work with those instead of
> the underlying primitives.
>
> Once translated to this b-rep model, it is more or less trivial to:
>
> (1) find edges where shapes meet;
> (2) describe those edges in a standardized fashion; and
> (3) apply modifications to the b-rep geometry, such as rounding a given
> edge.
>
> POV-Ray does not go via such a b-rep model, but directly uses the very
> fundamental geometric shapes, making /every/ of the above steps
> virtually impossible. (Quiz: how would you find the edge between an
> isosurface and a sphere? How would you describe it? And how would you
> modify the isosurface and sphere to actually generate the rounded edge?)
>
Yep! Easy, almost trivial, to do with mesh based geometry, but nearly
impossible to do with mathematically based geometry.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotron ca> wrote:
> > Am 27.08.2016 um 18:55 schrieb John Greenwood:
> >> Can I revive the request for a fillets and rounded corners tool?
> >>
> >> These are standard issue in mechanical CAD packages, so can't be that difficult!
> >
> > Oh yes, they can!
> >
> > Internally, mechanical CAD packages typically translate each and every
> > shape into some single type of boundary representation model (based on
> > e.g. triangle meshes or NURBS surfaces), and work with those instead of
> > the underlying primitives.
> >
> > Once translated to this b-rep model, it is more or less trivial to:
> >
> > (1) find edges where shapes meet;
> > (2) describe those edges in a standardized fashion; and
> > (3) apply modifications to the b-rep geometry, such as rounding a given
> > edge.
> >
> > POV-Ray does not go via such a b-rep model, but directly uses the very
> > fundamental geometric shapes, making /every/ of the above steps
> > virtually impossible. (Quiz: how would you find the edge between an
> > isosurface and a sphere? How would you describe it? And how would you
> > modify the isosurface and sphere to actually generate the rounded edge?)
> >
>
> Yep! Easy, almost trivial, to do with mesh based geometry, but nearly
> impossible to do with mathematically based geometry.
Does povray knows for each pixel on the rendered image to which surface it
corresponds and what is the normal at this point ? I suppose yes. If so, this is
maybe possible to do something on the rendered image...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"lelama" <nomail@nomail> wrote:
> > Yep! Easy, almost trivial, to do with mesh based geometry, but nearly
> > impossible to do with mathematically based geometry.
I'm not quite sure you mean to say exactly that - mathematical geometry
interfaces where the equations for those geometries are equal, or put another
way, one minus the other is zero.
I think the problem that often arises is that a user's perspective of how
POV-Ray generates an image through "the rendering equation" is a lot different
than how someone who programs the algorithms sees it.
Correct me if I'm wrong, but POV-Ray does not "know" anything about the overall
scene and the objects that comprise it.
It systematically follows a ray, and uses a lot of data from the parser and
internal functions to evaluate the RGB value of a pixel. Then it moves to the
next ray / pixel.
I think that someday a visual diagram, or flowchart showing how a few
representative pixels are evaluated would help people understand both the
complexity, and simplicity of the process. It would give a better sense of the
advantages drawbacks, the capabilities and limitations.
Perhaps easier, might be to just make a special demo edition that writes out to
a text file what's actually going on at each step in the source code for every
100th or 1000th pixel. I'm sure it would be an eye-opener. ;)
> Does povray knows for each pixel on the rendered image to which surface it
> corresponds and what is the normal at this point ? I suppose yes. If so, this is
> maybe possible to do something on the rendered image...
I would suggest that if fillets and rounded corners are desired, that a library
of meshes that correspond to the primitives you want to use is created, and then
macros or whatever, are written to do what is claimed is easy to do with meshes.
I thought that maybe someone had investigated doing something like this in the
past - so many very talented people have written so many useful and inspiring
tools and macros and examples of very clever code.
I will have to look when this real life thing yields a few round tuits not
already reserved for other projects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And then of course you can try to blob things together such as:
http://wiki.povray.org/content/File:TutImgIso_17.png
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yep! Easy, almost trivial, to do with mesh based geometry, but nearly
>> impossible to do with mathematically based geometry.
>
> Does povray knows for each pixel on the rendered image to which surface it
> corresponds and what is the normal at this point ? I suppose yes. If so, this is
> maybe possible to do something on the rendered image...
No, it's not possible. Yes POV knows which surface/shape it has hit, but
it knows nothing about any other surfaces in the scene. The way the CSG
works in a raytracer, any surface is not known about (or
calculated/stored anywhere) until a ray actually hits it.
POV and CAD may seem to work the same way (you give both a list of
mathematical definitions of shapes and how to combine them) - but
internally they work very differently.
As an example, think of a simple union between a box and a sphere. Think
of all the possible different shapes you might end up with depending on
the relative position of the two, the relative sizes/scaling (which
could be non-uniform) and any rotations involved.
POV doesn't have to worry at all about all these options, or even do any
calculations about it. It simply goes along, pixel by pixel, and figures
out if the ray through that pixel hits the sphere or the box, and if it
hits both, which is closer to the camera. It doesn't care, or know, what
the overall shape looks like, it has no concept of how many surfaces or
edges are involved, it doesn't matter.
CAD works by calculating an exact representation of the geometry first.
It will calculate exactly where all the intersection lines are between
the two solids, defining all the new surfaces as bounded planes or
bounded spherical sections (in this example). As you can imagine this is
a lot of geometrical calculations with many "special cases" to deal
with, and the result can be quite complex even for this simple example.
At the end though, it will have a list of surfaces and edges that make
up the final shape. To "render" it, it is relatively trivial to then
mesh this geometry representation (most CAD software gives you options
for how detailed to mesh the geometry for display purposes).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.08.2016 um 21:50 schrieb lelama:
> Does povray knows for each pixel on the rendered image to which surface it
> corresponds and what is the normal at this point ? I suppose yes. If so, this is
> maybe possible to do something on the rendered image...
Nope; at the time POV-Ray assembles the image, it has already forgotten
entirely how it came up with the colour values for the individual pixels.
"Knowing for each pixel to which surface it corresponds" is also far
less trivial than it sounds; take a glass sphere, for example: Does the
pixel correspond to the surface of the sphere, or rather to the object
behind it? And what about that other object seen as a reflection?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you Christoph for the remark. I didn't have transparency,
semi-transparency in mind.
If it's not possible for each pixel to know the corresponding impact point, the
idea I have in mind won't work,
Thus I discuss with the hypothesis that it is possible to know the impact point
and the normal at the impact point of the ray ( maybe after tweaking the povray
code) .
Please forgive me in advance if some of the ideas are too naive. I don't know
the code of Povray, and there are obviously many difficulties that I'm not aware
of.
It seems to me that the visual inconsistancy comes in the boolean operations
at the intersection of two surfaces. For each
pixel, we associate the impact surface. If we find 2 *adjacent* pixels which
involve two different surfaces which appear in a boolean operation, then
there may be a visual problematic corner at this pair of points.
Among all these potential problematic junctions, we need to eliminate some of
them depending of some parameters ( distance between the impact points,
variation of the normal...)
We end up with a list of problematic pairs of points. Starting from a
problematic pair of point, which are more or less on the fillets, we construct a
zone of pixels around this pair corresponding to pixels whose impact is in a
zone that we want to smooth.
We then reach a list of pixels corresponding to zones that we want to smooth.
Then we apply an averaging filter on each zone.
There are obviously plenty of technical details to be fixed. This is just a
starting idea to round the corners without computing intersections with meshes.
Laurent.
clipka <ano### [at] anonymousorg> wrote:
> Am 30.08.2016 um 21:50 schrieb lelama:
>
> > Does povray knows for each pixel on the rendered image to which surface it
> > corresponds and what is the normal at this point ? I suppose yes. If so, this is
> > maybe possible to do something on the rendered image...
>
> Nope; at the time POV-Ray assembles the image, it has already forgotten
> entirely how it came up with the colour values for the individual pixels.
>
> "Knowing for each pixel to which surface it corresponds" is also far
> less trivial than it sounds; take a glass sphere, for example: Does the
> pixel correspond to the surface of the sphere, or rather to the object
> behind it? And what about that other object seen as a reflection?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.09.2016 um 19:10 schrieb lelama:
> It seems to me that the visual inconsistancy comes in the boolean operations
> at the intersection of two surfaces. For each
> pixel, we associate the impact surface. If we find 2 *adjacent* pixels which
> involve two different surfaces which appear in a boolean operation, then
> there may be a visual problematic corner at this pair of points.
>
> Among all these potential problematic junctions, we need to eliminate some of
> them depending of some parameters ( distance between the impact points,
> variation of the normal...)
>
> We end up with a list of problematic pairs of points. Starting from a
> problematic pair of point, which are more or less on the fillets, we construct a
> zone of pixels around this pair corresponding to pixels whose impact is in a
> zone that we want to smooth.
>
> We then reach a list of pixels corresponding to zones that we want to smooth.
> Then we apply an averaging filter on each zone.
That won't suffice. Beveled corners have the tendency to also appear
brighter than the adjacent flat surfaces, due to highlights: A flat
surface has only a single direction from which light will produce a
highlight on that surface; a curved surface like a beveled edge has a
wide choice of directions from which light will produce a highlight
/somewhere/ on that surface. A simple post-processing averaging filter
can't create that effect out of thin air.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
