hua### [at] post3teledk news:3f3fcfc6@news.povray.org

> http://users.skynet.be/bs936509/povfr1/concept1/povfr-gs-pp.htm

(FUT warning)

Interesting, I will try to implement this to SpecFlare[1]. Can POV output 
is 16 bit per channel mode? And maybe - to a text file ?
I was suggesting this path some time ago, along with additional chanels, 
but it was not welcomed AFAIR...

[1] name may change

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

> Can POV output in 16 bit per channel mode?

Yes, the PNG and PPM file formats allow you to specify an output bit depth
from 5 to 16 bits per channel. This is done via the commandline. The docs
will tell you how to do.

> And maybe - to a text file ?

Not to my knowledge, but there's a slow work-around: It's possible to use a
function to evaluate a pixel, and output the info with a loop running over
all the pixels. Beware it's done in SDL and therefore it's slow. It may also
require a two-pass rendering, where you first render the image, and then
start another render that loads the first image and evaluates it... Not so
elegant solution.

By the way, what is a FUT warning?


Regards,
Hugo

Post a reply to this message

hua### [at] post3teledk news:3f3fefd0$1@news.povray.org

>> And maybe - to a text file ?
> Not to my knowledge, but there's a slow work-around: It's possible to
> use a 

I realy must find some time one day to implement it :)

Can anybody here help me to start with Pov re-compiling, using 
GCC+MinGW+DevCPP platform ?


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

On 17 Aug 2003 15:25:52 -0400, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> Can POV output is 16 bit per channel mode?

http://www.povray.org/search/?s=Bits_Per_Color

> And maybe - to a text file ?

+FP

> I was suggesting this path

this become your constant error. patch!

> some time ago, along with additional chanels, 

You mean you proposed additional channels before old MegaPOV introduced
postprocessing ?

> but it was not welcomed AFAIR...

Please reference that thread. I'm pretty sure the reaction was not related to
subject of patch.

ABX

Post a reply to this message

On 17 Aug 2003 17:17:47 -0400, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> Can anybody here help me to start with Pov re-compiling, using 
> GCC+MinGW+DevCPP platform ?

You mean POV-Ray for Windows ? At this moment sources of WinPOV are not ready
for compiling with MinGW. MegaPOV 1.1 should be compilable with MinGW.

ABX

Post a reply to this message

> Yes, the PNG and PPM file formats allow you to specify an output bit depth
> from 5 to 16 bits per channel. This is done via the commandline. The docs
> will tell you how to do.
> 
>>And maybe - to a text file ?

There are two versions of ppm. One is pure text, for the other one just the
header is pure text. povray uses the second one. You can convert that to the
first one with pnmtoplainpnm.


-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

abx### [at] abxartpl news:qur0kvogqji2b51vrdjlb63ako6urrr9eb@4ax.com

>> I was suggesting this path
> this become your constant error. patch!

OK, no need to get angry.

>> some time ago, along with additional chanels, 
> You mean you proposed additional channels before old MegaPOV
> introduced postprocessing ?

Idea is to allow storing of additional informations per pixel in new file 
format. 
Format would be:

V,W,H
Names
Pixel00;Pixel01;Pixel02;...Pixel0W;
...
PixelH0;PixelH1;PixelH2,...PixelHW;

V is format version like 100 W=Width H=Height

Names is list of variables names stored for each pixel i.e.
R,G,B

mean that each pixel has standard RGB information ets.

Suggested informations:

R (G,B) - red channel of output pixel 0 - 255
r (g,b) - -||- as float  0.0 - 1.0
R2 (G2,B2) - -||- as 16 bit 0 - 65536
x,y,z      - position of pixel(*) in scene relative to camera
xa,ya,za   - -||- absolute
nf,nt      - normal of surface in that point defined by 2 angles

(*) pixel - in case of AA, or focal blur - this would be the i.e. first 
sub-pixel used for computing this pixel

user1,user2,user3 - user date, user can use them in code as additional 
pigment or texture data
  pigment { bozo ...  
    info { user1 1.0, user2 2.0 }
  }

flags - user falgs - list of flags that are ON for this pixel 
  pigment { ... 
    flags { backgr, skin }
  }


It would be very usefull for game developers. I will try to create a small 
example why would I suggest thist patch in few days.

And to summ it up example of output image:

100,3,3
R,G,B,user1,flags
0,0,255,0,[backgr] 128,0,0,0,[] 0,0,255,0,[backgr]
200,0,0,1,[skin] 200,50,0,2,[skin eye] 200,0,0,1,[skin]
0,0,255,0,[backgr] 128,0,0,0,[skin] 0,0,255,0,[backgr]

and this image describes a hmm monster with in asciiart could look like

   "
  (*)   (an alien "cyclope" with eye in middle)
   A

and image is ready-to-use in game because it stores data about
- hit points for each area (user1)
- background (flags: backgr)
- monster skin where can it be hit (flags: skin)
- monster eye - from where can it attac by his thunders ;) (flags: eye)



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

spa### [at] raf256com news:Xns### [at] 204213191226

> and this image describes a hmm monster with in asciiart could look like
> 
>    "
>   (*)   (an alien "cyclope" with eye in middle)
>    A
> 

This image would be create by i.e.

global_Settings {
  output_info "R,G,B,user1,flags"
}
background { rgb z info{user1{0} flags{backgr}}  }
sphere { 0 1 scale 1+x pigment { bozo info{user1{1} flags{skin}} } } 
sphere { 0 1 scale 1+y pigment { bozo info{user1{1} flags{skin}} } } 
sphere { 0 1 scale  .7 pigment { bozo info{user1{2} flags{skin eye}} } } 


Another important usage - user1 etc would be perfect for SpecFlare - then 
can pass to it informations i.e. is this point a lightsource (add flare) or 
is it only white material.



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

On 18 Aug 2003 06:01:42 -0400, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> > > I was suggesting this path
> > this become your constant error. patch!
>
> OK, no need to get angry.

I have no idea what suggested you I was angry. I myself made a lot of typos
and grammar mistakes. Probably many in this post :-)

> > > some time ago, along with additional chanels, 
> > You mean you proposed additional channels before old MegaPOV
> > introduced postprocessing ?
>
> Idea is to allow storing of additional informations per pixel in new file 
> format. 

Rafal, I asked for reference. Can you force yourself to refer to the thread
you mentioned ? I would appreciate if you could continue previous discussion
rather than waste time and space for repeating the same things ? I don't want
again and again repeate arguments like:

  Why ? If you can output it with 16 bit per color resolution in format 
  readable for other image manipulation apps why to introduce another file 
  format which only duplicates functionality of other formats ?

And please note, you did not proposed patch. You usually imagine/propose
_feature_ and only promise patches :-)

ABX

Post a reply to this message

abx### [at] abxartpl news:pe91kvsssl0rid9nikg23qupc92hp6arr8@4ax.com


> And please note, you did not proposed patch. You usually imagine/propose
> _feature_ and only promise patches :-)

And my SpecFlar is what, an FPP game ;) ? 
Yes it is as separate program. I wrote in only in 3 hourse (one day 
including test image screation and render).

I use MinGW and if pov 3.5 can't be yet compiled by it - it's a problem for 
me if I want to change pov code.

>   Why ? If you can output it with 16 bit per color resolution in
>   format readable for other image manipulation apps why to introduce

In with format can I store informations about RGB each pixel, is it a light 
source and how bright, is this an hit-point of monster for my game, what is 
normal of this pixel, how far is it from camera. 

It would need about 5 channels.

And yes, this is usefully, if arguemnt about monster in game etc is'nt so 
good for graph artistis, I hope a little demo I'm making would be 
interesting. 

This demo requires RGB + normal FT data, but I will fake it using pov 3.5 
in two renders (one for actual RGB, second to gather FT data).


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