"Edouard Poor" <pov### [at] edouardinfo> wrote:
> stbenge <THI### [at] hotmailcom> wrote:
> >
> > The biggest reason I didn't model this as a mesh is because it's
> > currently impossible to use any proximity patterns with meshes. That's
> > right, impossible! Actually, if somebody can figure out how to get a
> > proximity pattern working with meshes, I would really appreciate it :)
>
> Just write your own inside() function. I gave it a go with the following, and it
> seems to work pretty well. It should really be improved with the equivalent of
> an inside_vector, so you can usefully use it with open meshes, but it's OK for
> a quick attempt.
>
> #macro inside_m( obj, pos )
>  #local current = pos;
>  #local dir = x;
>  #local done = 0;
>  #local num = 0;
>  #while ( done != 1 )
>   #local norm = <0,0,0>;
>   #local inter = trace( obj, current, dir, norm );
>   #if ( vlength( norm ) != 0 )
>    #local num = num + 1;
>    #local current = inter + <0.0001,0,0>;
>   #else
>    #local done = 1;
>   #end
>  #end
>  (mod( num, 2 ) = 1)
> #end
>
> Cheers,
> Edouard.

Forgive me for being slow as usual, but could you could help me understand your
macro?

I suppose you could used the inside test to fill up the inside of a mesh with
cubes to make CSG approximation of a mesh shape--but that doesn't appear to be
what you did.

Post a reply to this message

> > > The biggest reason I didn't model this as a mesh is because it's
> > > currently impossible to use any proximity patterns with meshes. That's
> > > right, impossible! Actually, if somebody can figure out how to get a
> > > proximity pattern working with meshes, I would really appreciate it :)
> >
> > Just write your own inside() function. I gave it a go with the following, and it
> > seems to work pretty well. It should really be improved with the equivalent of
> > an inside_vector, so you can usefully use it with open meshes, but it's OK for
> > a quick attempt.
> >
>>[...]
>
> Forgive me for being slow as usual, but could you could help me understand your
> macro?
>
> I suppose you could used the inside test to fill up the inside of a mesh with
> cubes to make CSG approximation of a mesh shape--but that doesn't appear to be
> what you did.

Just replace the "inside()" call in Sam's fastprox macros with my "inside_m()"
(or your own more complete macro) and his code then works perfectly on meshes
(but still should work with everything else too).

Cheers,
Edouard.

Post a reply to this message

Edouard Poor wrote:
> stbenge <THI### [at] hotmailcom> wrote:
>> The biggest reason I didn't model this as a mesh is because it's
>> currently impossible to use any proximity patterns with meshes. That's
>> right, impossible! Actually, if somebody can figure out how to get a
>> proximity pattern working with meshes, I would really appreciate it :)
> 
> Just write your own inside() function. I gave it a go with the following, and it
> seems to work pretty well. It should really be improved with the equivalent of
> an inside_vector, so you can usefully use it with open meshes, but it's OK for
> a quick attempt.
> 
> #macro inside_m( obj, pos )

Hi Edouard,

I thought using the "i" word might get somebody to think of a solution 
:) I tried the macro, and it seems to work very well. It's not as slow 
as I thought it would be! I'm not sure if I understand the code 
completely. It traces lines through the mesh, and if the number of 
intersections is odd, it considers the point of reference inside, right? 
I don't have any formal schooling in higher math, so I do not understand 
this line:

(mod( num, 2 ) = 1)

The POV docs say mod(A,B) returns the remainder of the integer division 
of A/B. I can understand that. But how does this work when you say it 
equals 1? Is this like a conditional statement?

And I don't comprehend what you mean when you say I can improve your 
macro with the equivalent of an inside_vector. Would I simply add 
another parameter which would pass a vector to #local dir ?

May I use your code in my next distribution of my proximity macros? I'll 
give you credit, of course :)

Sam

Post a reply to this message

Edouard Poor wrote:
> Just replace the "inside()" call in Sam's fastprox macros with my "inside_m()"
> (or your own more complete macro) 

Would you care to elaborate on what a "more complete macro" might 
entail? If there are improvements I can make before my next release, I 
will consider them as long as they don't make the macro too complex for 
the end user (of course, it might already be too late...).

Sam

Post a reply to this message

stbenge <THI### [at] hotmailcom> wrote:

> Hi Edouard,
>
> I thought using the "i" word might get somebody to think of a solution
> :) I tried the macro, and it seems to work very well. It's not as slow
> as I thought it would be! I'm not sure if I understand the code
> completely. It traces lines through the mesh, and if the number of
> intersections is odd, it considers the point of reference inside, right?

Exactly - odd means the point was inside.

I, too, was surprised how fast it was - I didn't really notice being slower on
the test scenes you bundled with your macro.

> I don't have any formal schooling in higher math, so I do not understand
> this line:
>
> (mod( num, 2 ) = 1)
>
> The POV docs say mod(A,B) returns the remainder of the integer division
> of A/B. I can understand that. But how does this work when you say it
> equals 1? Is this like a conditional statement?

The statement gets evaluated to true or false (which is one or zero in POV SDL).
Once the "mod(num,2)" has been evaluated, the statement then becomes "0=1" or
"1=1" which in turn evaulates to 0 or 1 (i.e. false or true).

It's being used like a shorthand for an if() statement. I'm a C++ programmer,
and it's a very common idiom in that language, so I guess it's second nature to
me, and I didn't think that it wouldn't be as clear to an SDL programmer. Sorry!

> May I use your code in my next distribution of my proximity macros? I'll
> give you credit, of course :)

Most certainly! Your macros are a wonder, and amazingly useful.

> Sam

Cheers,
Edouard.

Post a reply to this message

stbenge <THI### [at] hotmailcom> wrote:
> Edouard Poor wrote:
> > Just replace the "inside()" call in Sam's fastprox macros with my "inside_m()"
> > (or your own more complete macro)
>
> Would you care to elaborate on what a "more complete macro" might
> entail? If there are improvements I can make before my next release, I
> will consider them as long as they don't make the macro too complex for
> the end user (of course, it might already be too late...).

Just the inside_vector improvement I think.

Imagine if you had a mesh height field - if you chose an inside_vector that
pointed "up", then your fastprox macros would work on it, even though it's an
open object. My inside_m() macro just uses x as the test direction.

> Sam

Cheers,
Edouard.

Post a reply to this message

"Edouard Poor" <pov### [at] edouardinfo> wrote:
> stbenge <THI### [at] hotmailcom> wrote:
> > Edouard Poor wrote:
> > > Just replace the "inside()" call in Sam's fastprox macros with my "inside_m()"
> > > (or your own more complete macro)
> >
> > Would you care to elaborate on what a "more complete macro" might
> > entail? If there are improvements I can make before my next release, I
> > will consider them as long as they don't make the macro too complex for
> > the end user (of course, it might already be too late...).
>
> Just the inside_vector improvement I think.
>
> Imagine if you had a mesh height field - if you chose an inside_vector that
> pointed "up", then your fastprox macros would work on it, even though it's an
> open object. My inside_m() macro just uses x as the test direction.

You guys are friggin' amazin'! XD

Post a reply to this message

Edouard Poor wrote:
> stbenge <THI### [at] hotmailcom> wrote:

> The statement gets evaluated to true or false (which is one or zero
> in POV SDL). Once the "mod(num,2)" has been evaluated, the statement
> then becomes "0=1" or "1=1" which in turn evaulates to 0 or 1 (i.e.
> false or true).

Excuse me, but isn't the statement in this case totally obsolet?
It evaluates to 0 when mod(num,2) is 0 and it evaluates to 1 if mod(num,2) 
is 1.

Or did i miss something?

Greetings,
Marc-Hendrik

Post a reply to this message

"Marc-Hendrik Bremer" <Mar### [at] t-onlinede> wrote:
>
> > The statement gets evaluated to true or false (which is one or zero
> > in POV SDL). Once the "mod(num,2)" has been evaluated, the statement
> > then becomes "0=1" or "1=1" which in turn evaulates to 0 or 1 (i.e.
> > false or true).
>
> Excuse me, but isn't the statement in this case totally obsolet?
> It evaluates to 0 when mod(num,2) is 0 and it evaluates to 1 if mod(num,2)
> is 1.
>
> Or did i miss something?

No - you're exactly right. It makes it explicit what the check is for, but is
unnecessary.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> schreef in bericht 
news:web.493c772562d2e2211cb718750@news.povray.org...
>
> You guys are friggin' amazin'! XD
>

I agree totally!!

(...and I almost missed this code development)

Thomas

Post a reply to this message