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

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

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

Btw, current SpecFlare needs 3*2 channels - RGB and RGB of specular 
highlight, in next version it will need another RGB more - for actual light 
sources (that we are looking on directly) and it will result in 3 renders 
per image :|  Ofcourse gathering data for specular / light sources doesn't 
need rediosity, focalblur, arealights and there fore it is quick, but still 
one phase rendering would be better imho.

-- 
#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:51:37 -0400, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> > 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).

SpecFlar does not introduce any of features you proposed while feature you
described in last post takes about 10 minutes for experienced programmer with
some basic rayracing knowledge (implement output to text file from within a
loop over image pixels and recompile). I imagine you are experienced
programmer if you need only 3 hours for writing whole pretty advanced
application :-)

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

Wrong. MinGW is not able to compile raw POV with _WinGUI_. There should be not
problem with compiling console application and MegaPOV is available for almost
8 months with makefile for MinGW.

  http://megapov.inetart.net/download.html

I think that having this link you are able to implement feature you mentioned
for tomorrow? In the meantime can you give me reference to the thread I asked?

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

What's wrong with having it in 2 images with 3 channels each ?

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

Rafal, You will spend more time preparing such demo than implementing text
output within loop for own purposes for yourself. Really! Why you are so lazy
to undestand it? Moreover post processing patch since its begining in old
MegaPOV does exactly what you want.

ABX

Post a reply to this message

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

> Wrong. MinGW is not able to compile raw POV with _WinGUI_. There
> should be not problem with compiling console application 

Hmm I realy like GUI but no problem.
Heres an idea - You will introduce me to recomiling pov[1] if You have time 
to help me by email, and then I will write this patches mentioned above. 
Deal :) ?

btw. it's not so simple, because to add more chanels and special chanels 
like flags - each ray must store all informations (RGB, user*, info).

For each user* there can be filter / transparent (same for info, but info 
would need only binary filter - on/off).

-- 
#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 07:29:29 -0400, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> > Wrong. MinGW is not able to compile raw POV with _WinGUI_. There
> > should be not problem with compiling console application 
>
> Hmm I realy like GUI but no problem.
> Heres an idea - You will introduce me to recomiling pov[1] if You have time 
> to help me by email, and then I will write this patches mentioned above. 
> Deal :) ?

No :-)
I do not agree for email. If there can be some problems there is a chance
somebody in the fututre will have those problems too. Feel free to ask in
povray.unofficial.patches or if necessary in povray.programming and answer to
your question will be available for others. That's how sharing knowledge work
best. Be aware I do not know DevC package.

> btw. it's not so simple, because to add more chanels and special chanels 
> like flags - each ray must store all informations (RGB, user*, info).

It is simple :-) Main intersection test returns pointer to intersected object.

ABX

Post a reply to this message