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

Le 06/09/2016 à 12:33, scott a écrit :
>>
>> 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.
>

Is sphere_sweep able to follow a circle ?

The Devil's advocate sets the following situation:
Two cylinders of identical diameter and axis in the same plane intersect 
each other with an angle of exactly 90°.

The intersection curve is a sheared circle whose minor radius is the 
radius of the cylinder and major radius is sqrt(2) time the radius of 
the cylinder.

You could sub-sample, but you cannot follow exactly a part of circle 
with a sphere_sweep (you need rational curve to do it).

Post a reply to this message

>> 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.
>>
>
> Is sphere_sweep able to follow a circle ?

Indeed, I didn't think of that limitation with sphere_sweep and 
following arcs.

> The Devil's advocate sets the following situation:
> Two cylinders of identical diameter and axis in the same plane intersect
> each other with an angle of exactly 90°.
>
> The intersection curve is a sheared circle whose minor radius is the
> radius of the cylinder and major radius is sqrt(2) time the radius of
> the cylinder.

And then ... what is the mathematical definition of the surface needed 
to create this simple round between these two cylinders (highlighted red 
in the attachment).  And for extra marks, make it general for any 
diameter, any plane, any offset (green in the attachment)... Should be 
easy, right, I mean this is just two cylinders intersecting...

Post a reply to this message

Attachments:
Download 'rounds2.png' (151 KB)

Preview of image 'rounds2.png'

I can change the texture around the fillets (for two objects only), but 
I'm afraid it would be a nightmare to make a real 3D shape for it.

(and I needed the proximity pattern of hgpovray)

It might be possible to have a pattern taking the children of a CSG to 
compute that kind of effect over a complete object :
* for each child, eval the proximity pattern --> V_i
* Find the two maximal values amongst V_i, multiply them

Post a reply to this message

Attachments:
Download 'pro.png' (115 KB) Download 'pro.pov.txt' (1 KB)

Preview of image 'pro.png'

Am 07.09.2016 um 15:41 schrieb Le_Forgeron:
> I can change the texture around the fillets (for two objects only), but
> I'm afraid it would be a nightmare to make a real 3D shape for it.
> 
> (and I needed the proximity pattern of hgpovray)
> 
> It might be possible to have a pattern taking the children of a CSG to
> compute that kind of effect over a complete object :
> * for each child, eval the proximity pattern --> V_i
> * Find the two maximal values amongst V_i, multiply them

Would using the proximity pattern in an isosurface do the trick?

Post a reply to this message

scott <sco### [at] scottcom> wrote:
>
>
> You'll need much more than the "impact curve" in order to build the
> mesh. [...]
>
> 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.




If some part is not visible, we don't care: The proposed algorithm starts from
the 2D image.

Let me give with some details the algorithm which computes the mesh of the
rounded corner for clarity.


Let us represent the pixels on the 2D image as squares on a chess board. Let us
call segment the piece of line which is at the interface of two adjacent squares
on the board. For each square s on the board, by the hypothesis, we have the
following parametrized data: an impact point p(s) in the 3D space, an object
o(s) which contains the impact point p(s), the normal n(s) at the impact point.
(Recall that I supposed that for each pixel in the rendering,  the impact
surface and the corresponding normal was accessible).


An sharpEdge is a segment such that the two adajacent squares s1,s2 on each side
verify:
- there are on two different surfaces o(s1)!=o(s2) and the user asked to smooth
the intersection of these two surfaces
- the distance between the two corresponding points p(s1) p(s2) in the 3d space
is small enough ( small depends on the user input parameters).

2 sharpEdges are called connected if
- they are connected on the chess board, ie they have in common the corner of a
square
- the two segments have the same objects on each side

( If unclear, The last condition may be described precisely as follows
- if the two edges form a right angle, the three squares s1,s2,s3 on the
exterior of the curve have the same object o(s1)=o(s2)=o(s3)
- it the two edges are along a line, and if s1 s2 are two squares adjacent to
the edges and on the same side of the edges, then o(s1)=o(s2)

If we put a set of connected edges together, we get a connected component of
sharpEdges. This is a ray that we see on the 2D image where we want to smooth.
After a moment of thouhgt, we see that a connected component is a set of
sharpEdges which is not a general tree, but a simple branch.  For instance, in
the example you propose, there are 3 connected components of straight edges :
one component for each pair of surface.

Thus now, we have a well defined branch, with 2 sides, which I call left and
right for simplicity, and we want to produce a mesh around this branch.
There is an object o(l) on the left of the branch and an object o(r) on the
right. By construction, all the squares adjacent to the left side
parametrize ray whose impact is in o(l) and same thing for the right.


Now, we delimit the zone around the branch that we shall smooth out. We
construct a set S(l) containing squares on the left side. The squares s in S(l):
- are connected to the left side of the branch
- are  sufficiently closed to the curve: ie there is s' adjacent to the curve
with p(s)-p(s') small enough
- have impact in the required surface ie o(s)=o(l)

The boundary of S(l) is a union of segments which is closed curve: this is a
deformed circles. More
precisely, it is a union of 2 pieces: the sharp edges that we are
trying to smooth out, and a residual piece which I call the left boundary
B(l).

Similarly, there is a right boundary B(r). THe union of B(l) and B(r) is a
closed curve around the connected component that I call the total boundary B.

The boundary B is a union of segments, and it is a deformed circle. We want to
smooth the zone corresponding to the squares inside B,

If a square s is in the circonference of the deformed circle, ie if it
adjacent to some segment in B, we keep unchanged the
information p(s),n(s),o(s) we started from.

For the other squares, which are inside the circle but not on the
circumferentce, we use an algorithm to interpolate the values
p(s),n(s),o(s) (basically by averaging while keeping the circumference
unchanged)

Once we have computed the values p(s),n(s),o(s) for s in B, this is easy to
produce the mesh.

Laurent.

Post a reply to this message

Am 08.09.2016 um 18:07 schrieb lelama:

> Let me give with some details the algorithm which computes the mesh of the
> rounded corner for clarity.

Given the unwavering enthusiasm you show for this topic, you should
probably go ahead and write a patch for POV-Ray ;)

Because, seriously, while I can't speak for the other active developers,
I know for a fact that I myself certainly won't.

I have participated in this discussion to show how complex the matter
is, in order to help you come to terms with what I believe to be the
hard truth: That your proposal will in all likelyhood not be picked up
by the official developers.

If you can demonstrate that your proposal works, can be implemented in
POV-Ray with reasonable effort, and produces reasonably good results,
then let me know, and I'll happily provide support to get it into
official POV-Ray; but until that happens, I personally am convinced that
it will not be worth spending any more time on it.

In other words: Everyone feel free to continue discussing this idea, but
count me out.

Post a reply to this message