"clipka" <nomail@nomail> wrote:
> Hm... what do you need a completely flat mesh for?
>
> Anyway, if it's OK for you to get unexpected effects *above* the mesh for
> differences and intersections (I guess unions shouldn't be too problematic in
> this respect) then you'd want an inside_vector of -y, i.e. pointing *downward*.

I've done some tests with my mesh, and difference seems to work OK, but
intersections doesn't work so great.

http://i421.photobucket.com/albums/pp292/SharkD2161/Support/gh_test_difference.png
http://i421.photobucket.com/albums/pp292/SharkD2161/Support/gh_test_intersection.png

If you look closely at the intersection you'll see that the object is not solid
(there are no walls). Instead, it seems to work more like clipped_by.

-Mike

Post a reply to this message

> In fact, my understanding is whether it is closed or not is irrelevant.  
> Even if you define a simple closed polyhedron,  if you don't have an 
> inside_vector defined properly, the system has no way of determining if 
> that's a finite solid or a hole in an infinite solid.


As is often the case, my understanding was flawed.... there's no way to define a mesh
which is a hole in an infinite solid without CSG.  So a closed mesh really is
unambiguous, assuming no numerical issues.

Dan

Post a reply to this message

Dan Connelly <djc### [at] yahoocom> wrote:
> As is often the case, my understanding was flawed.... there's no way to define a
mesh which is a hole in an infinite solid without CSG.  So a closed mesh really is
unambiguous, assuming no numerical issues.

  Well, I don't really know what you mean by "ambiguous".

  An open mesh with a given inside_vector is completely unambiguous in its
behavior as a solid (in CSG). Its behavior may be slightly counter-intuitive
in that part of the "inside" of the mesh will extend to infinity, but this
no different from how eg. a plane works: One side of the plane is considered
the "inside", and this inside extends to infinity.

  To understand how this works, the simplest case would be eg. a mesh with
one single triangle. Let's say this triangle is on the xz-plane (with the
y coordinates of the vertices being all 0), and an "inside_vector y".
Basically this mesh now forms an infinite triangular prism solid (which
extends from y=0 towards the negative y axis direction). It's just that
this "prism" as only the "end cap" (the triangle in question) but no
visible "walls". However, in CSG it will behave like it had them.

  (Disclaimer: No, I haven't actually tested it actually works like this.
However, knowing the algorithm used for the insideness test, I can't think
how it could work in any other way.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   To understand how this works, the simplest case would be eg. a mesh with
> one single triangle. Let's say this triangle is on the xz-plane (with the
> y coordinates of the vertices being all 0), and an "inside_vector y".
> Basically this mesh now forms an infinite triangular prism solid (which
> extends from y=0 towards the negative y axis direction). It's just that
> this "prism" as only the "end cap" (the triangle in question) but no
> visible "walls". However, in CSG it will behave like it had them.

  Btw: Bounding boxes might actually make it not behave like an infinite
prism. The "prism" might be limited by the size of the bounding box created
for the mesh. As I said, I haven't tested it.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   To understand how this works, the simplest case would be eg. a mesh with
> one single triangle. Let's say this triangle is on the xz-plane (with the
> y coordinates of the vertices being all 0), and an "inside_vector y".
> Basically this mesh now forms an infinite triangular prism solid (which
> extends from y=0 towards the negative y axis direction). It's just that
> this "prism" as only the "end cap" (the triangle in question) but no
> visible "walls". However, in CSG it will behave like it had them.

Quite so, yes. It should be noted though that the CSG operations will *not* make
the invisible walls visible (because PoV-ray can't make anything visible except
ray-surface intersection points, and for the purpose of *this* test the "prism
walls" don't exist). So even in CSG, it will behave like it had those
"invisible walls" *only* with respect to what can be seen of the other objects'
surfaces in the CSG construct.

- In Unions, there should be no effect at all on the other objects
- In Merges, parts of the other objects which are "inside" the "mesh prism"
should be invisible
- In Intersections, parts of the other objects which are "outside" the "mesh
prism" should be invisible

(Note that differences can be regarded as an intersection between the first
object and inverted versions of the others.)


Therefore, the visible effect of this "prism" defined by the mesh and the inside
vector will be limited to hiding (or not hiding) parts of the other object's
surface.

In addition, bounding boxes may interact with this, because a bounding box based
inside-test will definitely be "cheaper" than the test-ray based approach, so I
guess it's actually implemented.


>   (Disclaimer: No, I haven't actually tested it actually works like this.
> However, knowing the algorithm used for the insideness test, I can't think
> how it could work in any other way.)

Same goes for me.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   To understand how this works, the simplest case would be eg. a mesh with
> one single triangle. Let's say this triangle is on the xz-plane (with the
> y coordinates of the vertices being all 0), and an "inside_vector y".
> Basically this mesh now forms an infinite triangular prism solid (which
> extends from y=0 towards the negative y axis direction). It's just that
> this "prism" as only the "end cap" (the triangle in question) but no
> visible "walls". However, in CSG it will behave like it had them.

This is exactly the behavior I was expecting, however in my tests this isn't in
fact the case. See my previous post.

-Mike

Post a reply to this message

SharkD wrote:
> If you look closely at the intersection you'll see that the object is not
> solid (there are no walls). Instead, it seems to work more like
> clipped_by.

Are there walls in the difference?

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> I've done some tests with my mesh, and difference seems to work OK, but
> intersections doesn't work so great.
>
> http://i421.photobucket.com/albums/pp292/SharkD2161/Support/gh_test_difference.png
> http://i421.photobucket.com/albums/pp292/SharkD2161/Support/gh_test_intersection.png
>
> If you look closely at the intersection you'll see that the object is not solid
> (there are no walls). Instead, it seems to work more like clipped_by.
>
> -Mike

I tried nesting the first difference within another difference, but the result
is the same.

-Mike

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > If you look closely at the intersection you'll see that the object is not
> > solid (there are no walls). Instead, it seems to work more like
> > clipped_by.
>
> Are there walls in the difference?

Yes. I provided links to the renders in my message, so you can see for yourself.

In beta 29 the results are similar, except the road surface is missing a pigment
(which I'm actually not worried about).

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> This is exactly the behavior I was expecting, however in my tests this isn't in
> fact the case. See my previous post.
>
> -Mike

Here's a simple example. The intersection works; but change the intersection to
a difference and it's wonky.

-Mike

camera
{
 location  -z * 6
 look_at   0
 right     x*image_width/image_height
 rotate x * 30
 rotate y * -30
}

light_source
{
 <-3, 9, -3>
 color rgb 1
 parallel
}

plane
{
 y, 0
 pigment {color rgbt <0,0,1,1/4,>}
}

difference
{
 box
 {
  -1, 1
 }
 mesh
 {
  smooth_triangle { 0,  y,  x,  y,  z,  y}
  inside_vector y
  translate y*2
 }
 pigment {color rgbt <1,1,1,1/4,>}
}

Post a reply to this message