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.

Source is available at
http://www.geocities.com/rengaw03/download/wskypovs.zip


Features:
 * Wavelength-dependant Rayleigh scattering
 * Infinite-light hack -- needed to make wavelength-dependant scattering
   look good
 * A few notes on how to use the program.
 * Two or three demo scenes

Features that might make a future version:
 * Colour curve post-processing to replace the infinite-light hack
 * Random rendering order
 * A polynomial parser to allow polys to be written as "3x^5+2xy+z-1" etc.
 * Assorted minor optimizations
 * Improved "quality" command-line options
 * Improved splines
 * Render time prediction
 * Fixed memory leaks

Might make it into version 99999
 * Variable IOR
 * Non-linear transforms
 * Spectral ray-tracing



--
Mark Wagner

Post a reply to this message

Mark Wagner 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.
>
> Source is available at
> http://www.geocities.com/rengaw03/download/wskypovs.zip
>
> Features:
>  * Wavelength-dependant Rayleigh scattering
>  * Infinite-light hack -- needed to make wavelength-dependant scattering
>    look good
>  * A few notes on how to use the program.
>  * Two or three demo scenes
>
> Features that might make a future version:
>  * Colour curve post-processing to replace the infinite-light hack
>  * Random rendering order
>  * A polynomial parser to allow polys to be written as "3x^5+2xy+z-1" etc.
>  * Assorted minor optimizations
>  * Improved "quality" command-line options
>  * Improved splines
>  * Render time prediction
>  * Fixed memory leaks
>
> Might make it into version 99999
>  * Variable IOR
>  * Non-linear transforms
>  * Spectral ray-tracing
>
> --
> Mark Wagner

Sounds good!
Go hell, TerraGen  ;-)

Can someone upload a compiled version? (maybe on your homepage, Nathan?)

Paul

Post a reply to this message

In article <8FE01D1B3markwagner17gtenet@204.213.191.228>, 
mar### [at] gtenet (Mark Wagner) wrote:

> Features that might make a future version:
>  * Colour curve post-processing to replace the infinite-light hack

I am going to make a post_process filter which uses a spline to adjust 
color values...is this what you are talking about?


>  * Random rendering order

You mean it picks a random pixel each time? Another thing that might be 
nice: some kind of "progressive" antialiasing, that renders the image 
without antialiasing and then makes several "refinement" passes.


>  * A polynomial parser to allow polys to be written as "3x^5+2xy+z-1" 
>  etc.

Couldn't you use isosurface functions? I haven't had a look at your 
patch yet, so I don't really know what this is for...


>  * Improved "quality" command-line options

I hope command line options aren't necessary for this...you should be 
able to specify all options in the scene file. Or are you talking about 
changing the "Render Quality" option syntax?


>  * Improved splines

I would suggest using one of the spline patches...less duplicate code, 
more standardized, etc...

-- 
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 povray.general Mark Wagner <mar### [at] gtenet> wrote:
:  * A polynomial parser to allow polys to be written as "3x^5+2xy+z-1" etc.

  Why, when we have isosurface functions already?

  Isosurfaces even render faster than polys (I had a hard time admitting this
at the beginning, but currently I'm quite happy about this).

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

Post a reply to this message

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

OH YEAH, BABY!! XD

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?

-Xplo

Post a reply to this message

Chris Huff wrote in message ...
>In article <8FE01D1B3markwagner17gtenet@204.213.191.228>,
>mar### [at] gtenet (Mark Wagner) wrote:
>
>> Features that might make a future version:
>>  * Colour curve post-processing to replace the infinite-light hack
>
>I am going to make a post_process filter which uses a spline to adjust
>color values...is this what you are talking about?


Yes.

>
>>  * Random rendering order
>
>You mean it picks a random pixel each time? Another thing that might be
>nice: some kind of "progressive" antialiasing, that renders the image
>without antialiasing and then makes several "refinement" passes.


That's going to be part of the system, since I can't do antialiasing with
just one pixel.

>
>>  * A polynomial parser to allow polys to be written as "3x^5+2xy+z-1"
>>  etc.
>
>Couldn't you use isosurface functions? I haven't had a look at your
>patch yet, so I don't really know what this is for...


I don't have it implemented yet, but this will be for the "poly" object
type.  It's much easier to enter a formula for a 7th-order polynomial as a
formula than as a string of a hundred coefficients.

>
>>  * Improved "quality" command-line options
>
>I hope command line options aren't necessary for this...you should be
>able to specify all options in the scene file. Or are you talking about
>changing the "Render Quality" option syntax?


Yes, render quality options.  I'm going to make it possible to turn specific
things on and off -- specifically, these will be available in version 0.2:
 +QQ = use quick colors
 +QA = use area lights -- cancels +QF
 +QF = use ambient only -- cancels +QA, +QM
 +QS = calculate shadows
 +QM = use reflection -- cancels +QF
 +QL = use refraction
 +QN = use normals
 +QV = use media?

>>  * Improved splines
>
>I would suggest using one of the spline patches...less duplicate code,
>more standardized, etc...


This is going to be an improvement on the spline{} syntax.

Mark

Post a reply to this message

Mark Wagner wrote in message
<8FE01D1B3markwagner17gtenet@204.213.191.228>...
>Announcing.....SkyPOV 0.1!


A Windows binary is available at:
http://www.geocities.com/rengaw03/download/wskypov.zip


Mark

Post a reply to this message

I tried to use the link provided but geocities said
that page was not available. I tried .../rengaw03/download/
and HAL invited me to go back.

sniff..... I so wanted to see this version.... sniff

Mark Wagner wrote:
> 
> Mark Wagner wrote in message
> <8FE01D1B3markwagner17gtenet@204.213.191.228>...
> >Announcing.....SkyPOV 0.1!
> 
> A Windows binary is available at:
> http://www.geocities.com/rengaw03/download/wskypov.zip
> 
> Mark

Post a reply to this message

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

> >I am going to make a post_process filter which uses a spline to adjust
> >color values...is this what you are talking about?
> Yes.

I will send you the code as soon as it is tested.


> >You mean it picks a random pixel each time? Another thing that might be
> >nice: some kind of "progressive" antialiasing, that renders the image
> >without antialiasing and then makes several "refinement" passes.
> That's going to be part of the system, since I can't do antialiasing with
> just one pixel.

Good. :-)


> I don't have it implemented yet, but this will be for the "poly" 
> object type.  It's much easier to enter a formula for a 7th-order 
> polynomial as a formula than as a string of a hundred coefficients.

Oh, I thought this was for something else...this seems rather redundant, 
since you can just use isosurfaces to do the same thing, and 
often(usually?) with faster rendering.


> >I would suggest using one of the spline patches...less duplicate code,
> >more standardized, etc...
> 
> This is going to be an improvement on the spline{} syntax.

Oh...
Ok, what improvements are you thinking of? More spline types, the 
ability to choose what kind of spline to use at evaluation time?

By the second, I mean something like this:
#declare Spline = spline {...the usual spline stuff...}

#declare Val1 = Spline(XVal);
#declare Val2 = Spline(XVal, cubic_spline);
#declare Val3 = Spline(XVal, linear_spline);

Another wild idea that might be useful: allow splines to be used as 
color maps. :-)

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

"Mr. Art" wrote:
> 
> I tried to use the link provided but geocities said
> that page was not available. I tried .../rengaw03/download/
> and HAL invited me to go back.
> 

Ditto

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Chris Huff wrote in message ...
>In article <3a025559$1@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>> >I am going to make a post_process filter which uses a spline to adjust
>> >color values...is this what you are talking about?
>> Yes.
>
>I will send you the code as soon as it is tested.


Thanks!

>> >I would suggest using one of the spline patches...less duplicate code,
>> >more standardized, etc...
>>
>> This is going to be an improvement on the spline{} syntax.
>
>Oh...
>Ok, what improvements are you thinking of? More spline types, the
>ability to choose what kind of spline to use at evaluation time?
>
>By the second, I mean something like this:
>#declare Spline = spline {...the usual spline stuff...}


I'm going to be removing the limit on the number of points in a spline, and
making it possible to use the points from one spline as the basis for
another spline, like:

#declare Spline2 = spline{ Spline 1,<2,2,2> etc.}

Right now you can't do that.

--
Mark

Post a reply to this message

Margus Ramst wrote in message <3A03A18D.FDFBCBF0@peak.edu.ee>...
>"Mr. Art" wrote:
>>
>> I tried to use the link provided but geocities said
>> that page was not available. I tried .../rengaw03/download/
>> and HAL invited me to go back.
>>
>
>Ditto


How odd.  I just downloaded it successfully from that address.  Was it
giving you a "file not found" error, or some other error message?

Mark

Post a reply to this message

Try the links from my POV-Ray downloads page to see if they work for you.

http://www.geocities.com/rengaw03/povray.html


--
Mark

Post a reply to this message

Mark Wagner wrote:
> 
> Try the links from my POV-Ray downloads page to see if they work for you.
> 

Got it.
As far as I know Geocities doesn't like direct download links originating from
non-geocities addresses. Since your home page is also at Geocities, a link from
there will work.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

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

> >I will send you the code as soon as it is tested.
> Thanks!

I'm having a hard time getting it to work though...I suspect the problem 
is in my parsing code, though I'm not sure why it is misbehaving. 
Anyway, this is the syntax I am planning to use(I am currently working 
on the first form):
curves {rgb RED_SPLINE, GREEN_SPLINE, BLUE_SPLINE}
curves {red RED_SPLINE}
curves {green GREEN_SPLINE}
curves {blue BLUE_SPLINE}
curves {gray GRAY_SPLINE}
(got a better name for the last one? "all"?)

When I add color space conversion filters, you will be able to adjust 
other types with these filters(convert to another color space, modify 
the correct channel, convert back to rgb).


> I'm going to be removing the limit on the number of points in a spline, 

There is a limit? I hadn't noticed...


> and making it possible to use the points from one spline as the basis 
> for another spline, like:
> #declare Spline2 = spline{ Spline 1,<2,2,2> etc.}
> Right now you can't do that.

I noticed the Parse_Spline() function had the ability to take an 
identifier to create a copy of the spline, but also had a bug which made 
that useless when no new points were defined. I think it was intended to 
work the way you describe, allowing new points to be inserted.

Also, it would be useful if you could access the control points, with 
functions that behave similar to the array functions and an array-like 
syntax.

-- 
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 <chrishuff-DDBC53.06140904112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> I'm having a hard time getting it to work though...I suspect the problem 
> is in my parsing code, though I'm not sure why it is misbehaving. 

I found the problem, a rather nasty bug in Copy_Spline(). It allocates 
room for the spline data, but doesn't copy the old data to the new 
spline. I have no idea how this wasn't noticed before...the fixed 
version is below(all that was needed was the addition of one line, the 
call to memcpy()). I am still not sure it is right, I have never used 
memcpy() before, but it works. :-)

SPLINE2 * Copy_Spline(SPLINE2 * se)
{
    SPLINE2 * New;
    New = (SPLINE2 *)POV_MALLOC(sizeof(SPLINE2), "spline");
    
    New->SplineEntries = 
POV_MALLOC(se->Number_Of_Entries*sizeof(SPLINE_ENTRY), "spline entry");
    memcpy(New->SplineEntries, se->SplineEntries, 
se->Number_Of_Entries*sizeof(SPLINE_ENTRY));
    
    New->Number_Of_Entries = se->Number_Of_Entries;
    New->Type = se->Type;
    return New;
}

-- 
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 found the problem, a rather nasty bug in Copy_Spline(). It allocates
>room for the spline data, but doesn't copy the old data to the new
>spline. I have no idea how this wasn't noticed before...the fixed
>version is below(all that was needed was the addition of one line, the
>call to memcpy()). I am still not sure it is right, I have never used
>memcpy() before, but it works. :-)


Thanks!

--
Mark

Post a reply to this message

Chris Huff wrote in message ...
>In article <3a03ab54$1@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>(got a better name for the last one? "all"?)


"all" makes more sense than "grey".

>
>> I'm going to be removing the limit on the number of points in a spline,
>
>There is a limit? I hadn't noticed...


The limit is 256 points -- enough for most uses, but why have a limit when
there doesn't need to be one?

>Also, it would be useful if you could access the control points, with
>functions that behave similar to the array functions and an array-like
>syntax.


This might be very difficult to implement -- there are enough problems with
the spline syntax as it is.

--
Mark

Post a reply to this message

That worked much better. Thanks for the assist.

Mark Wagner wrote:
> 
> Try the links from my POV-Ray downloads page to see if they work for you.
> 
> http://www.geocities.com/rengaw03/povray.html
> 
> --
> Mark

Post a reply to this message

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

> "all" makes more sense than "grey".

That is what I finally implemented it as. It took me a while to figure 
out how to allow rgb, red, green, and blue to be used, though.


> The limit is 256 points -- enough for most uses, but why have a limit 
> when there doesn't need to be one?

It looks to me like that was just a stopgap measure...it looks like you 
could implement it mostly by adding code to the Insert_Spline_Entry() 
function.
I don't have any experience with growing dynamically allocated 
arrays...I tend to use linked lists for everything.


> >Also, it would be useful if you could access the control points, with
> >functions that behave similar to the array functions and an array-like
> >syntax.
> This might be very difficult to implement -- there are enough 
> problems with the spline syntax as it is.

I think could get it working with functions, but I have no idea how to 
do the array like syntax...
INT spline_points(SPLINE_IDENT) Retrieves the number of points in the 
spline.
EXPRESS get_spline_point(INT_INDEX) Returns the corresponding point on 
the spline.

BTW, I implemented the SPLINE_IDENT(T, TYPE) syntax. You can now do 
something like this:
#declare Spl = spline {linear_spline ...}

#declare Val1 = Spl(T);
#declare Val2 = Spl(T, cubic_spline);
#declare Val3 = Spl(T, quadratic_spline);

I will send you the code soon.

-- 
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 <chrishuff-AE6B1C.09490803112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> I will send you the code as soon as it is tested.

I've found a couple more bugs, for example, Insert_Spline_Entry() took a 
vector and tried to pass 5 float values through it. I changed that to an 
expression... However, it might be a good idea to have separate 
Insert_Spline_Vector_Entry() and maybe Insert_Spline_Float_Entry() 
functions for ease of use in other code.
I also cleaned up a lot of the code, mostly just reformatting it, but 
partly rewriting some functions. And I fixed some typos in the 
comments...:-)
I plan on doing more, but I thought you would like to have what I have 
done so far. I hope this is helpful in the work you are doing.
The spline code changes are here:
http://homepage.mac.com/chrishuff/mpovplus/splines.zip

I will upload the curves post_process patch soon.

-- 
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 Wagner wrote:
> 
> Chris Huff wrote in message ...
> >In article <3a03ab54$1@news.povray.org>, "Mark Wagner"
> ><mar### [at] gtenet> wrote:
> >
> >(got a better name for the last one? "all"?)
> 
> "all" makes more sense than "grey".
> 
	I think it depends on what the spline does exactly: is it the same as:
rgb SPLINE, SPLINE, SPLINE

	Or does it only change the brightness? A good thing to add too:
spline-based manipulations on hue and saturation...

		Jérôme
-- 
********************************* Jérôme M. BERGER
* 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 <3A059156.6903634A@enst.fr>, Jérôme M. Berger 
<Jer### [at] enstfr> wrote:

> > "all" makes more sense than "grey".
> 	I think it depends on what the spline does exactly: is it the same as:
> rgb SPLINE, SPLINE, SPLINE
> 	Or does it only change the brightness?

It uses the same spline to adjust each channel. The current value of the 
channel is taken as the "t" value of the spline, and the result of the 
spline is used as the new value for the channel.


> A good thing to add too: spline-based manipulations on hue and 
> saturation...

Not as a special feature of the spline patch...just use a rgb_to_hsl 
filter, then use the ordinary curves filter to adjust hue or saturation, 
then use hsl_to_rgb to get the corrected image back. More flexible, less 
complicated, and you can combine it with other things to get special 
effects. And I *am* planning to write these conversion filters...as soon 
as I figure out the math. I've found lots of information about 
converting between color spaces, but little or nothing about the actual 
equations used to convert between rgb and hsl. That, or I'm just not 
recognizing it when I see 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

In article <chrishuff-2DD880.12353405112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> ...as soon as I figure out the math. I've found lots of information 
> about converting between color spaces, but little or nothing about 
> the actual equations used to convert between rgb and hsl. That, or 
> I'm just not recognizing it when I see it...

Never mind, I just came across a couple files Nathan sent me which 
should do everything that I need. I had set them aside and completely 
forgotten about them...

-- 
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 <3a04ed21@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>> The limit is 256 points -- enough for most uses, but why have a limit
>> when there doesn't need to be one?
>
>It looks to me like that was just a stopgap measure...it looks like you
>could implement it mostly by adding code to the Insert_Spline_Entry()
>function.
>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.

>> >Also, it would be useful if you could access the control points, with
>> >functions that behave similar to the array functions and an array-like
>> >syntax.
>> This might be very difficult to implement -- there are enough
>> problems with the spline syntax as it is.
>
>I think could get it working with functions, but I have no idea how to
>do the array like syntax...
>INT spline_points(SPLINE_IDENT) Retrieves the number of points in the
>spline.
>EXPRESS get_spline_point(INT_INDEX) Returns the corresponding point on
>the spline.


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.

>BTW, I implemented the SPLINE_IDENT(T, TYPE) syntax. You can now do
>something like this:
>#declare Spl = spline {linear_spline ...}
>
>#declare Val1 = Spl(T);
>#declare Val2 = Spl(T, cubic_spline);
>#declare Val3 = Spl(T, quadratic_spline);
>
>I will send you the code soon.


Thanks!

Post a reply to this message

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

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,
		Jérôme
-- 
********************************* Jérôme M. BERGER
* 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

In article <3A0### [at] enstfr>, Jérôme M. Berger 
<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...

		Jérôme
-- 
********************************* Jérôme M. BERGER
* 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

In article <3A0A735E.A48E843C@tapasmail.net>, Jérôme M. Berger 
<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