"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

Hmmm, Ok.

Then, maybe we can proceed as follow. Consider the zone that we want to smooth
out. Let's say for that this zone of pixels in the 2D imaage is a disk to
simplify for the moment. The circle of pixels around the disk have corresponding
impact points in the 3D scene. THe impact points draw a curve in the 3D scene.
We consider the cone C with center the eye of the camera built on this impact
curve. On the other hand, we may build a simple mesh M whose perimeter is the
impact curve and this mesh would corresponding to the rounded corner. This mesh
could be produced by averging the normal at the impact points with some filter.

Now we build a new scene. If S is the original scene, the new scene
is S minus the cone C union the mesh M. Then povray computes the pixels
of this new scene ( only the pixels in the zone to smooth).

The rendering finally is the rendering of the initial scene, modified by the
insertion of the pixels from the new scene in the zone that we want to smooth.


Laurent.




clipka <ano### [at] anonymousorg> wrote:
> 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

> On the other hand, we may build a simple mesh M whose perimeter is the
> impact curve and this mesh would corresponding to the rounded corner. This mesh
> could be produced by averging the normal at the impact points with some filter.

You'll need much more than the "impact curve" in order to build the 
mesh. You'll need to know exactly what the surface is either side of the 
sharp edge, so you know where to finish the mesh. If you can imagine, a 
very sharp "V" channel will need a very different mesh to a more relaxed 
angle, or one with complex curved surfaces on each side.

Also what happens when the sharp edge / impact curve that is needed to 
create the round is not visible in the image (because it's obscured by 
another part of the shape or just pointing away from the camera)? 
Attached example.

Post a reply to this message

Attachments:
Download 'croppercapture[4].png' (52 KB)

Preview of image 'croppercapture[4].png'

This has been a fascinating discussion. The conclusion seems to be that a
general purpose fillet/round provision is not realistic.

However I wonder if there are limited cases where solutions can be found, for
example

All CSG objects that contain only spheres and sphere sweeps etc., fillets could
be defined by blobbing, although I think this could be made more general and
intuitive.

The intersection of two conic section primitives, will itself be a conic
section, so that an equation for it could be written for an extra CSG component
in the form of a sphere sweep following that equation. All under the hood of
course!

Maybe there are other limited cases where in the same way an equation can be
written so that the fillet can be defined as a CSG component.

Post a reply to this message

On 06/09/2016 10:54, John Greenwood wrote:
> This has been a fascinating discussion. The conclusion seems to be that a
> general purpose fillet/round provision is not realistic.
>
> However I wonder if there are limited cases where solutions can be found, for
> example
>
> All CSG objects that contain only spheres and sphere sweeps etc., fillets could
> be defined by blobbing, although I think this could be made more general and
> intuitive.
>
> The intersection of two conic section primitives, will itself be a conic
> section, so that an equation for it could be written for an extra CSG component
> in the form of a sphere sweep following that equation. All under the hood of
> course!

The sphere sweep doesn't follow the intersection curve, that would give 
you a "bead" along the edge. The sphere sweep needs to be offset a 
variable amount to ensure that the contact between the sphere sweep and 
both CSG surfaces is exactly tangent along the whole length. Then the 
CSG is not trivial, you need just the bit of material between the sphere 
sweep object and the two surfaces.

I'm not saying it's impossible, just a lot more complex than it first 
seems. Try writing it as an SDL macro first - if it works well then 
maybe it will get implemented natively...

Post a reply to this message