Hello,
what steps should I do to create own text output format ?
output file will be like :

width height
line1
line2
line3

where lineN is :
pixel1 ; pixel2 ; pixelN

where pixel is :

r,g,b,x,y,z,normal_fi,normal_theta,distance,alpha,id,cpu_time

so I want to access all above informations (id-see next post, cpu_time - 
cpu utilization histogram, assuming that histogram is same size as output)


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

> Hello,
> what steps should I do to create own text output format ?
> output file will be like :
> 
> width height
> line1
> line2
> line3
> 
> where lineN is :
> pixel1 ; pixel2 ; pixelN
> 
> where pixel is :
> 
> r,g,b,x,y,z,normal_fi,normal_theta,distance,alpha,id,cpu_time


The problem might be to collect the information when it is available.

The traditional file writing code is usually given a line of pixel at a 
time. Here, pixel being "traditional" pixel (rgba), not your pixel.
To collect your information, you will have to patch (heavily) the 
rendering engine
so that not only it compute the color of the pixel, but also saves the 
ray intersection... x,y,z: Evaluate_Ray(...),
Normal : You could have the classical 3 components vectors from the 
intersection of the ray (IF there is an intersection, background does 
not count), up to you to transform the vector,
distance is obviously the depth of the ray/intersection,
alpha is already part of the colour,
id : as long as you extend the object fields, the intersection will 
provide you with the object pointer, the remaining is easy.
cpu_time : look at the histogramme code, calling the right function 
before and after tracing each ray.

You have ONE BIG PROBLEM: Antialiasing!
You won't be able to perform it (what do you store if half the pixel is 
from a sphere and the other half is a box or the background).

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote in news:3D6### [at] freefr

> The problem might be to collect the information when it is available.

> The traditional file writing code is usually given a line of pixel at a 
> time. Here, pixel being "traditional" pixel (rgba), not your pixel.
> To collect your information, you will have to patch (heavily) the 
> rendering engine

It realy looks not so easy, maybe I should start with basic r,g,b text 
format. 
With file/line is responsible for 
- setting i.e. 'txt' and 'T' as output format
- creating output file
- adding pixel to buffer
- writing buffer/line to file
- closing it

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

Posting under my real name for once, I will revert to "Le Forgeron" right after.
(it's the week-end!)

Rafal 'Raf256' Maj wrote:
> 
> Le Forgeron <jgr### [at] freefr> wrote in news:3D6### [at] freefr
> 
> > The problem might be to collect the information when it is available.
> 
> > The traditional file writing code is usually given a line of pixel at a
> > time. Here, pixel being "traditional" pixel (rgba), not your pixel.
> > To collect your information, you will have to patch (heavily) the
> > rendering engine
> 
> It realy looks not so easy, maybe I should start with basic r,g,b text
> format.
> With file/line is responsible for
> - setting i.e. 'txt' and 'T' as output format

+FT is already used for Uncompressed Targa 24bits
What about +FA instead (A: Ascii ?)

> - creating output file
> - adding pixel to buffer
You do not have to update that code, unless you want more than RGBA in the buffer.
The file interface has only the knowledge of the concept of line.

Look in png_pov.* or targa.* for an example of the functions needed
(one open, one write a line, one read a line, one read full image, one close)
The buffer is there to delay the writing of x lines on the disk, instead
of making a disk access (or rather asking the system to do it) per lines.
Most useful when rendering small width, far less I/O, this keep the CPU working
on the useful things!)

> - writing buffer/line to file
> - closing it

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message