 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
While I'm on the subject, I'll mention here for the benefit of
anyone else who doesn't bother putting Version=3.1 in their INI
files (like me, duh!), if you don't tell MegaPOV anything going
in, it apparently automatically sets itself for version 3.00 which
of course kills the #macro directive.
For some reason, setting ...
#version unofficial MegaPov 0.4;"
...won't change this behaviour even though setting...
"#version official 3.1;"
..will fix it. (??) Anyway, the best solution is fix your
INI files, I guess, but another workaround is to use
"#version official 3.1;" before you define your macros, then
"#version unofficial MegaPov 0.4;" after you're finished.
For whatever reasons, once they're defined, the version
doesn't have any affect on the macros performance. Personally
I don't see why any version switch should turn off macros.
I mean, obviously macros didn't always exist and older
versions of POV won't handle them, but if the program
version you're using knows what they are, why be fussy and
shut down with an error messgae because of a version switch?
Anyway, thought I'd post this observation in case it affects
anyone else as dumb as me.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have used the #macro statement without any problem.
I did have to set #version unofficial MegaPov 0.4; to
get isosurfaces to work, but that was all.
I am using WinMeagPov0.4. Are you on a different os?
Charles Fusner wrote:
>
> While I'm on the subject, I'll mention here for the benefit of
> anyone else who doesn't bother putting Version=3.1 in their INI
> files (like me, duh!), if you don't tell MegaPOV anything going
> in, it apparently automatically sets itself for version 3.00 which
> of course kills the #macro directive.
>
> For some reason, setting ...
>
> #version unofficial MegaPov 0.4;"
>
> ...won't change this behaviour even though setting...
>
> "#version official 3.1;"
>
> ..will fix it. (??) Anyway, the best solution is fix your
> INI files, I guess, but another workaround is to use
> "#version official 3.1;" before you define your macros, then
> "#version unofficial MegaPov 0.4;" after you're finished.
> For whatever reasons, once they're defined, the version
> doesn't have any affect on the macros performance. Personally
> I don't see why any version switch should turn off macros.
> I mean, obviously macros didn't always exist and older
> versions of POV won't handle them, but if the program
> version you're using knows what they are, why be fussy and
> shut down with an error messgae because of a version switch?
>
> Anyway, thought I'd post this observation in case it affects
> anyone else as dumb as me.
>
> Charles
--
Mr. Art
"Often the appearance of reality is more important
than the reality of the appearance."
Bill DeWitt 2000
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3894D0C0.CBF01B51@enter.net> , Charles Fusner
<cfu### [at] enter net> wrote:
> ...won't change this behaviour even though setting...
>
> "#version official 3.1;"
You should be able to continue to use the "#version 3.1;" for backward
compatibility with the official 3.1 parser.
> in, it apparently automatically sets itself for version 3.00 which
> of course kills the #macro directive.
It still sets itself to 3.1, so this is either a bug (or a precision
problem).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sme### [at] skynetbe (smellenbergh) writes:
> MegaPov 0.4 is ready for downloading.
>
> You can find Nathan's Windows version at (this is not the usual place!):
> ftp://ftp.povray.org/pub/povray/Unofficial/MegaPOV/
>
> The Macintosh version at the usual site:
> http://users.skynet.be/smellenbergh
First, let me thank you for the time that you invest in the megapatch.
In frame.h it says:
#define CLOCKDIVIDER CLK_TCK /*provided by standard c? */
and as far as I know the answer is "No". According to the documentation
available to me, you should use CLOCK_PER_SEC instead and include <time.h>.
In postproc.c there are two //-comments. Remove the lines or comment
them out with /* */.
In tokenize.c I have removed the "Not-quite-so-Static" function declarations.
Now, only the static declarations exists.
With these changes it compiles flawlessly under Sun Solaris using gcc.
You can dowload the modified version including the Makefile at
http://www.povray.willhalm.de/povaddon/
Thomas
--
http://thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
|
| |
| |
|
|
From: Sander
Subject: Re: MegaPov 0.4 Now Available (Windows/Macintosh)
Date: 31 Jan 2000 05:56:14
Message: <38956a4e@news.povray.org>
|
|
|
| |
| |
|
|
Yes, I use Ron Parker's brick wall code. Shouldn't it run with MegaPov 0.4?
What #statements should be present?
--
Regards,
Sander
Ken <tyl### [at] pacbellnet> schreef in berichtnieuws
3894ABB8.FA864E23@pacbell.net...
>
> Did you by any chance check it against the code Ron Parker recently
> posted in povray.text.scene-files ? That code is known to work with
> earlier versions.
>
> Subject: Re: Brick wall and paving stones macros (~80kb)
> Date: 19 Jan 2000 10:15:35 -0500
> From: ron### [at] povrayorg (Ron Parker)
> Newsgroups: povray.binaries.images, povray.text.scene-files
> Followup-To: povray.text.scene-files
> References: 1 , 2 , 3 , 4
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"mr.art" wrote:
>
> I have used the #macro statement without any problem.
> I did have to set #version unofficial MegaPov 0.4; to
> get isosurfaces to work, but that was all.
> I am using WinMeagPov0.4. Are you on a different os?
>
No, WinMegaPOV0.4 here. The only thing required to (reliably)
reproduce the problem for me is that I have to pull the...
Version=3.1
...out of my INI file. When this is done, without expressly
saying "#version official 3.1;" before the macro definitions
causes them to fail with the following error message:
C:\C_wip\test.pov:1: error: Macros require #version 3.1 but #version
3.00 is set
I may be the only person this even affects, of course.
I imagine most people keep the Version=3.1 in their INI
even though logically, it seems to me it should be
useless since the default version compatibility should
logically be the latest syntax. I would think the only
time Version should be needed in an INI is if you are
distributing a custom INI designed to render a piece of
"legacy" POV code, and even then, it would normally be
unneeded, since you could always use #version in the code
itself more effectively.
Anyway, just thought I'd mention it in case anyone else
sees a similar problem. The solution is just to add the
"Version=3.1" back to your INI file. It's weird, but not
a show stopper.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> > ...won't change this behaviour even though setting...
> >
> > "#version official 3.1;"
>
> You should be able to continue to use the "#version 3.1;" for backward
> compatibility with the official 3.1 parser.
Yup, that also works. I was just keeping in the spirit of the
new syntax in the MegaPOV docs <g>.
> It still sets itself to 3.1, so this is either a bug (or a precision
> problem).
The only way I can reliably reproduce the behaviour is to yank
"Version=3.1" from my INI file, and since I would think the parser
would naturally assume version 3.1 until told otherwise, I'm
inclined to agree its a bug. A very very tiny one with an easy
workaround though, so I'm just observing, not complaining.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3896214F.9BBB720D@enter.net> , Charles Fusner
<cfu### [at] enternet> wrote:
>> It still sets itself to 3.1, so this is either a bug (or a precision
>> problem).
>
> The only way I can reliably reproduce the behaviour is to yank
> "Version=3.1" from my INI file, and since I would think the parser
> would naturally assume version 3.1 until told otherwise, I'm
> inclined to agree its a bug. A very very tiny one with an easy
> workaround though, so I'm just observing, not complaining.
The parser sets 3.1 but sometimes precision comes in the way and a compiler
stores (= presets) 3.1 as 3.09999999. The code correctly initialises to 3.1
so that is the likely cause as this has also been a problem with certain
compiler settings for the official 3.1, at least on Macs.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> New in this version:
> *Chris Huff's blob pattern, proximity pattern, evaluate pigment/pattern, noise3d.
Days when new pov versions arrive are like Christmas :)
I have used noise3d, however, in 0.3. Was there some kind of change to this function?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3897068A.7984E169@my-dejanews.com>,
gre### [at] my-dejanewscom wrote:
> I have used noise3d, however, in 0.3. Was there some kind of change to
> this function?
I wrote a patch which allows it to be used in normal POV-Ray script,
instead of only in isosurface functions.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
