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

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