In article <3a08ea5b$1@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> POV_REALLOC() is just a wrapper for pov_realloc(), which itself calls 
> realloc(). 

But it isn't a direct call to realloc(). There is still room for a bug 
in there...it seems strange that you couldn't get it to work.


> My solution is to call POV_MALLOC() to create a larger array, 
> followed by memcpy() to copy the old array to the new, and POV_FREE() 
> to get rid of the old array.

I thought realloc() was supposed to make it so you didn't have to do 
this. :-(
I was wondering if calling realloc() directly might bypass something 
POV's functions are breaking.


> >Hmm, another thing that would be nice is a larger assortment of spline
> >types. Catmull-rom, b-splines, etc...
> I'll do so if someone can point out some references for these, 
> preferably with C code examples.  I'm having enough trouble trying to 
> decipher the cryptic pseudo-code from my Numerical Analysis textbook 
> to want to deal with Fortran.

Hmm, my copy of "3D Graphics Programming" has some explanations of 
cubic, Hermite, and Bezier splines...not that I can make much sense of 
it. Not much in the way of examples either...mostly just the math.

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

<Jer### [at] enstfr> wrote:

> 	Why not? Actually, red SOMETHING hue SOMETHING does make sense: first
> work in rgb color-space and change red without touching green and blue,
> then work in hsl and change hue without touching saturation or
> brightness...

But what would the resulting vector be? Would it be a rgb vector, or a 
hsl, etc...
#declare Color = color red 0.6 hue 0.75;
Is Color.x red or hue? Is Color.y green or saturation?
"color rgb" should only accept red, green, and blue...


> 	This would make for an easy way to get the grayscale equivalent of a
> color for example (color rgb <whatever> saturation 0) or other effects
> of the kind...

I think this would be better done with color conversion functions, not 
the color specification. The idea is that you pick a color space and 
then set each component, when you try to set a component that isn't part 
of the color space things get messy. To get the grayscale of a color, it 
would be something like:
#declare Color = color rgb rgb_to_hsl(<whatever>).z;


> 	I prefer to have the color and transparency defined together (the way
> they are now) since they usually follow the same pattern. Needing to
> specify the pattern twice would be redundant, more difficult and
> error-prone...

It could be done so you don't have to specify the pattern twice, and it 
would give much more flexibility. And I never have understood why 
transparency was considered part of the color...the only explanation I 
can think of is that it developed from the use of alpha channels in 
images. It seems more of an interior feature to me, or a separate 
texture attribute.
And they usually follow the same pattern because it would be very 
difficult (impossible?) to get them to do otherwise with the current 
syntax. If it was easily possible to do it differently that might not be 
the case.

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

In article <3A01D3E8.8C98EF92@unforgettable.com>, 
inq### [at] unforgettablecom wrote:

> So to those of you out there concerned with such things.. how long until
> someone churns out a Mac binary? What are the odds that any of this will
> be added to the next version of the Ultra-Giganto Patch?

I plan on including these features in MegaPOVPlus, but probably not 
until the next version of SkyPOV is released.

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

Chris Huff wrote in message ...
>I plan on including these features in MegaPOVPlus, but probably not
>until the next version of SkyPOV is released.


The next version of SkyPOV will be released when I've managed to get the
splines working properly.

--
Mark

Post a reply to this message

Chris Huff wrote in message ...
>> My solution is to call POV_MALLOC() to create a larger array,
>> followed by memcpy() to copy the old array to the new, and POV_FREE()
>> to get rid of the old array.
>
>I thought realloc() was supposed to make it so you didn't have to do
>this. :-(
>I was wondering if calling realloc() directly might bypass something
>POV's functions are breaking.


There's a very good reason for using POV_REALLOC etc.: garbage tracking and
collection.  By using the POV_*ALLOC functions, it is much easier to track
down memory leaks.

>
>> >Hmm, another thing that would be nice is a larger assortment of spline
>> >types. Catmull-rom, b-splines, etc...
>> I'll do so if someone can point out some references for these,
>> preferably with C code examples.  I'm having enough trouble trying to
>> decipher the cryptic pseudo-code from my Numerical Analysis textbook
>> to want to deal with Fortran.
>
>Hmm, my copy of "3D Graphics Programming" has some explanations of
>cubic, Hermite, and Bezier splines...not that I can make much sense of
>it. Not much in the way of examples either...mostly just the math.


I'll see what Vahur Krouverk's code is like for this.

--
Mark

Post a reply to this message

Chris Huff wrote:
> 
> But what would the resulting vector be? Would it be a rgb vector, or a
> hsl, etc...
> #declare Color = color red 0.6 hue 0.75;
> Is Color.x red or hue? Is Color.y green or saturation?
	Whatever you do, you'll need a unique internal representation (which
should probably be rgb to avoid breaking something elsewhere in the
code). If Color.(x/y/z) is to make any sense, it would be with relation
to this internal representation. I personnally would favor using
Color.red or Color.hue...

> I think this would be better done with color conversion functions, not
> the color specification. The idea is that you pick a color space and
> then set each component, when you try to set a component that isn't part
> of the color space things get messy. To get the grayscale of a color, it
> would be something like:
> #declare Color = color rgb rgb_to_hsl(<whatever>).z;
> 
	This makes for more things to type and isn't any clearer or easy to
understand. Moreover, if you need to remember in wich space you defined
each color, you're in for a lot of bugs in your scenes ("Why the h*** is
that sphere white instead of blue???")

> It could be done so you don't have to specify the pattern twice, and it
> would give much more flexibility. And I never have understood why
> transparency was considered part of the color...the only explanation I
> can think of is that it developed from the use of alpha channels in
> images. It seems more of an interior feature to me, or a separate
> texture attribute.
> And they usually follow the same pattern because it would be very
> difficult (impossible?) to get them to do otherwise with the current
> syntax. If it was easily possible to do it differently that might not be
> the case.
> 
	Maybe, but OTOH you don't need to specify a color where the object is
fully transparent, so their patterns are related. I've never felt the
need to specify transparency independently from color...


-- 

* 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

In article <3a0a439b@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> There's a very good reason for using POV_REALLOC etc.: garbage 
> tracking and collection.  By using the POV_*ALLOC functions, it is 
> much easier to track down memory leaks.

But that won't help you figure out if there is a bug in POV_REALLOC(). 
:-)
I can understand working around it using the POV_*() functions, but I 
was talking about figuring out where the problem was. Oh, well...there 
are a couple places in my work with glows that could use POV_REALLOC(), 
I will try to figure it out myself...


> >Hmm, my copy of "3D Graphics Programming" has some explanations of
> >cubic, Hermite, and Bezier splines...not that I can make much sense of
> >it. Not much in the way of examples either...mostly just the math.
> I'll see what Vahur Krouverk's code is like for this.

And I'll poke around in the "other" spline patch...I think it had 
something like a "rational bezier spline".

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

In article <3a0a3db8$1@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> The next version of SkyPOV will be released when I've managed to get the
> splines working properly.

No hurry. :-)
I have plenty of other coding stuff to do(I think I finally got glows to 
attach to objects properly!), and plenty of other stuff that I *should* 
do...MP+ 0.6a mod 0.1 will have some other new stuff.

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

<jbe### [at] tapasmailnet> wrote:

> 	Maybe, but OTOH you don't need to specify a color where the object is
> fully transparent, so their patterns are related. I've never felt the
> need to specify transparency independently from color...

Simplest case: a multicolored transparent ball which is evenly 
transparent and has a big color_map. You decide you want to change the 
amount of transparency...you have to change every color in the 
color_map. If you had it specified in a separate block, you would only 
have to change one value. It would also make specifying transparence for 
image_maps a lot easier.

It becomes an even better idea when you add blurred transparency, etc.
Other programs do it because they often use image maps that use the 
alpha channel to define transparency...but does *tranparency* really 
belong in a *color*? Especially in POV, where image maps are relatively 
rarely used.

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

Mark, did you ever post a Windows binary? Sorry, but my newsgroup time is
limited and this thread is full of messages...

Grim

Post a reply to this message