Bill Pragnell wrote:
> SharkD <mik### [at] gmailcom> wrote:
> Quite simply, because I don't know how! (Well, except the simpler cases like the
> platonic/archimedean solids).

Are the meshes solid, and can they used in CSG operations without 
limitation?

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> Bill Pragnell wrote:
> > SharkD <mik### [at] gmailcom> wrote:
> > Quite simply, because I don't know how! (Well, except the simpler cases like the
> > platonic/archimedean solids).
>
> Are the meshes solid, and can they used in CSG operations without
> limitation?

AFAIK they are all fully closed, and I'm giving them inside_vectors so they
should also be good for CSG.

Post a reply to this message

Bill Pragnell schrieb:
> AFAIK they are all fully closed, and I'm giving them inside_vectors so they
> should also be good for CSG.

To try and root out this common misconception: Specifying an 
inside_vector is /not/ a prerequisite for a mesh to work properly with 
CSG, as POV-Ray will automaticaly assume a default value.

Specifying an inside_vector is only of use in case the default one 
should happen to give you artifacts, but I've never seen any.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> To try and root out this common misconception: Specifying an 
> inside_vector is /not/ a prerequisite for a mesh to work properly with 
> CSG, as POV-Ray will automaticaly assume a default value.

> Specifying an inside_vector is only of use in case the default one 
> should happen to give you artifacts, but I've never seen any.

  Unfortunately you are wrong. No default inside_vector is used if none is
specified in a mesh definition. Here's a demo:

//=============================================================================
#declare MajorRadius = 1;
#declare MinorRadius = .5;
#declare Resolution1 = 60;
#declare Resolution2 = 30;
#declare Torus =
  mesh2
  { vertex_vectors
    { Resolution1 * Resolution2
      #declare Ind1 = 0;
      #while(Ind1 < Resolution1)
        #declare Angle1 = 360*Ind1/Resolution1;
        #declare Ind2 = 0;
        #while(Ind2 < Resolution2)
          #declare Angle2 = 360*Ind2/Resolution2;
          vrotate(vrotate(MinorRadius*x, z*Angle2) + x*MajorRadius, y*Angle1)
          #declare Ind2 = Ind2 + 1;
        #end
        #declare Ind1 = Ind1 + 1;
      #end
    }
    face_indices
    { Resolution1 * Resolution2 * 2
      #declare Ind1 = 0;
      #while(Ind1 < Resolution1)
        #declare VInd1_1 = Ind1 * Resolution2;
        #declare VInd1_2 =
          ((Ind1+1 = Resolution1) ? 0 : (Ind1+1)) * Resolution2;
        #declare Ind2 = 0;
        #while(Ind2 < Resolution2)
          #declare VInd2_2 = ((Ind2+1 = Resolution2) ? 0 : (Ind2+1));
          <VInd1_1 + Ind2, VInd1_1 + VInd2_2, VInd1_2 + Ind2>
          <VInd1_1 + VInd2_2, VInd1_2 + Ind2, VInd1_2 + VInd2_2>
          #declare Ind2 = Ind2 + 1;
        #end
        #declare Ind1 = Ind1 + 1;
      #end
    }

    // Uncomment this for proper behavior:
    //inside_vector y
  };

camera { location <0, 5, -5> look_at 0 angle 35 }
light_source { <5, 20, -10>, 1 }
plane { y, -.5 pigment { rgb <.5, .8, 1> } }
intersection
{ object { Torus }
  plane { y, .4 }
  pigment { rgb 1 }
}
//=============================================================================

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> inside_vector is /not/ a prerequisite for a mesh to work properly with 
>> CSG, as POV-Ray will automaticaly assume a default value.
> 
>   Unfortunately you are wrong. No default inside_vector is used if none is
> specified in a mesh definition. Here's a demo:

Duh - how come I've always been fully convinced of the opposite?

You're absolutely right. I even checked in the code now.

(*blushes*)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >> inside_vector is /not/ a prerequisite for a mesh to work properly with 
> >> CSG, as POV-Ray will automaticaly assume a default value.
> > 
> >   Unfortunately you are wrong. No default inside_vector is used if none is
> > specified in a mesh definition. Here's a demo:

> Duh - how come I've always been fully convinced of the opposite?

> You're absolutely right. I even checked in the code now.

> (*blushes*)

  Maybe you got confused by a related phenomenon: Many people have a
misconception of how inside_vector works and eg. think that it must be
a point inside the mesh (rather than it being just a direction vector),
and thus it matters a lot what it is, when in fact in most cases it doesn't
matter at all. (The cases where it matters are so extremely rare that they
might as well not exist at all.)

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> (The cases where it matters are so extremely rare that they
> might as well not exist at all.)

I'm pretty much inclined to think so as well.

If such cases /do/ exist, I guess the best bet for an inside_vector 
would be anything that is not parallel or near-parallel to any face.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> If such cases /do/ exist, I guess the best bet for an inside_vector 
> would be anything that is not parallel or near-parallel to any face.

  It may indeed by that if the inside_vector is parallel to one of the
triangles, and that triange is being cut by the CSG, an artifact might
be introduced.

  The best way is to try to choose an inside_vector which is not parallel
to any of the triangles (at least not any which are being cut by CSG).

-- 
                                                          - Warp

Post a reply to this message

> clipka <ano### [at] anonymousorg> wrote:
>> If such cases /do/ exist, I guess the best bet for an inside_vector 
>> would be anything that is not parallel or near-parallel to any face.
> 
>   It may indeed by that if the inside_vector is parallel to one of the
> triangles, and that triange is being cut by the CSG, an artifact might
> be introduced.
> 
>   The best way is to try to choose an inside_vector which is not parallel
> to any of the triangles (at least not any which are being cut by CSG).
> 

With a high resolution mesh, it can be almost imposible for that vector 
not to be parallel with at least one, or several triangles.

If you get artefacts, then, just altering the inside_vector should do 
the trick. The vector will no longer be parallel with the problem triangles.



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
> With a high resolution mesh, it can be almost imposible for that vector 
> not to be parallel with at least one, or several triangles.

  Use a lot of decimals in at least one of the vector components, and the
likelihood for that happening will be extremely small.

-- 
                                                          - Warp

Post a reply to this message