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