|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > 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
|
|
| |
| |
|
|
|
|
| |