There are some very useful triangle mesh generators in shapes.inc for making
mesh2 versions of a sphere, cylinder, torus etc., which can have real surface
displacement via functions. Not quite as useful or capable as true isosurfaces,
but they generally render faster (and you can choose the triangle resolution.)

To successfully use any of the HF macros in CSG, an inside_vector <.....> has to
be added...not in your SDL scene code, as it will not work there in this case.
Instead, it has to go inside shapes.inc. *Where* to put it may not be obvious.
The docs say it has to be placed "following all other mesh data, but before the
object modifiers." I found a place for it, down around line 998 in
the HF_Create () macro--the "Internal macro not intended to be called by user"--
which is used by all the mesh2 generators. The original code there is written:

.....
   #fclose _HFMACRO_OUTPUT_FILE
      #else
         }
         }
      #end
......

The appended code is this:
.......
   #fclose _HFMACRO_OUTPUT_FILE
      #else
         }
inside_vector <.......>
         }
      #end
.......

Although it works very well, and can be left in permanently with no problems,
I'm not so sure it should be permanent. There may be times when you want to use
a CSG difference to simply punch a clean hole into the triangle mesh (kind of
like the behavior of water_level when used in a regular height_field, simply
clipping away triangles.)  In such cases, inside_vector should not be used. The
docs also say, "This will only work for well-behaved meshes, which are
completely closed volumes. If meshes have any holes in them, this might work,
but the results are not guaranteed."  The HF_Cylinder macro produces a cylinder
with open ends--just a tube--but inside_vector still works OK for it. A happy
surprise.

IMO, the documentation concerning inside_vector is not perfectly clear about how
to apply it. The docs seems to imply that you can just stick the keyword in and
it works; but in fact it *must* be followed by a vector <......> with three
values--all of which can be random, in my experience. I've never yet run into a
situation where a *specific* direction vector had to be used.

Ken W.

Post a reply to this message

'inside_vector', just like 'hollow', seems to be kind of magical to a lot of 
users...  AFAIK there is NO NEED to specify inside_vector if you want to use 
a properly closed mesh in CSG, since the default will do just fine.  If 
there are holes, or other abnormalities, it might work, but in some cases 
only if you carefully specify an inside_vector.  This should not be done 
randomly.  The idea of the inside_vector, AFAIK, is as follows:
to check if a specific point is inside the triangle-mesh, POV-Ray traces a 
ray in the direction of inside_vector and counts the intersections with the 
mesh.  If there's an odd number of intersections, the point is inside the 
mesh, an even number indicates that the point is outside the mesh. The 
problem arises if inside_vector points towards an abnormality (a hole in the 
mesh for instance), I suppose it's obvious what can go wrong in such cases.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen <zeg### [at] povplacecom> wrote:
> 'inside_vector', just like 'hollow', seems to be kind of magical to a lot of 
> users...  AFAIK there is NO NEED to specify inside_vector if you want to use 
> a properly closed mesh in CSG, since the default will do just fine.

  I think you are confusing meshes+CSG with meshes+media.

  The inside_vector indeed has nothing to do with media or other 'interior'
features, and would be completely needless with them. As long as the mesh
forms a closed surface, media inside it will render just fine.

  However, inside_vector *is* needed for intersection, difference and merge
CSG to work properly with meshes. This is because these operations require
to know if a given point is inside the mesh or not. If you don't use it,
POV-Ray won't be able to calculate CSG properly in all situations.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:48f7b570@news.povray.org...
> Zeger Knaepen <zeg### [at] povplacecom> wrote:
>> 'inside_vector', just like 'hollow', seems to be kind of magical to a lot 
>> of
>> users...  AFAIK there is NO NEED to specify inside_vector if you want to 
>> use
>> a properly closed mesh in CSG, since the default will do just fine.
>
>  I think you are confusing meshes+CSG with meshes+media.

no, I wasn't

>  The inside_vector indeed has nothing to do with media or other 'interior'
> features, and would be completely needless with them. As long as the mesh
> forms a closed surface, media inside it will render just fine.

I know, or at least I never saw any reason why it shouldn't

>  However, inside_vector *is* needed for intersection, difference and merge
> CSG to work properly with meshes. This is because these operations require
> to know if a given point is inside the mesh or not. If you don't use it,
> POV-Ray won't be able to calculate CSG properly in all situations.

you're saying there's no default-value for inside_vector?  I've never 
actually tried it, I just assumed so...
let's try something...

-- START CODE --
camera {location <2,3,-10> look_at 0}
light_source {<750,250,-500> rgb 1}
light_source {<500,500,-500> rgb <.5,.4,.3> shadowless}
#local Cube=mesh {
 triangle {<-1,-1,-1>,<-1,1,-1>,<1,1,-1>}triangle 
{<-1,-1,-1>,<1,1,-1>,<1,-1,-1>}
 triangle {<-1,-1,1>,<-1,1,1>,<1,1,1>}triangle {<-1,-1,1>,<1,1,1>,<1,-1,1>}
 triangle {<-1,-1,-1>,<-1,-1,1>,<1,-1,1>}triangle 
{<-1,-1,-1>,<1,-1,1>,<1,-1,-1>}
 triangle {<-1,1,-1>,<-1,1,1>,<1,1,1>}triangle {<-1,1,-1>,<1,1,1>,<1,1,-1>}
 triangle {<-1,-1,-1>,<-1,-1,1>,<-1,1,1>}triangle 
{<-1,-1,-1>,<-1,1,1>,<-1,1,-1>}
 triangle {<1,-1,-1>,<1,-1,1>,<1,1,1>}triangle {<1,-1,-1>,<1,1,1>,<1,1,-1>}
 //inside_vector x
}

intersection {
 object {Cube}
 sphere {0,1.5}
 pigment {rgbt .5}
}
-- END CODE --

hmm, indeed, without inside_vector, POV-Ray doesn't seem to even try to 
check if a point is inside the mesh... why not? a default inside_vector 
seems trivial to me (if a mesh is well formed and closed, any vector will 
do, if it isn't, any vector still has a reasonable amount of chance it will 
work, so any vector should work in most cases) and result in the behaviour 
most users would expect (I actually had troubles figuring out why the 
background showed through the CSG).

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen <zeg### [at] povplacecom> wrote:
> you're saying there's no default-value for inside_vector?

  That's correct.

> hmm, indeed, without inside_vector, POV-Ray doesn't seem to even try to 
> check if a point is inside the mesh... why not?

  I don't know why inside_vector is not always on by default. Maybe
rendering the mesh becomes slower in certain situations if it has an
inside_vector defined? (Although, I must admit, I don't know which
situations would those be.)

  One reason could be backwards compatibility: Meshes have always been
patch objects with no inside, and thus they do not affect things like
fog or surrounding media. Making them always have an inside_vector would
probably change this behavior. At the very least there should be a way
to turn it off.

  Maybe someone could measure the rendering speed of diverse meshes with
and without an inside_vector defined in different situations and see if
it makes a difference.

-- 
                                                          - Warp

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> [inside_vector] should not be done
> randomly.

When I was working on adding it to shapes.inc, I actually set up a little
randomizer, to see what might happen:

#declare SSS = seed(73);
inside_vector <rand(SSS) - .5,rand(SSS) - .5,rand(SSS) - .5>

That pretty well scrambles up the values + and -. I plugged in a bunch of
different seed values, ran the HF_Cylinder macro each time--which has big open
ends-- and it worked successfully with a CSG difference 100% of the time. Along
with previous experience, that convinced me that the vector could have
completely random values (although not <0,0,0>, I suspect; that would create no
vector direction at all.)

Something I've always wondered about: The docs say that a ray is shot in this
direction; but from *where*? Anyone know if it's from the origin?

KW

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>
>   Maybe someone could measure the rendering speed of diverse meshes with
> and without an inside_vector defined in different situations and see if
> it makes a difference.
>

Here's a parse-time test for the HF_Cylinder macro in shapes.inc (unmodified
except for inside_vector), no CSG, and run at a relatively hi-rez of 1200 X
1200:

No difference in the parse times, whether including inside_vector or leaving it
out.

KW

Post a reply to this message

Kenneth napsal(a):
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> [inside_vector] should not be done
>> randomly.
> 
> When I was working on adding it to shapes.inc, I actually set up a little
> randomizer, to see what might happen:
> 
> #declare SSS = seed(73);
> inside_vector <rand(SSS) - .5,rand(SSS) - .5,rand(SSS) - .5>
> 
> That pretty well scrambles up the values + and -. I plugged in a bunch of
> different seed values, ran the HF_Cylinder macro each time--which has big open
> ends-- and it worked successfully with a CSG difference 100% of the time. Along
> with previous experience, that convinced me that the vector could have
> completely random values (although not <0,0,0>, I suspect; that would create no
> vector direction at all.)
> 
> Something I've always wondered about: The docs say that a ray is shot in this
> direction; but from *where*? Anyone know if it's from the origin?
> 
> KW
> 
> 
from the point you test for insideness

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> Warp <war### [at] tagpovrayorg> wrote:

> >   Maybe someone could measure the rendering speed of diverse meshes with
> > and without an inside_vector defined in different situations and see if
> > it makes a difference.

> Here's a parse-time test for the HF_Cylinder macro in shapes.inc (unmodified
> except for inside_vector), no CSG, and run at a relatively hi-rez of 1200 X
> 1200:

> No difference in the parse times, whether including inside_vector or leaving it
> out.

  I was not asking for parsing times.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:

> > No difference in the parse times, whether including inside_vector or leaving > >
it out.
>
>   I was not asking for parsing times.
>

Render time?

I wasn't aware that render time would be influenced by that; triangle meshes are
'generated' during parsing, AFAIK, where the time differences would show up. Or
else I'm confused about what you originally meant. Or just plain confused!

KW

Post a reply to this message