> - Two cylinders of different radii R_1 and R_2, intersecting each other
> (perpendicular and with intersecting axes, for starters), with a
> "melting" inset radius of R_i.
>
> - Three planes intersecting each others (perpendicular, for starters),
> with different radii for the "melting" insets between the pairs, R_i_1,
> R_i_2 and R_i_3. Of course the corner where the three planes meet is
> also expected to be smooth.
>
> This might give you a /basic/ idea of the fundamental challenges involved.

The above are both a piece of cake for CAD software (see images 
attached) - but I hate to imagine the maths/algorithms behind this. 
Hopefully the images backup the idea that this would be *hard* to do in 
the general case.

Post a reply to this message

Attachments:
Download 'croppercapture[46].png' (96 KB) Download 'croppercapture[47].png' (53 KB)

Preview of image 'croppercapture[46].png'

Preview of image 'croppercapture[47].png'

Yes, exactly. Well recognized what I talk about. A hell to develop, I am
sure, but hell needed, too.  :-)

Post a reply to this message

Am 22.12.2015 um 18:24 schrieb Sven Littkowski:
> Yes, exactly. Well recognized what I talk about. A hell to develop, I am
> sure, but hell needed, too.  :-)

I think here's your fundamental problem:

- You experience something as a hell to get right.

- You ask others to do it for you, apparently expecting them to just
wave their magic wand and make it happen.


One of the hard facts of life: There's no fairy.

Wir kochen alle nur mit Wasser.

Post a reply to this message

True. But using water for our preparations, we're able to create such
amazing things like pies, cakes, cookies, soups (including the delicious
delicious Tom Kha Tai), Jamaican jerk pork, Jamaican chicken run down,
strange English plumpudding, German and international beer, fruit
juices, not so very healthy sodas (including the delicious ginger ale),
mashed potatoes, cooked rice, and so on.

But besides, your point is understood.   ;-)

Post a reply to this message

> Yes, exactly. Well recognized what I talk about. A hell to develop, I am
> sure, but hell needed, too.  :-)

Although there are some similarities between the way you build objects 
(CSG) in POV and CAD, the way it works internally is very different. The 
way POV does it is simply not suited to adding "rounds".

Take an example of subtracting a cylinder from a box, to get a box with 
a hole through the middle:

In CAD, the software will first create a boundary representation (brep) 
of the box. In the case of a box it's just six planes, each bounded by a 
rectangle. Note the brep is not a triangle-mesh, but a list of bounded 
mathematical surfaces that define the exterior surface of the solid 
geometry exactly. Next, when you subtract the cylinder, the CAD software 
will start with the box brep data and modify it to include the hole. 
You'll end up with a longer list of curved surfaces and planes bounded 
by curves and straight edges.

In POV, it literally just stores the box and cylinder, with a flag to 
say the cylinder is subtracted. Nothing else is calculated or stored. 
There is no concept of the "edge" between the two stored anywhere at 
all. It's only when you come to raytrace the scene, pixel-by-pixel, that 
the edge appears in the image.

Now consider how to add a round on this shape. In the CAD software it's 
just a matter of choosing the edge from the ones in the brep, and 
replacing it with a curved surface following that edge (and adding in 
suitable boundaries for the other surfaces affected). In POV no such 
edge exists, so you can't even choose where to apply the round! What you 
would need to do, is write specific code for every possible combination 
of shape intersections (sphere-sphere, sphere-cylinder, sphere-box, 
box-cylinder, ...) AND handle every possible case where one of the 
shapes is already bounded by another shape. That is *a lot* of maths and 
*a lot* of combinations that need to be figured out and hand-coded. It 
might not even be possible mathematically for some combinations.

The only feasible way for POV to be able to have this feature is for it 
to follow the CAD way of doing things and keep a brep of the shape. But 
this would be a gigantic undertaking from the way shapes are defined and 
stored, the way CSG is calculated, and how the raytracing intersections 
are done. IMHO it would then be a different piece of software rather 
than an "update" or "patch".

BTW there are free CAD packages available that do what you want, eg:

http://www.freecadweb.org/

Post a reply to this message

Yes, point taken. I wished, POV-Ray could export scenes (as meshes) into
the formats of other raytracers, so I could create the rounded edges
there as meshes and export them back into a mesh that POV-Ray understands.

Beside the Bishop modeller, are there other programs that can understand
the POV-Ray format of pre-defined shapes?

Post a reply to this message

> Beside the Bishop modeller, are there other programs that can understand
> the POV-Ray format of pre-defined shapes?

I'm not aware of any other software that can directly read a POV SDL file.

Your best bet is to use a 3D modeller or CAD package to design your 
complex shapes with rounds, then export as a mesh to render in POV.

Or, if you are using simple shapes, create the geometry for the rounds 
manually yourself in POV. It's a good exercise in maths, geometry and 
CSG :-)

Post a reply to this message

Yes, I could easily do that, where there is a 90° angle where they hit
each other. But at one location, it is a torus. There I would fail.  :-)

Besides, I achieved my wish with the blob I have created. Wasn't been
easy, but it is good enough now.

Post a reply to this message

Le 15-12-23 04:51, Sven Littkowski a écrit :
> Yes, point taken. I wished, POV-Ray could export scenes (as meshes) into
> the formats of other raytracers, so I could create the rounded edges
> there as meshes and export them back into a mesh that POV-Ray understands.
>
> Beside the Bishop modeller, are there other programs that can understand
> the POV-Ray format of pre-defined shapes?
>

I recently looked at the list of the include files and stumbled on the 
Meshmaker.inc file.
Some macros from that include have the option to export as .OBJ and .PCM 
files. Those can't be read back by POV-Ray, but can be used by other 
packages.
Those are:
BuildWriteMesh2()
Prism1()
Lathe()
Coons()

The type of objects they can generate is quite limited, but can probably 
simulate most primitives with some work.

Post a reply to this message

Thanks, Alain. This is one more helpful and good advise I saw from you.  :-)

And merry Christmas.

Post a reply to this message