In article <3a07cfe7@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> my english may be poor sometimes :-(
> 
> Chris Huff wrote in message ...
> >> but you put sign "=" between meaning of "all" and "gray"
> >> is it true in other color spaces ?
> >
> >The "=" operator isn't used in this patch...I don't know what you mean.
> 
> I mean that in your first post you don't know what is better
> name - "all" or "gray" - but you don't precise what "all" should
> represent - if the same as gray than what should be used for
> all curves in other color spaces ?

Oh, I see what you mean, "all" will mean something different in other 
color spaces...I will probably change it to use "rgb" instead of "all".

> > > >Your syntax will cause confusion("I can modify red and green at 
> > > >the same time, but not blue and saturation?").
> > > it depends of implementation in your planned patch :-)
> > No, it doesn't. For example, you can't manipulate red and hue 
> > simultaneously... yes I know this

But your syntax would allow something like:
red SPLINE hue SPLINE
which doesn't make sense.


(interesting stuff about color syntax)

I have been thinking about new ways of specifying colors(which I still 
think is a separate issue from the curves filter), but I would use a 
slightly different syntax:
color           (tells POV a color is coming)
rgb|hsl|cmy|    (color space name)
< c1, c2, c3>   (A 3 component vector specifying the color values)

Keywords red, green, and blue wouldn't be used any more, at least not 
for specifying colors. You wouldn't need hue, saturation, magenta, 
yellow, etc. either. This would be less backwards compatible, but 
simpler and better for future syntax. It would be easier for new users 
to learn, and doesn't have the problem of someone specifying something 
like "red Something hue SomethingElse".
Filter and transmit wouldn't be specified as part of the color, they 
would be part of a separate "transparency" block in the pigment. Layered 
textures would also have a way to specify different transparency effects 
that would only affect the texture layering.

Splines would be able to directly replace color maps:
pigment {
    PATTERN
    color_spline rgb|hsl|cmy spline {...}
    color_spline rgb|hsl|cmy spline {...}, spline {...}, spline {...}
}
This is something that should be easy to add while keeping the current 
syntax.
Or maybe just use one spline that interpolates between colors...that 
would be very easy to do, since splines can already interpolate between 
5-dimensional vectors. However, it would make modifying one color a bit 
more difficult.

-- 
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 ...
>In article <3a07969c@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>I've never used POV_REALLOC()(or realloc())...maybe it is a bug in the
>pov_realloc() function. Did you get it working with realloc(), or did
>you try some other way?


POV_REALLOC() is just a wrapper for pov_realloc(), which itself calls
realloc().  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.

>> #declare Spl[2].t = 0.4; // Sets the t value
>
>I think f and t are already reserved for filter and transmit...you would
>have to use something else.


As of POV 3.1g, t is only used for referring to the fourth component of a
four-dimensional vector.  Thus, it is available for using here, since all
splines are technically 5-dimensional vectors.

>> Arrays of splines would be treated as multi-dimensional arrays, with the
>> last dimension being the spline index.
>
>This probably would work...it certainly looks simpler and cleaner than
>my syntax, though a bit less clear in some rare circumstances.
>How about a similar syntax for getting textures, pigments, colors, etc.
>from blend maps?


Possible.  I don't know how difficult it will be to implement.

>These definitely need fixing...
>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.

--
Mark

Post a reply to this message

Chris Huff wrote in message ...
>I just use MegaPOVPlus
>as a way to develop my patches to a point where they are complete enough
>to be added to MegaPOV and to play around with patches by other people
>before they have a chance to get into MegaPOV.


This is the same thing I'm doing with SkyPOV.

--
Mark

Post a reply to this message

Mark Wagner wrote:
> 
> Chris Huff wrote in message ...
> 
> >These definitely need fixing...
> >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.
> 

( NB! Shameless self-promotion follows ;o)
If You can read _my_ C code, then download source code for POVMan and
look file shdrexec.c, it contains implementation for Catmull-Rom,
Hermite, Bezier and B-splines.
(Or alternatively mail me and I'll send You only this file...)
HTH

Post a reply to this message

Chris Huff wrote:
> 
> But your syntax would allow something like:
> red SPLINE hue SPLINE
> which doesn't make sense.
> 
> (interesting stuff about color syntax)
> 
> I have been thinking about new ways of specifying colors(which I still
> think is a separate issue from the curves filter), but I would use a
> slightly different syntax:
> color           (tells POV a color is coming)
> rgb|hsl|cmy|    (color space name)
> < c1, c2, c3>   (A 3 component vector specifying the color values)
> 
> Keywords red, green, and blue wouldn't be used any more, at least not
> for specifying colors. You wouldn't need hue, saturation, magenta,
> yellow, etc. either.
	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...

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

> Filter and transmit wouldn't be specified as part of the color, they
> would be part of a separate "transparency" block in the pigment. Layered
> textures would also have a way to specify different transparency effects
> that would only affect the texture layering.
> 
	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...

	Just my 2 copecks,

-- 

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