"SharkD" <nomail@nomail> wrote:
> > No, this is what you may *think* is the point.
>
> Be nice. There's no reason this discussion can't remain civil.

I *am* nice and civil :) If I'd shout at you, IT WOULD LOOK LIKE *THIS*! :)

I'm just emphasizing, that's all. I'd use italics, not bold, if newsgroups had
any kind of markup.

(See my posts in povray.unix about that timer issue I had for what I'm like when
I'm upset :})


> Ah, I see now. This happens in the case of the heightfield as well. My only
> request is that this behavior be toggled on and off. With other shapes (such as
> the heightfield) it is easy to create the closed volume defined as being
> "inside" the object via an intersection with a box or other primitive. But with
> a mesh this is non-trivial.

That's also exactly the reason why POV-ray currently doesn't do it for you :)


> > Second, POV's plane is *defined* to actually not be a plane, but "everything
> > 'below' the plane", for CSG purposes.
>
> ....and the heightfield, and the disc, and, incidentally, the mesh.

No, currently this is not the case in POV-ray, although I agree that it might be
of use if it was.

But it would require some extra processing, and therefore extra coding, to get
it to work. It's not deliberately "turned off" in the code - it's just not
there now.

With the plane, it is easy because nothing needs to be done except define which
side of it is inside and which is outside. There are no additional faces that
need to be created somehow in POV.

With the disc and height field, it would be comparatively easy to add some
square or cylindrical extrusion to infinity on one side.

With the mesh, POV would have to painstakingly analyze every edge of every
triangle and check if there's another triangle joining it (and if there are
multiple other such triangles, check if their number is odd or even) in order
to find holes, plus it would need to set up some internal data structure to
represent the holes it finds, so it can ultimately extrude them to infinity to
define the surfaces needed in the CSG.

So yes, it could be done, but it would take quite some coding effort. Which,
these days, is mainly invested instead in getting POV multithreaded properly.

Post a reply to this message

SharkD nous illumina en ce 2008-12-11 00:16 -->
> "clipka" <nomail@nomail> wrote:
>> If the mesh is open I'd expect whacky results from CSG operations. For example,
>> if you intersect an open mesh and a solid object, the resulting object will
>> *not* behave like a "cut-out" piece of the mesh; instead, I'd expect certain
>> parts of the other object's surface to be visible as well, namely all those
>> areas where a ray, when shot along the inside vector, would enter through a
>> "hole" into the inside of the mesh. (This is just a guess, but be prepared to
>> get something like this or similar.)
> 
> My mesh is completely flat. If anything lying above the mesh upward until
> infinity is considered "inside", that's OK.
> 
> Also, where do I put the "inside_vector" statement? Inside the triangle, or
> inside the mesh?
> 
> -Mike
> 
> 
A completely flat, 2D mesh will probably don't work in a CSG intersection or 
difference.

In you difference that mesh from a solid, you will remove zero volume, an 
infinitely thin sheet from whatever other objet you may have.
If you difference a solid from your mesh, it will cut a hole in it.

In the case of an intersection, there will be no volume left, and you'll get an 
empty object, or maybe, just a piece of plane.

You can always use that mesh in an union or merge without any problem.



-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you read each of these quotes.
Mike Weber

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> A completely flat, 2D mesh will probably don't work in a CSG intersection or 
> difference.

> In you difference that mesh from a solid, you will remove zero volume, an 
> infinitely thin sheet from whatever other objet you may have.
> If you difference a solid from your mesh, it will cut a hole in it.

  You could say the same from the 'plane' primitive, but of course it
doesn't work like that.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Alain <ele### [at] netscapenet> wrote:
>> A completely flat, 2D mesh will probably don't work in a CSG intersection or 
>> difference.
> 
>> In you difference that mesh from a solid, you will remove zero volume, an 
>> infinitely thin sheet from whatever other objet you may have.
>> If you difference a solid from your mesh, it will cut a hole in it.
> 
>   You could say the same from the 'plane' primitive, but of course it
> doesn't work like that.
> 

Isn't this a bounding box problem?

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> I'm a little confused by the docs when they explain when meshes can be used in
> CSG. Can I, for instance, create a flat plane from a mesh and use it in CSG as
> long as I specify an inside vactor? Or, must a mesh be fully enclosed, like a
> cube? Please explain what happens in either case.
>
> -Mike

CSG with meshes (even open meshes) should work as long as the mesh is well
behaved:
-mesh is continuous withing the CSG region
-mesh normals are properly defined and oriented
-inside vector included
This helps POV to determine what is in or out.  In the bathtub pic I posted
recently, the water is actually an intersection of an open mesh and a
heightfield and it worked no problem once I made the mesh well-behaved.

For meshes that are non-well-behaved, they may or may not work as expected.

-tgq

Post a reply to this message

Dan Connelly <djc### [at] yahoocom> wrote:
> Isn't this a bounding box problem?

Nope.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> CSG with meshes (even open meshes) should work as long as the mesh is well
> behaved:
> -mesh is continuous withing the CSG region

In the example we're discussing, this is exactly the problem.

Post a reply to this message

Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> -mesh normals are properly defined and oriented

  I don't think that has any effect on CSG calculations.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > -mesh normals are properly defined and oriented
>
>   I don't think that has any effect on CSG calculations.

Probably not; it will become a problem though for meshes with a different inside
texture, some optimizations for artifact suppression (if there are, or ever
might be, such things) might fail to kick in, and I'd expect it to have the
potential of messing up one's bump maps, so it's generally a good idea to keep
one's eyes peeled for such issues.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> > -mesh normals are properly defined and oriented
>
>   I don't think that has any effect on CSG calculations.
>
> --
>                                                           - Warp

You are right, probably not.  But it is still good practice to have it.

-tgq

Post a reply to this message