![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Well, I've run up against a problem. In Megapov, you can't define macros
within macros, which doesn't seem to be a big deal, except for what I'm
trying to do. See, I've written a general engine for doing certain kinds of
manipulations. To make it general, I define several macros that the engine
calls, thus allowing me to change the macros externally. However, now I
want to use the engine inside a macro. Oops! I can't define the
appropriate bits, because they're macros, and you can't define macros within
macros. So I have to define them externally to the macro which uses them.
However, I have several macros, each with different parameterizations, and
they're called from a different file. Now that file has to define a whole
bunch of stuff before calling the appropriate macro. Not exactly useful
behavior.
Now, these macros simply calculate floating point numbers. I considered
using functions, but that didn't work as I could not evaluate the functions
at the points I wanted. One macro evaluates to a material/texture, but I
can forgive that one being a little odd if I could get the others to work.
So, any of you Megapov gurus got any ideas? I this this is an unsolveable
limitation in the program, but maybe someone else has found a way around it.
Is there any way to turn off the memory management feature that limits the
macro declarations, maybe? It wouldn't be ideal, but it would work.
Thoughts?
Geoff
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Geoff Wedig wrote:
>
> Well, I've run up against a problem. In Megapov, you can't define macros
> within macros, which doesn't seem to be a big deal, except for what I'm
> trying to do. See, I've written a general engine for doing certain kinds of
> manipulations. To make it general, I define several macros that the engine
> calls, thus allowing me to change the macros externally. However, now I
> want to use the engine inside a macro. Oops! I can't define the
> appropriate bits, because they're macros, and you can't define macros within
> macros. So I have to define them externally to the macro which uses them.
> However, I have several macros, each with different parameterizations, and
> they're called from a different file. Now that file has to define a whole
> bunch of stuff before calling the appropriate macro. Not exactly useful
> behavior.
>
> Now, these macros simply calculate floating point numbers. I considered
> using functions, but that didn't work as I could not evaluate the functions
> at the points I wanted. One macro evaluates to a material/texture, but I
> can forgive that one being a little odd if I could get the others to work.
>
> So, any of you Megapov gurus got any ideas? I this this is an unsolveable
> limitation in the program, but maybe someone else has found a way around it.
> Is there any way to turn off the memory management feature that limits the
> macro declarations, maybe? It wouldn't be ideal, but it would work.
>
> Thoughts?
>
> Geoff
Not a guru, but a though: have your engine macros generated in a file then
include that file...
So, first use your engine, next get the result of it for use,
instead of doing all at once.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Geoff Wedig
Subject: Re: Macros, includes and memory management
Date: 19 Dec 2000 09:35:11
Message: <3a3f721f@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Geoff Wedig wrote:
>>
>> Well, I've run up against a problem. In Megapov, you can't define macros
>> within macros, which doesn't seem to be a big deal, except for what I'm
>> trying to do. See, I've written a general engine for doing certain kinds of
>> manipulations. To make it general, I define several macros that the engine
>> calls, thus allowing me to change the macros externally. However, now I
>> want to use the engine inside a macro. Oops! I can't define the
>> appropriate bits, because they're macros, and you can't define macros within
>> macros. So I have to define them externally to the macro which uses them.
>> However, I have several macros, each with different parameterizations, and
>> they're called from a different file. Now that file has to define a whole
>> bunch of stuff before calling the appropriate macro. Not exactly useful
>> behavior.
>>
>> Now, these macros simply calculate floating point numbers. I considered
>> using functions, but that didn't work as I could not evaluate the functions
>> at the points I wanted. One macro evaluates to a material/texture, but I
>> can forgive that one being a little odd if I could get the others to work.
>>
>> So, any of you Megapov gurus got any ideas? I this this is an unsolveable
>> limitation in the program, but maybe someone else has found a way around it.
>> Is there any way to turn off the memory management feature that limits the
>> macro declarations, maybe? It wouldn't be ideal, but it would work.
>>
>> Thoughts?
>>
>> Geoff
> Not a guru, but a though: have your engine macros generated in a file then
> include that file...
> So, first use your engine, next get the result of it for use,
> instead of doing all at once.
Tried that. But since the file contains macros, it must be included at
global level, and when you have macros calling other macros, that's not
always a sensible thing from a coding standpoint. You can't just include
the appropriate types before the macro definition either, since if you use
two variants, whatever variant happens to be "in power" at the time of the
macro's function call takes precedence. Essentially, the scene gets divided
up into sections of macrovariant1, macrovaraint2, etc, at the global level,
or some of the macro calls won't work properly.
Geoff
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a3f589f@news.povray.org>, Geoff Wedig
<wed### [at] darwin epbi cwru edu> wrote:
> So, any of you Megapov gurus got any ideas? I this this is an
> unsolveable limitation in the program, but maybe someone else has
> found a way around it.
Instead of defining a macro inside of another, change the value of a
global variable and put all your macros in the file, with different
names. Then, have the macro that you called(the one that was originally
defined inside the other macro) decide what to do based on that
variable. Probably the best way would be to use the #switch statement to
call the desired macro.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Geoff Wedig
Subject: Re: Macros, includes and memory management
Date: 19 Dec 2000 10:03:57
Message: <3a3f78dd@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
> In article <3a3f589f@news.povray.org>, Geoff Wedig
> <wed### [at] darwin epbi cwru edu> wrote:
>> So, any of you Megapov gurus got any ideas? I this this is an
>> unsolveable limitation in the program, but maybe someone else has
>> found a way around it.
> Instead of defining a macro inside of another, change the value of a
> global variable and put all your macros in the file, with different
> names. Then, have the macro that you called(the one that was originally
> defined inside the other macro) decide what to do based on that
> variable. Probably the best way would be to use the #switch statement to
> call the desired macro.
That's probably what I'll have to do. It's not very extensible though. If
someone wants to use their own parameterization, that isn't provided in the
base code, they have to not only write the new macro, but give it an
identifier and add it to the multiplexer macro. Of course, I could write
some code that would add something to the multiplexer macro.... That could
even be an include rather than a macro itself, so could be done.
Hmm, can a macro be defined in terms of itself? Ie, can you have something
like:
#macro test_macro()
test_macro()
other stuff
#end
?
I'll test...
Anyway, I'm back in business. Thanks!
Geoff
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a3f78dd@news.povray.org>, Geoff Wedig
<wed### [at] darwin epbi cwru edu> wrote:
> That's probably what I'll have to do. It's not very extensible though.
> If someone wants to use their own parameterization, that isn't
> provided in the base code, they have to not only write the new macro,
> but give it an identifier and add it to the multiplexer macro.
Just let one of the macros be a "user macro", with a specific,
documented name. That way, the user can write their own macro with this
name, which your code already knows to call if the control variable has
a certain value.
> Hmm, can a macro be defined in terms of itself? Ie, can you have
> something like:
>
> #macro test_macro()
> test_macro()
> other stuff
> #end
That depends on what you mean by "defined in terms of itself". What you
wrote there is an infinitely recursive macro...once you call it, it will
call itself, call itself, call itself...ad infinitum. You need to use an
#if() block and a counter variable to tell it when to stop calling
itself. Then it will return through all the "other stuff" once for every
call.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Geoff Wedig
Subject: Re: Macros, includes and memory management
Date: 19 Dec 2000 13:25:36
Message: <3a3fa820@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
> In article <3a3f78dd@news.povray.org>, Geoff Wedig
> <wed### [at] darwin epbi cwru edu> wrote:
>> That's probably what I'll have to do. It's not very extensible though.
>> If someone wants to use their own parameterization, that isn't
>> provided in the base code, they have to not only write the new macro,
>> but give it an identifier and add it to the multiplexer macro.
> Just let one of the macros be a "user macro", with a specific,
> documented name. That way, the user can write their own macro with this
> name, which your code already knows to call if the control variable has
> a certain value.
>> Hmm, can a macro be defined in terms of itself? Ie, can you have
>> something like:
>>
>> #macro test_macro()
>> test_macro()
>> other stuff
>> #end
> That depends on what you mean by "defined in terms of itself". What you
> wrote there is an infinitely recursive macro...once you call it, it will
> call itself, call itself, call itself...ad infinitum. You need to use an
> #if() block and a counter variable to tell it when to stop calling
> itself. Then it will return through all the "other stuff" once for every
> call.
What I meant was a macro that is redefined based upon it's previous state.
Much like with variables:
a = a+1;
for example. It takes the previous value of a and applies it to the new
expression. Macros don't work like that, and as far as I know, very few
programming languages allow such constructs, so I'm not surprised that POV
doesn't either.
However, with the solution you posted in the other thread (how to evaluate a
function), it might not be necessary at all. Most of my macros are the
calculation of single values, so can easily be functions. There are only
one or two that are tricky, and those can be worked around in this fashion.
Geoff
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |