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.
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.
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 inmath.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).
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)
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
Vicinity Shading vs. Global illumination
Vicinity Shading for different shadow ray lengths
Problem fixed. Was editing wrong part of source code.
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).
Mesopic and Scotopic glare simulation (lenticular halo)
New direct light sampling according to actual solid angle instead of approximation (fixes noise near lights)
Attempted to convert Octree traversal into iterative algorithm, slow
Octree-R for Teapot in a Stadium problem
Photopic glare simulation (ciliary corona)
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.
Vicinity Shading vs. Global Illumination (same lighting) vs. Global Illumination (frosty glass setting)
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.
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 |
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.
I'm still working on it but this is the best so far.
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
(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.
- 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
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 |
- 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.
- 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.
It's a photon map and should in this case be uniform, however there are holes.
- 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...
- 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.
 |
|
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
 |
 |
 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 = (
(r1-r2)2 +
(g1-g2)2 +
(b1-b2)2 ) / 3
RMSE = sqrt(MSE)
MRMSE = average RMSE for all pixels
MRMSE = Mean Root Mean Square Error
MRMSE(flocal, 5 spotlights) = 0.00830938 = 0.830938%
MRMSE(flocal, 1 spotlight) = 0.00847661 = 0.847661%
MRMSE(5 spotlights, 1 spotlight) = 0.00163915 = 0.163915%
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 flocal. 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:
For example, the Mean Square Error between a white pixel (1,1,1), and a black pixel (0,0,0), is ( (1-0)2 + (1-0)2 + (1-0)2 ) / 3 = (1+1+1)/3 = 1.
I also calculated the Root Mean Mean Square Error (RMMSE) for the entire image:
I need to adjust the error images so that red means maximum error. Also I need to analyze a single spotlight image for comparison.
- 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.
 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) |
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 |
||||||||||||||||||||||||||||||||||||||||||||||||
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.
Global illumination
Direct lighting
Direct lighting as point lights
Open Inventor
Direct lighting without geometry term
Benchmarked the SGI Altix 350 we're borrowing from SGI.