I was thinking that it would be cool to add the existing julia_fractal
object type as a pattern type to the fractal patch. The syntax would be
something like:

  pigment
  { julia_fractal { (julia fractal things) }
    color_map { (colors) }
  }

  The julia_fractal block could be exactly as in the object (it could be
cool if a previously declared julia_fractal identifier could be used as
a pattern type as well...)

  This, however, is a bigger work than I expected. I certainly don't know
enough about the povray source to make this easyly.
  I have some questions:

  1) Can I use an object definition as a pattern type? If yes, what would be
the easiest way?

  2) Is there any way in the existing julia_fractal code to get the number
of iterations (and other information) for a specific point in space?

  I would like to do this myself, but if some of you patch gurus feel like
making this by yourselves would be a piece of cake, I would not mind at all.
I would really like to see this feature in povray and would definitely not
care at all who makes it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 7 Dec 1999 07:34:21 -0500, Nieminen Juha wrote:
>  1) Can I use an object definition as a pattern type? If yes, what would be
>the easiest way?

Probably, yes.  The easiest thing to do is probably start with Chris Huff's 
object-based pattern code, because he's probably already gone to the trouble 
to add a pointer to the associated object (and associated constructor/copy/
destructor code) to TPAT_FIELDS.  He'll also have added some parse code you
can use as an example of how to do it yourself.

>  2) Is there any way in the existing julia_fractal code to get the number
>of iterations (and other information) for a specific point in space?

A fractal object has "virtual functions," one of which is (rougly)
Iterate( vector, fractal *).  That function returns true if the iteration
count exceeds the maximum, else it returns false.  With application of 
some elbow grease, you could change the implementations of that function
(in quatern.c, one for each evaluation method) to take a pointer to an 
iteration count in addition.  You wouldn't even have to change any of 
the current places it gets called, since it gets called through a macro
defined in fractal.h.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

This sounds quite complicated to me. I also have a continuous lack of time
(studies, work, lots of other projects, a life to live...).
  Anyone else willing to do this?-)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <384d0ae5@news.povray.org>, ron### [at] povrayorg wrote:

> Probably, yes.  The easiest thing to do is probably start with Chris 
> Huff's object-based pattern code, because he's probably already gone
> to the trouble to add a pointer to the associated object (and associated 
> constructor/copy/destructor code) to TPAT_FIELDS.

Actually, there might be a bug in the way I did it. I intended to have 
it take a pointer to the actual object instead of copying the object to 
the pattern structure, but the code I wrote might not have done that(due 
to a possible misunderstanding of how identifiers are handled by the 
parser).
I ran into this when I added my patches together into one patch, and the 
object pattern crashed unless I added code to copy the object.
Of course, I will be looking at this closer, and it probably also 
affects my proximity pattern.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On Tue, 07 Dec 1999 15:24:28 -0500, Chris Huff wrote:
>In article <384d0ae5@news.povray.org>, ron### [at] povrayorg wrote:
>
>> Probably, yes.  The easiest thing to do is probably start with Chris 
>> Huff's object-based pattern code, because he's probably already gone
>> to the trouble to add a pointer to the associated object (and associated 
>> constructor/copy/destructor code) to TPAT_FIELDS.
>
>Actually, there might be a bug in the way I did it. I intended to have 
>it take a pointer to the actual object instead of copying the object to 
>the pattern structure, but the code I wrote might not have done that(due 
>to a possible misunderstanding of how identifiers are handled by the 
>parser).

Yes.  #declared objects are freed at the end of parsing.  Even if they
weren't, you run the risk of one being redefined or undefined, which would
also free them.  You must copy the object if you intend to use it later.
My functions that work with #declared objects get away with using a 
reference because they happen entirely at parse time.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message