Log	PowerBook Configuration Log xw9300 Opteron Configuration Log

2005 Page 1   Page 2

• Sat Jul 2 09:34:12 EDT 2005

  Created many figures for chapter 5.

  
  Rendered large 2048x2048 comparison of skull with and without global illumination.

  
  Fixed environment map photon emission. Added small light to boat scene to create caustic.

  
  Wrote script to render a series of images substituting random samples from a normal distribution as a parameter in the scene description. In this case the parameter is the height of the floor. Images show the resulting caustic as the floor moves up to the bottom of the boat.

• Fri Jul 1 20:11:49 EDT 2005 Reading this page, I realized that it's only necessary to know the ratio of the indices of refraction for two surfaces. The significance is that it's not necessary to store both indices in the model, although that may be simpler. The point is mute since I still do not have per-object indices of refraction. While not an important revelation, at least I think I know how to render Jensen's cognac glass.

• Thu Jun 9 04:35:11 EDT 2005

  Fixed cubic solving problem. It was four things: Had unnecessary IsZero() test in quadratic case. MYEQN_EPS is better at something large, like 1e-8. Was missing a fabs() in while() condition (oops!). Was not checking that final root estimate plugged into the cubic produced a near-zero result. (Sometimes the Newton-Raphson iterations would end on something far from correct but within the voxel, producing a false intersection)

  "Fixed" direct lighting weighting + sampling. In truth I didn't or have to do anything. Apparently I fixed it yesterday? Something is odd. I think I found the problem with the powerlifter scene: ambientresolution.

  Intel vtune is now running. Need to investigate further.

  Want to compare icc to gcc. This requires fixing direct lighting vla, which may require using hoard. Benchmark hoard. Also try g++ options Marcus gave me.

• Tue Jun 7 17:00:58 EDT 2005

  
  

• Mon Jun 6 01:23:37 EDT 2005

  Learned about cycle counting. This can be done by including asm/msr.h and using rdtscl(); This is fabulous. Here are some brief tests.

  Op	Cycles
  1008ms	3081521324 (about 3.0GHz)
  10 adds	4 (aout 1 cpi)
  10 muls	100 (about 10 cpi)
  10 divs	584 (about 58 cpi)
  100 sqrts	4344 (about 43 cpi)

  Optimizations

  x * 1.0/C is faster than x/C where C is a constant.
  V * 1.0/x is faster than V/x where V is a vector of length>1.
  There is a fast inverse square root in Graphics Gem I .
  According to Wald/Slusallek, ray-tracing is a memory-limited application (that is memory is slow, and RT requires random access to memory).

  Notes

  There are contants for 1/pi and more in math.h.
  g++ -MM source.cxx generates dependencies for a source file.

  Ray tracing

  pane was exhibiting "scalloping" (as described by Greg Ward in Radiance) in the direct lighting contribution for lights adjacent to the point of computation. Additionally, two lights above a sphere produced noise as the weights for each light changed in the multi-luminaire sampling. (This is using Wang's and Shirley's direct lighting computation with a probablity mass sampler to choose the weight (computed as Phi*cos(O)*cos(O')/r^2) and a triangle at unit distance length to approximate sampling according to solid angle.

  The first fix was to use true spherical triangle sampling (Arvo) to sample according to the actual solid angle of the luminaire. This gets rid of the scalloping but doesnt eliminate the error in choosing a triangle.

  It's worth noting that there is a way to sample with a probability density proportional to the projected solid angle, which is the best for variance reduction as it matches the integrand most closely without knowing anything about the brdf or visibility (Urena). However, this looks difficult to implement and costly to perform, so I do not adopt this approach.

  As for the weighting problem (choosing the weights with which to choose a particular triangle) I ran into several problems. It is not good enough to weight the triangle according to its solid angle, even if computed with Arvo's expensive solid angle computation, unless you clip the triangles against the horizon. I didn't try it, because that would be really slow.

  I found something called the Nusselt analogy, which says the projected area of a spherical triangle is proportional to the projected solid angle. Projecting a triangle on the unit sphere down will not work, even if clipped to the horizon, because the triangle's projection will not be the same as the spherical solid angle's projection.

  
  A triangle across the horizon should be clipped for weighting (and for sampling, but I dont do this)

  Luckily, thanks to (Urena), I found another paper by (Buam) that gives an analytical formula for computing the projected solid angle of a polygon by using Stoke's theorem to turn it into a contour (edge) integral. By clipping triangles to the horizon (I do it in two conditionals per triangle side), I can compute the exact projected solid angle of the clipped triangle and multiply by the power to use as the weight. This gives very good results with relatively minor speed decrease (compared to the benefits in quality and in limited testing).

• Sun May 22 16:57:20 EDT 2005

  Brain (120 isos)
  With:  132s, 1.10614 s/iso
  Without:  128s, 1.07408 s/iso
  
  Nucleon (120 isos)
  With: 257s, 2.14253 s/iso
  W/o: 220s, 1.8382 s/iso
  

  Brain data set, 120 isovalues evenly spaced in range:
  
  Just isosurface with normals:
  Total (wall) time: 103372ms, 103s, 0.861433 s/iso
  
  With just texture:
  Total (wall) time: 127035ms, 127s, 1.05862 s/iso (delta = +0.197187 s/iso)
  
  With texture, walls, 2-pass reflectance
  Total (wall) time: 134663ms, 134s, 1.12219 s/iso (delta = +0.06357 s/iso)
  

• Wed May 18 20:35:56 EDT 2005

  Computed display times needed for isosurface texturing.

  Brain    
  Total (wall) time: 30902ms, 30s, 1.5451 s/iso
  Total (wall) time: 17173ms, 17s, 0.85865 s/iso (w/o)
  ~/iso/gillum-0.5/src/modSurface -f ~/c/josh_gi/colin_brain2.mri -d 109 -r
  frost3/blurred.br -x -c -m -l glass/ -y 0.75 -i 0 -S 20
  
  Nucleon
  Total (wall) time: 39096ms, 39s, 1.9548 s/iso
  Total (wall) time: 22644ms, 22s, 1.1322 s/iso  (w/o)
  ~/iso/gillum-0.5/src/modSurface -f pasta1.out -r blurred2.br -d 101 -x -c -m
  -i 115 -2 pasta2.out -n blurred1.br -l . -3 0.8 -i 0 -S 20
  ~/iso/gillum-0.5/src/modSurface.trans -f pasta1.out -d 101 -x -i 115 -2
  pasta2.out -3 0.8 -i 0 -S 20
  
  Nueron
  Total (wall) time: 12306ms, 12s, 0.6153 s/iso 
  Total (wall) time: 7210ms, 7s, 0.3605 s/iso   (both with this default view)
   ~/iso/gillum-0.5/src/modSurface -f ../neuron.dat -d 150 -x -c -m -i 50 -r
  subsurface/blurred.br -4 -l subsurface/ -S 20 (required failsafe mode login
  for more memory)
  
  LAPR
  Total (wall) time: 27858ms, 27s, 1.3929 s/iso
  Total (wall) time: 14465ms, 14s, 0.72325 s/iso (w/o)
  ~/iso/gillum-0.5/src/modSurface -f convolve.050-1.out -2 convolve.050-2.out
  -d 120 -x -c -m -r approxmix_050.br -n approxmix_0502.br -p 0.25 -i 112 -l
  water_trans/ -S 20 
  ~/iso/gillum-0.5/src/modSurface.trans -f convolve.050-1.out -2
  convolve.050-2.out -d 120 -x -p 0.25 -i 112 -S 20 -3 0
  
  
  Ray tracing times for all isosurfaces
  
  Brain: 73724+10802 s
  Neuron: 34733 s
  LAPR: 7850 s
  Nucleon: 8162 s
  

• Thu May 12 14:42:54 EDT 2005

  
  Vicinity Shading vs. Global illumination

  
  Vicinity Shading for different shadow ray lengths

  Problem fixed. Was editing wrong part of source code.

• Wed May 11 13:33:19 EDT 2005

  
  This is a rendered isosurface with just direct lighting that is meant to represent vicinity shading. There is no shadow ray length threshold as values as low as 5% made no visible difference. Presently I'm rendering isosurfaces with even smaller thresholds to see if it makes a difference (it should).

• Mon May 23 11:25:27 EDT 2005

  Mesopic and Scotopic glare simulation (lenticular halo)

• Mon May 22 11:25:27 EDT 2005

  New direct light sampling according to actual solid angle instead of approximation (fixes noise near lights)

• Mon May 15 11:25:27 EDT 2005

  Attempted to convert Octree traversal into iterative algorithm, slow

• Thu May 5 08:36:51 EDT 2005

  Octree-R for Teapot in a Stadium problem

• Wed May 4 08:36:51 EDT 2005

  Photopic glare simulation (ciliary corona)

• Sat Apr 30 19:41:43 EDT 2005

  I really like OS X. And I really like my new PowerBook. They are great. They are so great it's not fair that the first thing I should write about them is a gripe, but here it is.

  The Keyboard is pretty and nice. It glows, that's awesome. It's easy to type on. But why is the Fn key in the bottom left instead of Ctrl? That makes ctrl harder to use. Also, why do Macs have one mouse button for simplicity, which really sucks by itself, yet to go with this "simplicity" they put a Fn, ctrl, alt, option, open apple, AND a command key to the left of the spacebar. What in the world...? This isn't simple! This is a mess. (The alt and option key are the same, and the open apple and command key are the same.) It should just be Ctrl, Alt, Fn, Command. Basically Macs have an extra modifier key and one less mouse button.

• Tue Apr 12 16:51:00 EDT 2005

  
  
  

  Vicinity Shading vs. Global Illumination (same lighting) vs. Global Illumination (frosty glass setting)

• Mon Apr 4 18:00:32 EDT 2005

  
  Left: Pirate: "Arrrr!" Right: Me: "Arrr, floating point precision problem!"

  I had to rework the model rendering in pane to do both a) per-vertex rendering and b) use individual triangle properties.

  In the process I impemented vertex normal generation, which I had to debug, and multi-threading support. I implemented the normal generation because I thought I needed it but now I don't think I do (not positive on this.. too tired to think right now).

  I found a bug in the triangle shadow ray generation, where the rays miss the light because of random samples extremely close to zero, and a mesh artifact where a middle vertex is beneath an adjacent side, as shown above.

  Long story short: pane can render iv files per-vertex, with multi-threading, using the triangle material properties, including support for transparency (new), and can generate normals for a model at runtime (new). The normal generation is more robust than Hui's ivComputeNormal tool I've been using.

  I'm rendering frosted skulls right now.

• Sat Apr 2 16:38:03 EST 2005

  Brad's hierarchical isosurfacer

  Dataset	Isovalues	Time w/o texture	Time w/texture	difference	difference/isosurface
  Brain (Glass, 217^3)	40	38s	46s	8s	0.2s
  Neuron (150^3)	60	22s	37s	15s	0.25s
  Nucleon (101^3)	60	108s	127s	19s	0.31s

  Josh's isosurfacer

  Dataset	Isovalues	Time w/o texture	Time w/texture	difference	difference/isosurface
  Brain (217^3)	20	56s	67s	11s	0.55s
  Neuron (150^3)	40	30s	32s	2s	0.05s

• Wed Mar 30 09:03:03 EST 2005

  
  Vicinity shading, Global illumnation (texture based volume renders)

  Changing epsilon from 1e-15 to 1e-8 fixed the issue for this dataset. Suitable values for epsilon seem to be resolution dependent. These images look much better without the noise. Also, they display the underlying texture more precisely than the marching cubes isosurface. Marching cubes blends the vertex colors across triangles. These images sample the texture directly (with trilinear filtering) and have pixel perfect accuracy. I can now see the textures better. I'll make new images for all the textures and generate some new textures with different filtering.

  I've been generating scenes to compare my global illumination using the uniform lighting of vicinity shading, but the renders are taking forever and some of them are crashing with "generic error", "illegal instruction", and "segmentation fault" :(. I think some diagnostic code I inserted monday is causing the last problem. They are probably running slower because of more lightsamples to integrate the large sphere.

  update: I've reverted to an older version of pane and restarted the renders.

  
  Vicinity shading, global illumination, and debugging image using a texture based volume renderer.

  I implemented volume ray tracing to see if ray tracing the volume data directly would alleviate some of the aliasing. No triangulation or marching cubes is peformed. As a result I have discovered that I *still* have numerical issues in my isosurface intersection cubic solver.

  If I bypass the solver and just intersect the voxel in the center, I get the last image. This image shows that the code is at least traversing the voxels.

• Sat Mar 26 18:06:07 EST 2005

  

• Thu Mar 24 08:29:06 EST 2005

  
  I'm still working on it but this is the best so far.

• Wed Mar 23 18:04:17 EST 2005

  I was having some precision problems with my intersection code. If the cubic solver was too precise, this would happen:

  #define     MYEQN_EPS   1.e-30
  ./pane --3ddata=$HOME/iso/blobby100.dat.sf --3ddim=100 -4 --showphotons --windowbg=0,0,0 --tempfloat=9.06
  

  

  If it was too imprecise, this would happen:

  #define     MYEQN_EPS   1.e-8
  ./pane --3ddata=../test1x1x1.dat.sf --3ddim=2 -4 --showphotons --windowbg=0,0,0 --tempfloat=0.5
  

  

  The problem with my intersection code was solved by using a happy medium:

  #define     MYEQN_EPS   1.e-15
  

  

• Thu Mar 17 06:38:39 EST 2005

  
  (Left: My vicinity shading. Right: Interpolated rendered isosurfaces) There is a problem with our technique on the skull dataset. The .br file produces the lines seen on the image on the right. I've tried all sorts of filtering (including creating a texture at the highest resolution possible on photon) and nothing helps. Isosurface colors are leaking through.

  I've reworked my isosurface rendering to (hopefully) produce better vertex color samples, by sampling at the vertices directly instead of along faces and then averaging at the vertices. Hopefully this will produce cleaner results and alleviate the problem. I have hope that there is a solution because other techniques produce a valid texture, e.g. vicinity shading.

  Tomorrow I should have timings for the isosurface generation with and without texuring.

  After that I'll try to make a povray rendering of a scene.

• Tue Mar 8 02:21:02 EST 2005
  • Submitted Chapter 3 to Chris.
  • Fixed bug in pane model rendering
  • Rendered brain isosurfaces in split, two colored, horizon aligned, environment map.
  • Tomorrow:
  • Post pics of brain
  • Think of better global illumination scene for brain
  • Fix bug in intersection code
  • Apply for jobs

• Fri Mar 4 14:41:01 EST 2005

  
  Vicinity shading, GI with spherical light, GI with cornell box.

  
  First row: Vicinity shading, GI with spherical light, GI with cornell box.
  Second row: Last two images of first row minus headlight.

  Vicinity shading Stewart's "Vicinity shading" \cite{stewart:2003} assumes a uniform diffuse light surrounding the volume and calculates isosurface occlusions in a small region near each voxel. Like the authors, he stores the lighting in a 3D texure. During display, isosurfaces are texture mapped and viewed with a specular headlight for a combination of view-independant and view-dependent lighting. This produces soft self-shadows, which is a partial global illumination solution, but it is not a full solution as it does not account for color bleeding (indirect illumination), caustics, or non-uniform-spherical illuminaires. (Though his algorithm is O(n^2) while ours is O(n^3))

  Apple order status:

  2 laptops	X
  2 ipod shuffles	X
  2 ipod 20gb	X
  2 isight	X
  incase laptop sleeve	X
  timbuk2 bag	X
  iKlear	X
  midi keyboard	X
  2 screensavrz	X
  2 display cushions	X
  ipod case	X
  2 office2004	X
  2 virtualPC	X
  2 adobe CS	X
  framemaker
  2 ethernet cables
  cheap mousepad	X
  2 gb ram	X
  2 gb ram	X
  2 mice	X
  router	X
  cd-r's	X

• Thu Feb 24 15:32:42 EST 2005
  • I'm trying to fix Stanford's happy buddha model for rendering. Presently the problems are that some normals are not being computed because of some triangles being nearly infinitely thin. I'm attempting to decimate the mesh to hopefully remove these thin, bogus triangles. So far, I've tried qslim and rsimp. qslim doesn't remove all the thin triangles, and rsimp crashes.

• Wed Feb 23 13:21:33 EST 2005
  • Sent Apple laptop purchase request to Michele. Should add two iPod sleeves and an external data storage device for backup purposes.
  • Tested skippy, an X11 task switcher similar to Apple's Expose. It's decent.
  • Downloaded VTune for linux, a visual profiler. Have not tried out yet.
  • Converted TCVG paper submission to TCVG format, printed it out and gave to Dr. Banks.

• Thu Feb 10 19:43:51 EST 2005 Still trying to debug this:
  
  It's a photon map and should in this case be uniform, however there are holes.

• Thu Feb 10 04:19:15 EST 2005
  • Got some programs to work on bubba:

    Performer
    cd /usr/share/Performer/data/
    perfly -c 1 town.perfly
    
    Volumizer
    /usr/demos/Volumizer2/bin/volview
    Load -> data/medical/Phantom/Bone...tif
    

  • Benchmarking futch's convolution code right now. I notice however that it performs worse with multiple threads. I suspect the cause is rapid mutex contentions -- the threads are fighting to lock a mutex. Buffering should be employed to easy the lock rate.
  • Fixed precision error in pane/4D isosurfact intersection, but found another bug where certain gridcells are missing.
  • Tried to fix a bug in gaim.
  • Am reading one of Jensen's subsurface scattering papers after having read the chapter in his book on the same subject (and participating media).
  • Added link to README on Pane page.
  • Purchasing ideas: CD-R's, mice, RAM...

• Wed Feb 9 06:18:06 EST 2005
  • Still debugging dome light source. Found precision error in trilinear isosurface intersection.
  • Got brad's code to run on bubba -- need to run benchmarks.
  • Submitted Chapter 1 to Chris.
  • Looked at firefox extension development.
  • Discovered ddd -- a graphical front end to gdb.

• Tue Feb 1 20:48:53 EST 2005 New renders of morph between f_local and f_global

  
  
  SGI Prism benchmarks
  8 1.5Ghz Intel Itanium 2 processors
  8 Gigabytes RAM (shared)
  

  Pane benchmarks

  
  Command used:

  pane -u40 water2.iv --rindex=1.33 -s16 --photons=400000 --estimate=100 --cphotons=10000000 -d1024x768 -r --gatherrays=500 --octreedepth=10 --octreeitems=5 --cestimate=150 -j$NUMBER_OF_THREADS

  
  
  L_invisible for f_local, f_shadowless, f_oneBounce, f_global

  
  
  

• Tue Jan 25 17:34:04 EST 2005

  retroRendering flocal	OpenGL 5 spotlights	OpenGL 1 spotlight	5 spotlights, 1 spotlight error
  flocal, 5 spotlights difference	flocal, 5 spotlights error	flocal, 1 spotlight error

  MSE = ( (r₁-r₂)² + (g₁-g₂)² + (b₁-b₂)² ) / 3
  RMSE = sqrt(MSE)
  MRMSE = average RMSE for all pixels

  MRMSE = Mean Root Mean Square Error
  MRMSE(f_local, 5 spotlights) = 0.00830938 = 0.830938%
  MRMSE(f_local, 1 spotlight) = 0.00847661 = 0.847661%
  MRMSE(5 spotlights, 1 spotlight) = 0.00163915 = 0.163915%

• Tue Jan 25 04:00:11 EST 2005

  OpenGL	Pane	Difference
  Error	Error0.35	Error/max(Error)

  On the top left is an image rendered using OpenGL and five spotlights. The top middle shows an image using a Monte Carlo Path Tracer with retro-rendering and a f_local. The top right image shows their difference. It's almost completely black, with some speckles resulting from insufficient samples.

  The error images on the bottom row map error for each pixel to hue. Blue means no error, red means higher error. When I say "error", I mean the Mean Square Error for the pixel:

  MSE = ( (r₁-r₂)² + (g₁-g₂)² + (b₁-b₂)² ) / 3

  For example, the Mean Square Error between a white pixel (1,1,1), and a black pixel (0,0,0), is ( (1-0)² + (1-0)² + (1-0)² ) / 3 = (1+1+1)/3 = 1.

  I also calculated the Root Mean Mean Square Error (RMMSE) for the entire image:

  RMMSE = sqrt(mean(MSE)) = 0.0126247 = 1.26%

  I need to adjust the error images so that red means maximum error. Also I need to analyze a single spotlight image for comparison.

• Sun Jan 23 15:07:06 EST 2005

  

• Fri Jan 21 06:12:51 EST 2005
  • Two images finished rendering (finally):

    
    

  • Installed latest inventor on bubba, the new prism demo machine from SGI. The machine is the same as the altix we had awhile ago but has four graphics pipes (ATI R350 = 9800 ?).

    The install was done in part because it couldn't load a large scene file. This turns out to be because of an NFS issue (file corruption) with rivera. Home directories appear to not have the problem.

  • Benchmarked bubba: it's about a third as fast as photon in rotating a large triangle mesh. Meh. I will do rendering tests soon but I expect it will be the same as the last altix as both machines have eight Itanium2's at 1500 MHz.
  • I matched a pane rendering w.r.t. to brightness to an inventor scene using a point light.

    
    I am in the process of doing the same matching for a spotlight scene in inventor with a small area light in pane. I had some success with a single spotlight approximation as you can see here:

    [imgs missing]

    I'm trying to use a rectilinear array of 25 spotlights but I don't think inventor is using them all, even though this number is less than the GL_MAX_LIGHTS constant of 0x0D31 I see in GL/gl.h. I will have to investigate this further.

• Sat Jan 15 14:12:51 EST 2005

  no shadows, no inter-reflection (1024x768, 100 samples)	no shadows, inter-reflection (1024x768, 100 samples)
  shadows, no inter-reflection (1024x768, 10000 samples)	shadows, inter-reflection (1024x768, 10000 samples)

  no shadows, no inter-reflection (1024x768)	no shadows, inter-reflection (1024x768)
  shadows, no inter-reflection (1024x768)	shadows, inter-reflection (1024x768)

• Fri Jan 14 19:50:26 EST 2005

  I'm trying to render a new brain dataset with better lighting and global illumination to compare with vicinity shading. Vicinity shading is not true global illumination because it only considers direct lighting. Also, their use of a headlight can be used with our technique too. Additionally, our technique allows for arbitrary texture resolution.

  I'm currently rendering new images of the following scenes.

  On Monday Tuesday I need to apply to Disney and call Harris to politely decline. Also I need to make figures and write.

  On Saturday and Monday I will be working with Dr. Banks on the siggraph paper.

  I would like to spend some small amount of time doing new development on pane.

  no shadows, no inter-reflection	no shadows, inter-reflection
  shadows, no inter-reflection	shadows, inter-reflection

• Mon Jan 10 15:54:53 EST 2005

  Notes:

  • Comparison with vicinity shading is... unfavorable. Revise thesis statement.
  • Problems with fake lighting: Area lighting with shadows turned off does not look like openGL because of extended light sources and 1/r^2 drop off. Interreflection doesn't work because all surfaces become fake light sources.

• Fri Jan 7 15:12:44 EST 2005

  
  Global illumination

  
  Direct lighting

  
  Direct lighting as point lights

  
  Open Inventor

  
  Direct lighting without geometry term

• Mon Mar 15 16:28:53 EST 2004
  Benchmarked the SGI Altix 350 we're borrowing from SGI.

2005 Page 1   Page 2

Kevin Beason /

Home