Chris Huff wrote in message ...
> Anyway, this is the syntax I am planning to use(I am currently working
> on the first form):

don't you like pov schema for color definition ?

> curves {rgb RED_SPLINE, GREEN_SPLINE, BLUE_SPLINE}

curves {red RED_SPLINE green GREEN_SPLINE blue BLUE_SPLINE}

> curves {red RED_SPLINE}
> curves {green GREEN_SPLINE}
> curves {blue BLUE_SPLINE}

ok.

> curves {gray GRAY_SPLINE}
> (got a better name for the last one? "all"?)


curves {rgb GRAY_SPLINE}

ABX

Post a reply to this message

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

> Chris Huff wrote in message ...
> > Anyway, this is the syntax I am planning to use(I am currently working
> > on the first form):
> 
> don't you like pov schema for color definition ?

Uh, POV doesn't let you specify colors with splines. And you don't 
specify colors in the curves patch, it simply reuses the keywords as 
names for color channels.

Some of those would be pretty easy to do, but they would just be 
confusing...since you are not specifying a color. Would you like it 
better if it required the "type" keyword before the type?
And anyway, the syntax I use is better suited for expansion to other 
color spaces. I plan to allow other color spaces to be manipulated by 
adding a filter to convert to those spaces, but a future version of the 
curves patch may allow a shortcut for modifying those spaces. Your 
syntax will cause confusion("I can modify red and green at the same 
time, but not blue and saturation?").

-- 
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 ...
>Uh, POV doesn't let you specify colors with splines.

yes, I know
but this could be useful - color curves like color_map

#declare Curve=curve{red Spline1 green Spline2 filter Spline3}
#declare Pigment=pigment{pattern color_map{curve Curve}}

therefore I thought about similiar syntax
this also allow extension to other color spaces I think

>And anyway, the syntax I use is better suited for expansion to other
>color spaces.

but you put sign "=" between meaning of "all" and "gray"
is it true in other color spaces ?

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

ABX

Post a reply to this message

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

> >I don't have any experience with growing dynamically allocated
> >arrays...I tend to use linked lists for everything.
> I've already got the code for this written -- it's just a matter of 
> copying it from my personal version to SkyPOV.

:-)


> I think that, usage-wise, it would be better to use the array syntax. 
>  This would allow points to be changed and read using a single 
> syntax.

Arrays don't have any special syntax for insertion...and I don't think 
reading the points with [] brackets will be very easy. As for changing 
existing points...what would this do?
#declare Spl[2] = 0.4;

Would this set the t value of the third point to 0.4, or would it set 
the x value? Also, this syntax would be a problem for using arrays of 
splines.

I would suggest using functions for most of these:

Getting number of control points:
INT spline_points(SPLINE_IDENT)

Reading a point:
FLOAT get_spline_t(SPLINE_IDENT, INDEX)
Returns the "distance" of the point at INDEX.

EXPRESS get_spline_value(SPLINE_IDENT, INDEX)
Returns the value of the spline at INDEX. I'm not sure how to handle 
floats, vectors, and colors...maybe this function will work for all of 
them.

Modifying a point:
set_spline_t(SPLINE_IDENT, INT_INDEX, FLOAT_NEW_T)
Changes the "distance" of the point at INDEX.

set_spline_value(SPLINE_IDENT, INT_INDEX, EXPRESS_VALUE)
Changes the value of the spline at INDEX. You can specify a float, 
vector, color...

Adding a point should be possible already, it should work fine with the 
modifications I made(mainly the fix to Copy_Spline()). Just do something 
like this:
#declare Spline = spline {Spline NEW_POINTS}

And one other thing that should probably be taken care of: multiple 
points with the same t value should probably not be allowed. New points 
with the same t value of an existing point should replace that point. I 
don't remember seeing anything about this in the source code...

-- 
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 <3a06b03e@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> but this could be useful - color curves like color_map
> 
> #declare Curve=curve{red Spline1 green Spline2 filter Spline3}
> #declare Pigment=pigment{pattern color_map{curve Curve}}

I have been thinking the possibility of something like this...I think it 
might be useful. But I don't think it applies to the curves patch...


> this also allow extension to other color spaces I think

No, it won't. See explanation below.


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


> >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, you can only manipulate one color space at a time. This 
is because saturation and hue affect red, green, and blue, and the same 
goes for the reverse. My syntax will allow the addition of hsl, hue and 
saturation modes, yours won't, at least not in a way that makes sense. 
However, those shouldn't be necessary anyway, since you can just use 
other conversion filters before and after the curves filter to get the 
same result. So we are back to whether or not to use the color syntax 
for splines.

What exactly is deficient in the syntax I chose? Why do you think 
specifying splines representing color channel curves with a color-like 
syntax is a better idea than specifying a channel and a spline to go 
with it?

-- 
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 <3a06459f$1@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>> >I don't have any experience with growing dynamically allocated
>> >arrays...I tend to use linked lists for everything.
>> I've already got the code for this written -- it's just a matter of
>> copying it from my personal version to SkyPOV.
>


Update: I implemented it today.  For unknown reasons, POV_REALLOC doesn't
work properly for this.  I'm using Borland C++ Builder 4.0, if that makes
any difference.

>
>> I think that, usage-wise, it would be better to use the array syntax.
>>  This would allow points to be changed and read using a single
>> syntax.
>
>Arrays don't have any special syntax for insertion...and I don't think
>reading the points with [] brackets will be very easy. As for changing
>existing points...what would this do?
>#declare Spl[2] = 0.4;


The obvious fix would be to do something like
#declare Spl[2].x = 0.4; // Sets the x value at the fourth item
#declare Spl[2].y = 0.4; // Sets the y value at the fourth item
#declare Spl[2].z = 0.4; // Sets the z value at the fourth item
#declare Spl[2].red = 0.4; // Sets the red value at the fourth item (same as
.x)
#declare Spl[2].green = 0.4; // Sets the green value at the fourth item
(same as .y)
#declare Spl[2].blue = 0.4; // Sets the blue value at the fourth item (same
as .z)
#declare Spl[2].filter = 0.4; // Sets the filter value at the fourth item
#declare Spl[2].transmit = 0.4; // Sets the transmit value at the fourth
item
#declare Spl[2].t = 0.4; // Sets the t value


Arrays of splines would be treated as multi-dimensional arrays, with the
last dimension being the spline index.

>Adding a point should be possible already, it should work fine with the
>modifications I made(mainly the fix to Copy_Spline()). Just do something
>like this:
>#declare Spline = spline {Spline NEW_POINTS}


It does.

>And one other thing that should probably be taken care of: multiple
>points with the same t value should probably not be allowed. New points
>with the same t value of an existing point should replace that point. I
>don't remember seeing anything about this in the source code...


The source code doesn't do anything about this right now.  I'll add that to
my list of things to do.

On the lines of splines and the problems with them:
1) Parse_Spline() will accept "quadratic_spline", but quadratic splines does
not exist.  They are treated as cubic splines.

2) Cubic interpolation is not done properly.  It appears that the "cubic
interpolation" is actually done by averaging two quadratic interpolations of
the spline data.  Fixing this will result in minor changes to all scenes
that use cubic splines.

--
Mark

Post a reply to this message

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 ?

>> >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, you can only manipulate one color space at a time.
This
> is because saturation and hue affect red, green, and blue, and the
same
> goes for the reverse.

yes I know this

> My syntax will allow the addition of hsl, hue and
> saturation modes, yours won't, at least not in a way that makes sense.
> However, those shouldn't be necessary anyway, since you can just use
> other conversion filters before and after the curves filter to get the
> same result. So we are back to whether or not to use the color syntax
> for splines.
> What exactly is deficient in the syntax I chose? Why do you think
> specifying splines representing color channel curves with a color-like
> syntax is a better idea than specifying a channel and a spline to go
> with it?


I don't think that your syntax is wrong
but I think that there should be first discussion
about implement other color spaces in all ways where old colors
can be use, than how to extend it to use curves and than
use this curves syntax in post-processes
your way is to implement it to one usage but
perhaps it is hardly to extend in the future for rest of pov syntax

perhaps:
COLOR_DEFINITION:
  color SPACE_NAME value_for_all | SPACE_COORDINATES
SPACE_NAME:
  rgb | hsl | hue | etc ...
SPACE_COORDINATES:
  vector | COORDINATES_SPECIFICATION
COORDINATES_SPECIFICATION:
  COORDINATE_IN_SPACE value_of_coordinate
  [COORDINATE_IN_SPACE value_of_coordinate ...]
COORDINATE_IN_SPACE:
  red | green | blue | cyan | magenta | filter | transmit | saturation
...

as you see this is nearly the same like old definition
and not to much to change in old scripts

COLOR_MAP:
  color_map {
    curve { SPACE_NAME curve_identifier } /* for all coordinates in
space */
    curve { SPACE_NAME
      COORDINATE_IN_SPACE curve_identifier
      [COORDINATE_IN_SPACE value_of coordinate ...]
    } /* for specification */
  }

i'm not specialist, forgive me than if i'm wrong with something
and what's more important - since year I slowly but carefully
read archiv of news.povray.org, but still I have
46205 messages to read - perhaps there is discussion of our problem

ABX

Post a reply to this message

In article <8FE01D1B3markwagner17gtenet@204.213.191.228>,
mar### [at] gtenet  wrote:
> Announcing.....SkyPOV 0.1!
> SkyPOV is an unofficial version of POV-Ray designed to do atmospheric 
> effects.  It is based on MegaPOV 0.6a.  Due to computer problems beyond
> my  control, it is currently available only as source code.  If I can
> find  time, I will upload a Windows binary tomorrow.  If I can't, it
> will be  available next Tuesday.
> To compile, download the SkyPOV and MegaPOV 0.6a source code, copy the 
> SkyPOV source over the MegaPOV source, and compile.

  Out of curiousity, have you looked at possibly just integrating your
changes into MegaPOV for a 0.7 release?  I'm only asking, becouse with
all of the 'sub releases' of different things, it could get confusing
over time..  This really also applies for 'MegaPOVPlus' as well.

Post a reply to this message

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

> Update: I implemented it today.  For unknown reasons, POV_REALLOC doesn't
> work properly for this.  I'm using Borland C++ Builder 4.0, if that makes
> any difference.

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?


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


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


> 2) Cubic interpolation is not done properly.  It appears that the 
> "cubic interpolation" is actually done by averaging two quadratic 
> interpolations of the spline data.  Fixing this will result in minor 
> changes to all scenes that use cubic splines.

These definitely need fixing...
Hmm, another thing that would be nice is a larger assortment of spline 
types. Catmull-rom, b-splines, etc...
Keep up the good work.

-- 
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 <3a085f02$1@news.povray.org>, "Thomas Charron" 
<tch### [at] ductapenet> wrote:

>   Out of curiousity, have you looked at possibly just integrating your
> changes into MegaPOV for a 0.7 release?  I'm only asking, becouse with
> all of the 'sub releases' of different things, it could get confusing
> over time..  This really also applies for 'MegaPOVPlus' as well.

SkyPOV and MegaPOVPlus are based on MegaPOV, so their features are 
already integrated into MegaPOV. And whether or not features in them get 
into the next release of MegaPOV depends mostly on Nathan(who is also 
busy working on POV 3.5) and the Smellenberghs...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.

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