Hi all,

This is my first post. I tried searching the forum, be couldn't find what I'm
looking for ...

Can I difference the same object on itself?
I tried it and no error comes up, but the scene is empty.
Thanks, Dick

Code:

difference {
 object {
  myBox
  translate <0, 0, 0>
  scale <1, 1, 1>
 }
 object {
  myBox
  translate <0.25, -0.01, 0.25>
  scale <0.5, 1.01, 0.5>
 }
}

Post a reply to this message

Dicko <dic### [at] gmailcom> wrote:
> Can I difference the same object on itself?
> I tried it and no error comes up, but the scene is empty.

You can, but the problem with a mesh object is that it's not solid and
therefore cannot be used in CSG as-is.

You are in luck, however, because a mesh can be made solid by using the
keyword "inside_vector" followed by a direction (something like <1, 0, 0>
will usually work just fine) and thus it should work in CSG.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Dicko <dic### [at] gmailcom> wrote:
> > Can I difference the same object on itself?
> > I tried it and no error comes up, but the scene is empty.
>
> You can, but the problem with a mesh object is that it's not solid and
> therefore cannot be used in CSG as-is.
>
> You are in luck, however, because a mesh can be made solid by using the
> keyword "inside_vector" followed by a direction (something like <1, 0, 0>
> will usually work just fine) and thus it should work in CSG.
>
> --
>                                                           - Warp

Yes, warp is right completelly. You can put the inside statement immediately
before the closing bracket "}" of the mesh2-definition, the direction itself is
not important but the inside_vector must exist. Then you can use mesh2-objects
with CSG-operations like differences or intersections as with the other
POV-primitives.

Best regards,
Michael

Post a reply to this message

MichaelJF <mi-### [at] t-onlinede> wrote:
> Yes, warp is right completelly. You can put the inside statement immediately
> before the closing bracket "}" of the mesh2-definition, the direction itself is
> not important but the inside_vector must exist.

(One might ask that if the direction is not important, then why it has to
be specified. The direction is not important only for *closed* meshes. For
open meshes it makes a huge difference which direction you choose.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> MichaelJF <mi-### [at] t-onlinede> wrote:
> > Yes, warp is right completelly. You can put the inside statement immediately
> > before the closing bracket "}" of the mesh2-definition, the direction itself is
> > not important but the inside_vector must exist.
>
> (One might ask that if the direction is not important, then why it has to
> be specified. The direction is not important only for *closed* meshes. For
> open meshes it makes a huge difference which direction you choose.)
>
> --
>                                                           - Warp

Ah, yes, you are right. But as I understand it so far, open meshes are a problem
even with a proper inside_vector.

Michael

Post a reply to this message

> Hi all,
>
> This is my first post. I tried searching the forum, be couldn't find what I'm
> looking for ...
>
> Can I difference the same object on itself?
> I tried it and no error comes up, but the scene is empty.
> Thanks, Dick
>
> Code:
>
> difference {
>   object {
>    myBox
>    translate <0, 0, 0>
>    scale <1, 1, 1>
>   }
>   object {
>    myBox
>    translate <0.25, -0.01, 0.25>
>    scale <0.5, 1.01, 0.5>
>   }
> }
>
>

If your object is a regular, solid, primitive, or union of regular 
primitives, as you translate and unevenly scale the second instance, you 
should see something, unless the camera is not looking in the correct 
direction.
You also need some light source or it's going to be very dark.

If your object "myBox" is a regular primitive, declared like this or 
similarly:

#declare myBox = box{<-1,-1,-1>,<1,1,1> rotate<1,2,3> scale<0.7,1,2>}

You should have no problem.


If your myBox object is a mesh, or composed of a collection of polygons 
or any other "patch" object, you are heading for some problems.
For a mesh, take the advice of Warp, it's very good.
Just make sure that the inside_vector is not parallel to a face as it 
can confuse the insideness tests.

If you use a collection of polygons, the inside_vector will not work.
Same thing apply for the bicubic_patch.
If you have an union of triangles, make it into a mesh by replacing 
"union{" by "mesh{" and add an inside_vector, like "inside_vector 1".




Alain

Post a reply to this message

MichaelJF <mi-### [at] t-onlinede> wrote:
> Ah, yes, you are right. But as I understand it so far, open meshes are a problem
> even with a proper inside_vector.

How so? I don't think there are any more of a problem as eg. heightfields.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> MichaelJF <mi-### [at] t-onlinede> wrote:
> > Ah, yes, you are right. But as I understand it so far, open meshes are a
> > problem even with a proper inside_vector.
>
> How so? I don't think there are any more of a problem as eg. heightfields.
>

With a standard HF, an inside_vector of <0,-1,0> (or maybe <0,1,0>) would always
work, AFAIU. But for, say, a spherical mesh with a hole in it--i.e., not a
closed mesh-- a specially-chosen inside_vector may work *most* of the time, but
perhaps not always. I think it depends on the location of the CSG object--where
it happens to intersect the mesh.  I've run into that problem myself.

Post a reply to this message

Kenneth <kdw### [at] gmailcom> wrote:
> With a standard HF, an inside_vector of <0,-1,0> (or maybe <0,1,0>) would always
> work, AFAIU. But for, say, a spherical mesh with a hole in it--i.e., not a
> closed mesh-- a specially-chosen inside_vector may work *most* of the time, but
> perhaps not always. I think it depends on the location of the CSG object--where
> it happens to intersect the mesh.  I've run into that problem myself.

The hole would simply extend to infinity and act as an "interior" (or
"exterior" depending on which direction the inside_vector is pointing.)
It might not be the desired behavior, but it should be pretty consistent
and predictable.

-- 
                                                          - Warp

Post a reply to this message