 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
We are happy to announce the release of MegaPov 0.6a. This is a bugfix
release to clean up some problems with MegaPov 0.6.
Windows:
http://nathan.kopp.com/patched.htm
Macintosh:
http://users.skynet.be/smellenbergh
DOS:
http://www.stuartgibson.com/
The demo scenes can be viewed on-line at Smellenbergh's site:
http://users.skynet.be/smellenbergh (click on the "Demos" link in the
navigation bar on the left).
Here are the changes for MegaPov 0.6a:
* Fixed a bug in the proximity patch. If no sample_weight vector was given
it was filled with random values, giving different results for each
rendering.
* In isosurface statistics, max gradient is reported again
* Fixed more memory leaks in isosurface
* julia sqr and power (^) now allowed without version unofficial xx
specifier: it is a legal keyword in POV-Ray 3.1
* In the manual updated section 8.9 displace warp
* In the manual corrected 9.20: the formula used is:
Red*0.3+Green*0.59+Blue*0.11
* In DoPostProcess() in postproc.c give an error if for some reason the
input file could not be opened. Previously MegaPOV would crash.
* density file is now positioned from 0 to 1 again. We changed that in 0.6
but obviously this was incorrect. It crashed MP often too. Files written by
the df3 patch are now flipped so that the result is correct.
* df3 in i_dat3d now works again. This was listed as fixed in MP 0.6 but
only now in 0.6a this is realy fixed!
* Updated the displacement warp patch to MP+0.3.2. This adds the type
keyword.
* Fixed bug in transform when used like this: "transform {
DeclaredMyTrans }"
Enjoy!
-The MegaPov Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> We are happy to announce the release of MegaPov 0.6a. This is a bugfix
> release to clean up some problems with MegaPov 0.6.
>
I'm happy to hear this!
But during testing of my patch I've found memory leak in old version
(0.6) and seems like it ain't fixed in new version either:
Function InitMallocCaches in file lighting.c allocates cache sizes
(ShadowMediaListCacheSize, LightingMediaListCacheSize &
MediaIntervalCacheSize), but does not free them in DeInitMallocCaches.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 16 Oct 2000 01:20:18 -0400 Nathan Kopp wrote:
>We are happy to announce the release of MegaPov 0.6a. This is a bugfix
>release to clean up some problems with MegaPov 0.6.
Thanks much, Nathan and others on the WinMegaPov Team.
--
Alan - ako### [at] povray org - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
[...]
>
> Enjoy!
>
> -The MegaPov Team
I do ! :-)
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
all charioteers : Ben Hur :: all programmers : MegaTeam
all woodsmen : Davy Crocket :: all programmers : PovTeam
Nathan Kopp wrote:
> We are happy to announce the release of MegaPov 0.6a. This is a bugfix
> release to clean up some problems with MegaPov 0.6.
>
> Windows:
> http://nathan.kopp.com/patched.htm
> Macintosh:
> http://users.skynet.be/smellenbergh
> DOS:
> http://www.stuartgibson.com/
>
> The demo scenes can be viewed on-line at Smellenbergh's site:
> http://users.skynet.be/smellenbergh (click on the "Demos" link in the
> navigation bar on the left).
>
> Here are the changes for MegaPov 0.6a:
>
> * Fixed a bug in the proximity patch. If no sample_weight vector was given
> it was filled with random values, giving different results for each
> rendering.
> * In isosurface statistics, max gradient is reported again
> * Fixed more memory leaks in isosurface
> * julia sqr and power (^) now allowed without version unofficial xx
> specifier: it is a legal keyword in POV-Ray 3.1
> * In the manual updated section 8.9 displace warp
> * In the manual corrected 9.20: the formula used is:
> Red*0.3+Green*0.59+Blue*0.11
> * In DoPostProcess() in postproc.c give an error if for some reason the
> input file could not be opened. Previously MegaPOV would crash.
> * density file is now positioned from 0 to 1 again. We changed that in 0.6
> but obviously this was incorrect. It crashed MP often too. Files written by
> the df3 patch are now flipped so that the result is correct.
> * df3 in i_dat3d now works again. This was listed as fixed in MP 0.6 but
> only now in 0.6a this is realy fixed!
> * Updated the displacement warp patch to MP+0.3.2. This adds the type
> keyword.
> * Fixed bug in transform when used like this: "transform {
> DeclaredMyTrans }"
>
> Enjoy!
>
> -The MegaPov Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some files have capital letters in their names but they are included all
in lower-case.
This is a problem. The #included file name should be exactly the same as
the file name (case sensitive). Either the #include has to be renamed or
the file name itself has to be renamed to lower case (probably best solution).
I can automatically convert all file names to lowercase with a relatively
short unix command, but all unix users might not know enough to do it.
It would be best that the files were in lowercase in the zip-file itself.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Nathan,
The manual gives the displace warp syntax as
warp { displace { PATTERN, COLOR_MAP } type TYPE }
which is what went into the MP+ manual as well.
I understand the correct syntax (at least, it works for me) is
warp { displace { PIGMENT_BODY type TYPE } }
which means you can put in anything from a declared pigment name to a
full compound pigment pattern ...
Bye for now,
Mike Andrews.
Nathan Kopp wrote:
> * In the manual updated section 8.9 displace warp
>
> * Updated the displacement warp patch to MP+0.3.2. This adds the type
> keyword.
>
> Enjoy!
>
> -The MegaPov Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Some files have capital letters in their names but they are included all
> in lower-case.
> This is a problem. The #included file name should be exactly the same as
> the file name (case sensitive). Either the #include has to be renamed or
> the file name itself has to be renamed to lower case (probably best solution).
> I can automatically convert all file names to lowercase with a relatively
> short unix command, but all unix users might not know enough to do it.
> It would be best that the files were in lowercase in the zip-file itself.
>
Unfortunately, Windows has its own ideas about which letters should be
upper case and which lower case, and AFAIK there's no easy way to change
that.
On unix, the -L option of unzip is supposed to fix the problem...
Jérôme
--
********************************* Jérôme M. BERGER
* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy. * http://www.enst.fr/~jberger
*********************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for all your efforts, much appreciated.
Mick
"Nathan Kopp" <Nat### [at] Koppcom> wrote in message
news:39ea90ca$1@news.povray.org...
> We are happy to announce the release of MegaPov 0.6a. This is a bugfix
> release to clean up some problems with MegaPov 0.6.
>
> Windows:
> http://nathan.kopp.com/patched.htm
> Macintosh:
> http://users.skynet.be/smellenbergh
> DOS:
> http://www.stuartgibson.com/
>
> The demo scenes can be viewed on-line at Smellenbergh's site:
> http://users.skynet.be/smellenbergh (click on the "Demos" link in the
> navigation bar on the left).
>
> Here are the changes for MegaPov 0.6a:
>
> * Fixed a bug in the proximity patch. If no sample_weight vector was given
> it was filled with random values, giving different results for each
> rendering.
> * In isosurface statistics, max gradient is reported again
> * Fixed more memory leaks in isosurface
> * julia sqr and power (^) now allowed without version unofficial xx
> specifier: it is a legal keyword in POV-Ray 3.1
> * In the manual updated section 8.9 displace warp
> * In the manual corrected 9.20: the formula used is:
> Red*0.3+Green*0.59+Blue*0.11
> * In DoPostProcess() in postproc.c give an error if for some reason the
> input file could not be opened. Previously MegaPOV would crash.
> * density file is now positioned from 0 to 1 again. We changed that in 0.6
> but obviously this was incorrect. It crashed MP often too. Files written
by
> the df3 patch are now flipped so that the result is correct.
> * df3 in i_dat3d now works again. This was listed as fixed in MP 0.6 but
> only now in 0.6a this is realy fixed!
> * Updated the displacement warp patch to MP+0.3.2. This adds the type
> keyword.
> * Fixed bug in transform when used like this: "transform {
> DeclaredMyTrans }"
>
> Enjoy!
>
> -The MegaPov Team
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote...
> Some files have capital letters in their names but they are included all
> in lower-case.
> This is a problem. The #included file name should be exactly the same as
> the file name (case sensitive). Either the #include has to be renamed or
> the file name itself has to be renamed to lower case (probably best
solution).
> I can automatically convert all file names to lowercase with a
relatively
> short unix command, but all unix users might not know enough to do it.
> It would be best that the files were in lowercase in the zip-file itself.
I apologize for this. It seems to me that each time I put together a
release, I'm having to fix those filenames. I get new versions of the files
from a large variety of sources, and often times they come to me with the
first letter capitalized. When I unzip new files, I lose the names that I
fixed last time. And, unfortunately, I don't always catch each and every
file each and every time. I have a little utility that renames all files to
lowercase, but I forgot to use it this time.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Andrews wrote:
>
> Hi Nathan,
>
> The manual gives the displace warp syntax as
>
> warp { displace { PATTERN, COLOR_MAP } type TYPE }
>
> which is what went into the MP+ manual as well.
>
> I understand the correct syntax (at least, it works for me) is
>
> warp { displace { PIGMENT_BODY type TYPE } }
>
> which means you can put in anything from a declared pigment name to a
> full compound pigment pattern ...
>
When we are talking about the displace warp documentation i would also suggest
to change the description how it works:
right now it says:
'In type 1, the brightness of the pigment color determines the directions and
amounts points are pushed.'
which is perfectly right, but does not describe things very detailed. I would
either suggest (derived from what Chris Huff wrote in p.g.):
'It displaces the pattern according to the differences in brightness of the
control pigment's color away from brighter and towards darker areas.'
or in more mathematical terms:
'It displaces the pattern according to the gradient vector of the control
pigment's color.'
I hope suggestion this doesn't sound too picky, but since the displace warp
seems a quite important new feature, I thought it should have a complete
description.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39EB1876.6DE59632@reading.ac.uk>, Michael Andrews
<M.C### [at] readingacuk> wrote:
> The manual gives the displace warp syntax as
> warp { displace { PATTERN, COLOR_MAP } type TYPE }
> which is what went into the MP+ manual as well.
That should have been:
warp { displace { PATTERN, COLOR_MAP type TYPE} }
> I understand the correct syntax (at least, it works for me) is
> warp { displace { PIGMENT_BODY type TYPE } }
> which means you can put in anything from a declared pigment name to a
> full compound pigment pattern ...
You are right, anything that can be used in a pigment can be used there.
I'm not quite sure what I was thinking when I wrote that...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vahur Krouverk <vah### [at] aetecee> wrote:
> Nathan Kopp wrote:
> >
> > We are happy to announce the release of MegaPov 0.6a. This is a bugfix
> > release to clean up some problems with MegaPov 0.6.
> >
> I'm happy to hear this!
> But during testing of my patch I've found memory leak in old version
> (0.6) and seems like it ain't fixed in new version either:
> Function InitMallocCaches in file lighting.c allocates cache sizes
> (ShadowMediaListCacheSize, LightingMediaListCacheSize &
> MediaIntervalCacheSize), but does not free them in DeInitMallocCaches.
I discovered those memory leaks while working on 0.6. They were fixed
there and they remain fixed in 0.6a.
In lighting.c at about line 6804 in function DeInitMallocCaches() you
will find a block of code which starts like this:
/*YS sept 17 2000 memory leak fix */
if ( ShadowMediaListCacheSize != NULL)
POV_FREE(ShadowMediaListCacheSize);
ShadowMediaListCacheSize=NULL;
[...]
Are you sure you use the most recent sources and not those that were on
Nathans home page for a few hours when 0.6 was released? They were not
those of the release 0.6 at that time.
Yvo Smellenbergh
--
e-mail:sme### [at] skynetbe
http://users.skynet.be/smellenbergh
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"smellenbergh" <sme### [at] skynetbe> wrote...
>
> I discovered those memory leaks while working on 0.6. They were fixed
> there and they remain fixed in 0.6a.
> In lighting.c at about line 6804 in function DeInitMallocCaches() you
> will find a block of code which starts like this:
>
> /*YS sept 17 2000 memory leak fix */
> if ( ShadowMediaListCacheSize != NULL)
> POV_FREE(ShadowMediaListCacheSize);
> ShadowMediaListCacheSize=NULL;
> [...]
>
My bad. Actually, somehow that bugfix didn't yet get into my source. I
wish we had some kind of central repository, so we wouldn't have these kind
of synchronization problems. :-(
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nathan Kopp" <Nat### [at] Koppcom> wrote...
>
> My bad. Actually, somehow that bugfix didn't yet get into my source. I
> wish we had some kind of central repository, so we wouldn't have these
kind
> of synchronization problems. :-(
Well, my sloppy release of version 0.6 is continuing to haunt me. :-( As
it turns out, I was missing a few other memory leak fixes, as well as the
blob bounding-box fix and one other bugfix. All of these were supposed to
be in 0.6, but somehow I missed them. I was very careful to incorporate all
of the 0.6a fixes this time, but I had already missed these. The new
version is now uploaded. Well, yet again there will be a "bad" version of
WinMegaPov floating around out there.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
> My bad. Actually, somehow that bugfix didn't yet get into my source. I
> wish we had some kind of central repository, so we wouldn't have these kind
> of synchronization problems. :-(
SourceForge ??
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Berger wrote in message <39EB1884.F97AC1BD@enst.fr>...
> Unfortunately, Windows has its own ideas about which letters should be
>upper case and which lower case, and AFAIK there's no easy way to change
>that.
Windows 98 and Windows NT 4 allow mixed-case filenames:
Windows 98: Under the "Folder Options" control panel, select the "View" tab,
then, in "Advanced Settings", check the "Allow all uppercase names" box.
Windows NT: Something similar. I don't have access to a copy right now.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you for continuing to supply the official gooey...=)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, I'm bugging again :o(
When I run MegaPov test scenes, then I observed, that spline demos does
not free all the memory. More specifically, problem seems to be in
eval_3d_spline function. By examining code I found, that function
Parse_Num_Factor in express.c allocates memory for spline name when
parsing EVAL_3D_SPLINE_TOKEN, but does not free it. In case of
EVAL_SPLINE_TOKEN this spline name memory freeing is fixed, but
apparently 3d version was omitted.
In order to correct this, following line should be added before break
statement for case EVAL_3D_SPLINE_TOKEN:
POV_FREE(Local_String);
Well, thats all I have to type ;o)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
