Changeset 507 for trunk/VUT/GtpVisibilityPreprocessor/src/GlRenderer.cpp

Timestamp:

01/07/06 10:50:29 (19 years ago)

Author:

bittner

Message:

Preparation for hw based sampling

File:

• trunk/VUT/GtpVisibilityPreprocessor/src/GlRenderer.cpp (modified) (2 diffs)

trunk/VUT/GtpVisibilityPreprocessor/src/GlRenderer.cpp

@@ -5 +5 @@
 #include "Pvs.h"
 #include "Viewcell.h"
+#include "Beam.cpp"
 
 #include <GL/glext.h>
@@ -529 +530 @@
   
 }
+
+
+void
+GlRendererBuffer::SampleBeamContributions(
+                                                                                  Intersectable *sourceObject,
+                                                                                  Beam &beam,
+                                                                                  const int desiredSamples,
+                                                                                  BeamSampleStatistics &stat
+                                                                                  )
+{
+  // assumes that the beam is constructed and contains kd-tree nodes
+  // and viewcells which it intersects
+
+
+  
+  
+  // Get the number of viewpoints to be sampled
+  // Now it is a sqrt but in general a wiser decision could be made.
+  // The less viewpoints the better for rendering performance, since less passes
+  // over the beam is needed.
+  // The viewpoints could actually be generated outside of the bounding box which
+  // would distribute the 'efective viewpoints' of the object surface and thus
+  // with a few viewpoints better sample the vipoint space....
+  
+  int viewPointSamples = sqrt((float)desiredSamples);
+
+  // the number of direction samples per pass is given by the number of viewpoints
+  int directionalSamples = desiredSamples/viewPointSamples;
+  int i;
+  for (i=0; i < viewPointSamples; i++) {
+        Vector3 viewPoint = beam.mBox.GetRandomPoint();
+        // perhaps the viewpoint should be shifted back a little bit so that it always lies
+        // inside the source object
+        // 'ideally' the viewpoints would be distributed on the soureObject surface, but this
+        // would require more complicated sampling (perhaps hierarchical rejection sampling of
+        // the object surface is an option here - only the mesh faces which are inside the box
+        // are considered as candidates) 
+        SampleViewpointContributions(
+                                                                  sourceObject,
+                                                                  beam,
+                                                                  directionalSamples,
+                                                                  stat
+                                                                  );
+  }
+
+
+  // note:
+  // this routine would be called only if the number of desired samples is sufficiently
+  // large - for other rss tree cells the cpu based sampling is perhaps more efficient
+  // distributing the work between cpu and gpu would also allow us to place more sophisticated
+  // sample distributions (silhouette ones) using the cpu and the jittered once on the GPU
+  // in order that thios scheme is working well the gpu render buffer should run in a separate
+  // thread than the cpu sampler, which would not be such a big problem....
+}
+
+
+void
+GlRendererBuffer::SampleViewpointContributions(
+                                                                                           Intersectable *sourceObject,
+                                                                                           Beam &beam,
+                                                                                           const int desiredSamples,
+                                                                                           BeamSampleStatistics &stat
+                                                                                           )
+{
+  // 1. setup the view port to match the desired samples
+  // 2. setup the projection matrix and view matrix to match the viewpoint + beam.mDirBox
+  
+  // 3. reset z-buffer to 0 and render the source object for the beam using
+  //    glDepthFunc(GL_GREATER)
+  //    and glCullFace(Enabled) and glFrontFace(GL_CW)
+  //    remember the ray origin depth buffer somewhere?
+
+  // 4. set back to normal rendering and clear the ray termination depth buffer
+  // 5. render all objects inside the beam using id based false color
+  //    (objects can be compiled to a gl list now so that subsequent rendering for
+  //     this beam is fast - the same hold for step 3)
+
+
+  // 6. Now we have a two depth buffers defining the ray origin and termination
+  //    only rays which have non-zero entry in the origin buffer are valid since
+  //    they realy start on the object surface (this can also be tagged by setting a
+  //    stencil buffer bit at step 3)
+
+  // 7. Use occlusion queries for all viewcell meshes associated with the beam ->
+  // a fragment passes if the corresponding stencil fragment is set and its depth is
+  // between origin and termination buffer
+
+  // 8. The number of visible pixels is the number of sample rays which see the source
+  //    object from the corresponding viewcell -> rember these values for later update
+  //   of the viewcell pvs - or update immediatelly?
+
+  //  In general it is not neccessary to rember to extract all the rays cast. I hope it
+  // would be sufficient to gain only the intergral statistics about the new contributions
+  // and so the rss tree would actually store no new rays (only the initial ones)
+  // the subdivision of the tree would only be driven by the statistics (the glrender could
+  // evaluate the contribution entropy for example)
+  // However might be an option to extract/store only those the rays which made a contribution
+  // (new viewcell has been discovered) or relative contribution greater than a threashold...
+       
+  
+}