In article <3d8227fa@news.povray.org>,
 "Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:

> Were there plans for a POV 3.1g when POV 3.0 came out?  Or even this
> soon after 3.0 came out?

As I recall, yes. (Not 3.1g specifically, but 3.1)
I don't think POV 4.0 was planned that far back.

An update to POV 3.5 is not out of the question, there will probably be 
at least a few, but they will be minor bug-fix updates like the ones 
from 3.1 to 3.1g. A major release like 3.5 is unlikely.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:5793ou0tv62g00u8qg4tohak4uv89m3plc@4ax.com...
> I have to:
> - write mpeg port
>   http://news.povray.org/povray.animations/26571/
>

Uh, you're working on an IMporter.  Impressive, but not enough to make me
kiss your feet which I was about to when I thought you were making an mpeg
EXporter.

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
3B0### [at] netplexaussieorg

>> > environment mapping certainly isn't
>> > one of them.
>> You realy do not like env-maps, do You ;) ?
> I dislike them strongly, they only make sense for applications where 
> real reflections are impossible. POV doesn't need them.

In same way - "ambient" should be removed because "it make sens only for 
applications where real ambience (radiosity) is impossible".

I agree thet env-maps are needed in few scenes. _but_ they can be created 
while adding more important path - functions based not only on <x,y,z> but 
alsow on normal (i.e. <nx,ny,nz>) of point. How about this idea ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in
news:Xns### [at] 204213191226 

> I agree thet env-maps are needed in few scenes. _but_ they can be
> created while adding more important path - functions based not only on
> <x,y,z> but alsow on normal (i.e. <nx,ny,nz>) of point. How about this
> idea ? 

probalby this will need adding new block to texture, something like

normal_dependent_pigment

because pigment data probably (not cauting transformations and color_map) 
contains :
DBL (pigment_fun*)(DBL x, DBL y, DBL z)
while
DBL (pigment_fun*)(DBL x, DBL y, DBL z, DBL nx, DBL ny, DBL nz

is needed. Before writting a path I will try to simulate such pigment to 
see are results worth efford

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> In same way - "ambient" should be removed because "it make sens only for 
> applications where real ambience (radiosity) is impossible".

Um, no. It is much faster than radiosity, and is very useful combined 
with radiosity (it certainly does make sense with radiosity). An 
environment map would not be much faster than reflection, gives very 
imperfect results, takes more memory...no reason to use it, many reasons 
not to use it, so why add it?


> I agree thet env-maps are needed in few scenes. _but_ they can be created 
> while adding more important path - functions based not only on <x,y,z> but 
> alsow on normal (i.e. <nx,ny,nz>) of point. How about this idea ?

Not a new idea, in fact, a pretty old one. Intersection point, distance, 
normals (raw and perturbed), ray origin and direction...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> probalby this will need adding new block to texture, something like
> 
> normal_dependent_pigment

That is about the worst possible way I can imagine to do it.


> because pigment data probably (not cauting transformations and color_map) 
> contains :
> DBL (pigment_fun*)(DBL x, DBL y, DBL z)
> while
> DBL (pigment_fun*)(DBL x, DBL y, DBL z, DBL nx, DBL ny, DBL nz
> 
> is needed. Before writting a path I will try to simulate such pigment to 
> see are results worth efford

There are already pigments and patterns that depend on the normal, these 
patches just modify the code to make the necessary information 
available. There is no need to modify the syntax for such a thing, and I 
can't imagine why you thought there would be.
And the actual code doesn't even slightly resemble that. Try actually 
looking at the source before deciding how to add something...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

> with radiosity (it certainly does make sense with radiosity). An 
> environment map would not be much faster than reflection, gives very 
> imperfect results, takes more memory...no reason to use it, many
> reasons not to use it, so why add it?

the main purpose why I thinked of that - I'm creating small tutorail, and 
I'm writting like - this is a sphere + normal that can be render in POV, 
3dSMAX 4, etc. And compare it with this isosurface, that would not be so 
easy to create in most scan-lines programs.

I wanted simmilar thing for reflection. This here is a real reflection that 
we can create with POV, and here comes image of _same_ scene but with env-
map... hmmm how can I create env-map in POV ? This is the only 'category' 
in with POV cannot simulate work of 'less complicate' renderers.
 
> Not a new idea, in fact, a pretty old one. Intersection point,
> distance, normals (raw and perturbed), ray origin and direction...

Is some path beeing wrriten currently for that ?


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> I wanted simmilar thing for reflection. This here is a real reflection that 
> we can create with POV, and here comes image of _same_ scene but with env-
> map... hmmm how can I create env-map in POV ? This is the only 'category' 
> in with POV cannot simulate work of 'less complicate' renderers.

A scanline tracer isn't less complicated, just less realistic.
And POV can simulate it, it is just that it only allows one environment 
map per scene (the sky_sphere).


> > Not a new idea, in fact, a pretty old one. Intersection point,
> > distance, normals (raw and perturbed), ray origin and direction...
> 
> Is some path beeing wrriten currently for that ?

I'm working on it, though not very actively, and I'm sure others have 
looked at it...it has been discussed many times on these groups as a way 
to get something close to shader functionality. I think Warp was also 
thinking about it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

> I'm working on it, though not very actively, and I'm sure others have 
> looked at it...it has been discussed many times on these groups as a
> way to get something close to shader functionality. I think Warp was
> also thinking about it.

Interesting, btw. is it possible to assign function to any variable (like. 
i.e. reflection, specular etc) ? This would be realy interesting, like
finish { reflection f_bozo specular f_crackle*0.2 + 0.8 roughness 0.02 }
etc 


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> Interesting, btw. is it possible to assign function to any variable (like. 
> i.e. reflection, specular etc) ? This would be realy interesting, like
> finish { reflection f_bozo specular f_crackle*0.2 + 0.8 roughness 0.02 }
> etc 

There was discussion about this just recently...apparently there is a 
patch called mlpov that allows this. I don't know if it is for the 
MegaPOV functions or the POV 3.5 functions (there have been huge changes 
between the two, Thorsten did a lot of work on them), and it hasn't seen 
much publicity on the English speaking groups (the author is French).

find edges postprocess using functions (one of the more recent threads 
with discussion about giving functions more intersection information)
http://news.povray.org/povray.binaries.images/25848/

Function-Based Shader Macro (mentioning the mlpov patch)
http://news.povray.org/povray.binaries.images/26586/

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message