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