Hello again,  I haven't been here for awhile but I thought I would stop by to
make this anouncement.

I'm wanting to add a revolutionary  "radiosity" feature to POV.   If you've
been here for awhile you may already have heard from me about contributing
networks and such.    Lately it seems I have worked out all the conceptual
problems with my approach.   I have also discovered a way to weigh a
5-dimensional tree in exactly such a way that I needed.  Turns out this
weighing procedure was also exactly what I needed to create a smaller
"representative tree."  Math is funny like that...

But anyways, I'll need the help of anyone willing from this group or any of
the developers in navigating the code.   I have a small handful of very
specific questions.   I won't bore you with compiler portability issues, I
know how to program and I have Borland 5.0 so that shouldn't be a problem.
If need be, I could distribute a nice, pretty postscript file to all
interested so you can follow exactly what I'm trying to do.  

I'm wanting to create a WIN95 compile first, (since I want to test it on my
own computer :p )  but I'm clueless when it comes to creating one of those
petite, little self-extracting patchers.     On this I will need help.

Okay, the first thing I want to work on is adding the extra functionality to
the parser and the command line.  I'll try to stick as close to the existing
words as possible.   I'll keep the +/-Q option to turn the process on or off.
All I need are these radiosity{ } options:  Notice some are changed in meaning
to suit this new algorithm

brightness  { Tweak brightness of diffuse illumination.  1.0=no change
<1.0 dimming   >1.0 brightning  }

count      {  The number of final light sources used during the final tracing
pass.   1 could be interesting.   Something like 50 is probably maximum.  255
is the theoretical maximum for 24-bit color. }

gre/ay_factor { Same as always  0.0 by default!  }

recursion_limit {  Very touchy.   1 by default.   Since this method searches
for "absolute levels" instead of just blindly proceeding, the scene file
should be considered before turning this up.  If the scene does not need level
4 recursion, then this parameter should not be set that high!  Otherwise the
method will pre-process all night performing worthless calculations.   If, on
the other hand, the scene is a maze of mirrors, by all means, turn this
setting up. (more on "absolute levels" later)  As I have said before, this 
algorithm actually performs infinite recursion, but in a local sense.  This
parameter makes it "less local" }  

region <#,#,#>, <#,#,#> {  A bounding box where diffuse illumination takes
place.  This should bound the visible scene as tightly as possible.   Though
the visible scene should not be end-all to this bound.  Note: no diffuse
illumination will be calculated during the final render on points outside this
region.   Note: no diffuse illumination will emmenate from anywhere but inside
this region.  }

All the other old parameters will be ignored.

My first questions involve how to get the current running amount of free
memory from Win95.   I want a count of physical RAM, not all the free space on
the HD.  This method should have its data stored exculsively in RAM, due to
the massive the searching and sorting.   If someone thinks they can have a
scene rendered in the background with this radiosity while playing Quake2 with
several Netscape windows open, they should get a warning that there isn't
enough RAM available and that radiosity has been turned off.    

To begin pre-processing I'm wanting to trace a smaller resolution of the
scene; 300x300 maybe.  I want to keep track of all the points that are found
in intersections.  BUt I want to store only those points that contribute most
to a visible color change in the pixel.  At most, the best two points.  In
most cases, the best only.  I want these points only in order to avoid the
little trick where the camera is aimed into a mirror to see a reflection of
the "real scene."  Also, points that are not in the "region" should be
ignored.   If a pixel remains empty after the first pass, the number of empty
pixels should be matched by a same number of traces into pixels that will
"most probably" intersect something in the "region."     If we are having
trouble with empty pixels, this repetitive miss-and-replace algorithm should
terminate after so many steps.

This first stage of the pre-processing is building a database called the
"visible point set."   It reads 'VPS'  in my notes. 

So where in the code should I look first for these things?  

Thanks,
---------------------------------------------------------
Steve H.

Post a reply to this message

>My first questions involve how to get the current running amount of free
>memory from Win95.   I want a count of physical RAM, not all the free space
on
>the HD.  This method should have its data stored exculsively in RAM, due to
>the massive the searching and sorting.   If someone thinks they can have a
>scene rendered in the background with this radiosity while playing Quake2
with
>several Netscape windows open, they should get a warning that there isn't
>enough RAM available and that radiosity has been turned off.



Try : GlobalMemoryStatus

Post a reply to this message