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

Steve, I'm not a programmer but I am a person who has experimented with
POVs current radiosity system quite extensively. I didn't quite follow
what you were getting at in your message, could you please explain in
greater detail how your system differs from the current system and what
the advantages are, given more information I'm sure you could get a
great deal of support from the POV Ray user community. Specifically:

What is the method that you are planning to implement(Distributed
raytracing, radiance style radiosity, some extension of the photon map,
something else)?

What advantages does your approach offer over other methods?

Thanks in advance,
-- 
Chris Maryan
mailto:cma### [at] geocitiescom
***
Will work for cash.
***
Email me if you are interested in donating
to the Chris Maryan needs money fund.
We will also accept donations to the Chris
needs a Pentium III or SGI workstation 
fund and the Chris needs a car fund.

Post a reply to this message

On Thu, 13 May 1999 22:52:04 -0400, Chris Maryan <cma### [at] geocitiescom>
wrote:
>
>What advantages does your approach offer over other methods?
>

It removes the ambient term totally.  This is the major advantage first and
foremost.  POVs radiosity still relies on that  ambient term even in its
radiosity calcs.  Try turning your ambient levels to 0.0 on all your surfaces.
Set two renders side by side, one with radiosity and the other without.   They
will look exactly the same.  There is a reason for this.  To get good
"radiosity effects" you have to have your ambient up around 0.2 and higher.
See why this is bad?      In order to get diffuse illumination in POV you must
add fake diffuse illumination first (the ambient term).   This is redundant.
Radiosity should figure this out on its own.  (I have this "funny" idea that's
what radiosity was for in the first place!   But no.... POV seems to be
fishing towards some sort of simulation of color bleeding, and not much else.
I can assure you that diffuse illumination, or global illumination is
potentially much more complicated than a simulation of color bleeding.)

1.  It's potentially slower than the current POV radiosity.   Also potentially
much, much faster.
2.  Unlike POV, it is essentially noiseless.  POVs radiosity suffers from
terrible artifacts, that only dissappear by smoothing out the results.   But
then you have smoothed out and fuzzy-looking results.   Mine is noiseless and
in sort of super-focus.
3.  POV can't really pull off a recursion level past level 1.  This one can do
as many as you like if you have the patience.
4.  Without a really obvious example scene, I can tell you that anything
clearly visible in a reflection in a POV scene des not have radiosity
calculated on it.   I'm sure this is a simple fix (maybe).  But nonetheless.
5.  This is not "regular radiosity" meaning this is NOT that form-factor
method where you subdivide all the surfaces into triangles.  For this reason,
any surface tracable with rays can be used in a scene with this new method
without a hitch.  i.e. this method is a _sampling method_ and not a quantizing
or deterministic method.  Just like POV.
6.  This method is not confused by a dozen or so tweaking parameters that are
obscure in meaning.
7.   I question whether or not this method uses more memory or not.  I have
had POV crash and run out of memory on mosaic passes when I told it to do a
radiosity sample on every single point.  My roomate noted that my HD was going
nuts all night long.    It may be the case that this method is more elegant
memory wise.  I hope to have all of its databases in quiet physical RAM the
whole time.    This is possible, the databases will run approx 8 megs  and
never more than 20.

Any other questions?

---------------------
Steve H.

Post a reply to this message

On Fri, 14 May 1999 00:58:52 GMT, hor### [at] osuedu (Steve )
wrote:

>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 is a tough one.  I don't think Windows makes this number readily
available.  You can get the total available memory including virtual,
but that won't do you much good.  On NT, you can get physical RAM
information from the process statistics helper DLL, but I don't know
of an equivalent on 9x.

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

I'm not sure what you're looking for, exactly.  You'll find the
trace_pixel function in render.c, but it's probably too high-level for
what you're trying to do, so you might need to follow it down a couple
of steps.  Starting this way you'll also get an idea what preparatory
steps have to be done before tracing the rays.

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 is a tough one.  I don't think Windows makes this number readily
>available.  You can get the total available memory including virtual,
>but that won't do you much good.  On NT, you can get physical RAM
>information from the process statistics helper DLL, but I don't know
>of an equivalent on 9x.
>


Try GlobalMemoryStatus.

Philippe

Post a reply to this message