::recent
::off-topic
-:-whoami
welcome!
alternative
::downloads
-:-free
-:-non-free
::coding
-:-projects
gallery
samp
other
::misc
contact
my bookmarks
...
| 
| frozen. | Mon Apr 16, 2007 | | Cornell Boxing | Wed Jan 31, 2007 | | Daylight Simulation | Fri Dec 08, 2006 | | Massively Complex Landscapes | Wed Nov 29, 2006 | | A shiny and bright place. | Mon Nov 13, 2006 | | Shadows, Global Illumination and Fun | Mon Nov 06, 2006 | | Coloring and Triangulation | Sat Nov 04, 2006 | | Faster Noise. | Mon Oct 30, 2006 | | Introducing Mister Perlin | Fri Oct 27, 2006 | | First MLRTA Screenshots | Wed Oct 25, 2006 | | The gladius is beeing forged. | Tue Oct 17, 2006 | | Introducing Mr. Phong | Fri Sep 15, 2006 | | Stochastic Importance | Tue Sep 05, 2006 | | A new approach... | Wed Aug 30, 2006 |
| (this is a copy of the first xitrace.org blog-entry)
Long time no update on this site, but things have been in (slow) continous motion.
At first: The project gladius gprt has been frozen. Things have shown that the cores of gladius are not well armed for massively noise reducing rendering techniques like Metropolis Light Transport (MLT) or Energy Redistribution Path Tracing (ERPT).
So, on the one hand, I had a very fast global illumination ray tracer with hard constraints on extendibility, on the other hand a very slow realtime ray tracer. Thus I decided to start a new ray tracer from scratch, fully written in C, flexible due an interface oriented design.
xiTrace, or xitrace (unix name) will be released under the GNU-license. The project page is
http://xitrace.org
you will also find xiTrace on source forge.
Finally, here are some first test renderings, demonstrating simple, exponential motion blur and the floating point value back buffer.
     
     
| |
| Cornell Boxing | Wed Jan 31, 2007 |
|
Cornell Boxes ...
Verification time
For verification reasons I've rendered tons of Cornell Boxes. Nothing really special in the discipline of Realistic Image Synthesis. One major observation was that mostly indirectly lit scenes don't really look good using standard path tracing. So I tried to implement Bidirectional Path Tracing.
 
... more of them ...
Grinding Bidirectional Estimators
At first I tried out the Lafortune/Willems edition. I found out that I have some serious lacks in knowledge regarding Monte Carlo Integration and Monte Carlo Ray Tracing. So I got a bit deeper into the topic and ended up implementing the Veach one. Basically the latter one worked fine, but to seriosly use it in an unbiased way I have to learn more about optimal combination of estimators.
 
The image on the left has been rendered using Bidirectional path Tracing, the right one using standard Path Tracing. The difference is mainly caused by differing values for the maximum path length being traced.
Future...
To make a further step in Ray Tracing I've printed out some chapters of Veach's thesis which I am currently 'studying'.
Some testimonials using a spherical luminaire as the sun. Having a luminaire far, far away and with a very, very high luminance is hell for naive Path Tracers and glossy surfaces.
| |
| Daylight Simulation | Fri Dec 08, 2006 |
|
 
Advancing quality
I've read the paper on daylight simulation (by A. J. Preetham, Peter Shirley and Brian Smits) recently and I've had some time to try to implement the topics presented there. My implementation for aerial perspective does not work at the moment, but at least the sky looks similar to the one seen in A Practical Analytic Model for Daylight.
Playtime
Rendering realistic outdoor lighting is very addicting. At first you start playing with the sun's position, moving it from the west to the east, from the north to the south. From right above ones head to the horizon. Then you start playing with the turbicity, making the atmospehere thinner and thicker, again and again. I've felt myself more like a photograper than a coder...
Yet to come
It's allready fascinating, but I have not fully implemented the features of the book yet: There is currently no fog or haze visible on the geometry, so I will spend some more time inside that topic.
Thank you for your interest, see you later!
 
| |
| Massively Complex Landscapes | Wed Nov 29, 2006 |
|
    
some traversal complexity illustrations. Dark regions are the fastest, that means, regions where a ray finds a very straight path to the geometry with a minimum of traversal errors
Landscapes. Massive Landscapes.
I've not been coding much the last week, dito this week. But I have managed to work out a technique for ray tracing heightmap-based landscapes efficiently, regarding both amount of memory as well as speed; I will write a paper about it.
For the moment, just some hot facts for my good old Athlon XP 1800+
running within a block of 512MB DDR-RAM:
- with it's current, unoptimized traversal code, the technique enables the tracing of 0.5 - 3 million rays per second
- using linux with it's aggressive memory management, you can easily fit a heightmap with 8193x8193 elements and an accuracy of 1/65535 per height value into memory (this makes a triangle count of 134,217,728 = 134 million = 0.134 billion)
   
interactive ray traces with one directional light and one shadow ray
Comparisons.
A paper by Andreas Dietrich, Gerd Marmitt and Philipp Slusallek called "Terrain Guided Multi Level Instancing of Highly Complex Plant Populations" (using ray tracing) described a two dimensional kd-tree. And they wrote they stored a 8193x8193 heightmap into that kd-tree, packed into 21GByte of memory. The testbed was a shared memory system with 8 duo cores (2.0 GHz each) and a total RAM of 64GByte. They renderd that heightmap (including billions of plants) within ca. 19 seconds (with a screen resolution of 640x480).
Compared to my testbed, it's blown:
A singlecore AthlonXP 1800+, total RAM 512MByte. A heightmap of 8193x8193 elements. My acceleration structure, which is packed within RAM (actually, the whole rendering needed less than 400MByte (so the implementation in the paper used more than 40 times the memory I've needed). Rendertime for my implementation was about 0.5-2 seconds (but I have to say I did not render any plants) at a resolution of 800x600.
Conclusion.
As said before, my implementation is far away from beeing perfect: The code branches often, it's traversal is recursive and some data, which should be precalculated, is calculated on the fly.
So, a bit of optimization to do for me, and a bit of paper writing. See you!
a big testimonial. rendertime was about 4hrs at an original resolution of 2480x2048 and 300 samples per primary intersection
| |
| A shiny and bright place. | Mon Nov 13, 2006 |
|
A shiny and warm place called Monte-Carlo
I said 'I am a bit dissappointed of the results' in one of the last posts after rendering a global illumination perlin landscape.
Well, a little but evil error in the lighting algebra was the root of that evil.
I've fixed it and I had to implement explicit storage of the landscape vertices because the rendering using implicitly saved
coordinates was far too slow for global illumination...
From infinity to explicity
To summarize: In the beginning, there was ray marching and infinite detail with storage of just a few bytes. Then there was ray
tracing using implicitly defined triangles and a quadtree with just a few MBytes of storage. And now, there is everything
explicit, using tens of MBytes of memory...Reminds me on a paper I was writing a month ago, with about a hundred millions triangle
landscape at less than 512 MB Ram. I will continue my research with a little modification in the acceleration structure and
traversal.
Roadmap
To get more realism, I will implement realistic skylight soon. Furthermore I began the creation of a new L-System based
programming/scripting language. May the stars shine bright.
Have a look
 |
 |
| a first try using the fixed lighting math |
a second, blown try. took a 3/4 day to render, which is obviously too slow |
| |
| Shadows, Global Illumination and Fun | Mon Nov 06, 2006 |
|
 |
 |
| simple shadowing. |
global illumination. the effect of global illumination will be more saturating after some more features are implemented. |
Feature Extension
I've programmed two important extensions for my ray tracer:
I. shadows casting (see the first image)
II. diffuse global illumination (the other images)
This is nothing new, and the previous ray tracer (which contents can be found in the gladius-log, too) had more lighting features, including glossy mirrors, but I had no landscape screenshots so far. Well, I am a bit dissapointed of the results. It doesn't look very special. But maybe some more programming work will do the job: a realistic sky, flora, realistic sun light and more...who knows (a smile glimpses in my face;))?
Global Illumination in Stereo
Please enjoy the last two renderings, those with spheres only. They were just intended to be test-scenes, but I thought they would look nice in stereo. You should try the small versions first and then maybe the bigger ones, have fun!
 |
| just a test scene. rendered using a MLRTA-criteria SAH-kd-tree. rendering time was approximately 2.5 hrs. with 500 samples per pixel. originally rendered in 2560x2048. |
| |
| Coloring and Triangulation | Sat Nov 04, 2006 |
|
Coloring
Based on the surface normal at a given point on the landscape I implemented a simple texturing method, which makes the top of the hills look green and the walls look gray in the pictures. This, I think, increased the beauty of the terrain.
Tesselation
I was struggling at finding the actual and accurate bounding box of the sub-nodes of the acceleration structure of the perlin noise landscape. I tried several approaches and all were either very time consuming or inaccurate, resulting in unaesthetic artifacts.
To avoid the artifacts I began to tesselate the infinite detail terrain into triangles, a lot of them. As a result I canceled the ray marching algorithm (which could cause some additional visible artifacts) and revived ray tracing on the landscape. Now the results are very exact (ignoring the fact that you can see the tesselation when zooming in, but using a higher tesselation detail avoids it).
 |
 |
| rendered 300 meters above sea level. in this close up the tesselation of the landscape is visible, but a higher level of detail can be used |
rendered in 4,000 meters above sea level. the whole landscape scales 20x20 kilometeres |
| |
| Faster Noise. | Mon Oct 30, 2006 |
| 
good old quad-tree
Old School Lessons, Part 1: Quad-trees
The day before yesterday I decided to implement a landscape-classic: the good old quad-tree. It partitionizes the scene into four sub-scenes. Each of the sub-scenes again partitionizes into four sub-scenes. A hierarchy is build with the target to avoid unnecessary intersection tests where logic says "here no intersection, definitively, go further". This partitioning's scheme is demonstrated in the above image.
Using the quadtree accelerated the rendering by an order of tens up to several hundreds.
The images below show an extreme zoom of a far mountain (about 15 kilometers away from the camera). It's time to bring some flora and fauna I think...
Have some fun, see you later!
extreme zoom. reminded me on the olympus mons.
| |
| Introducing Mister Perlin | Fri Oct 27, 2006 |
|
 |
 |
| a heightfield rendered using ray marching. In theory the heightfield has an infite level of detail |
a more detailed version of the heightfield |
Making Noise, Perlin Noise.
I've just implemented a quick and dirty hack to draw landscapes of infite detail (thanks Thomas Ludwig [alias lycium] for the hint) using Perlin noise, invented by Ken Perlin (he was in the Tron team at Disney). Find some information about him here (page about his "oscar") or here (his personal homepage, you should definitely compile the code snippet on top for the site, you'll be suprised!).
The memory usage is converging to zero, it never minds how huge the landscape is (never minds) due to the parametric nature of Perlin Noise. But at the moment the rendering of the landscapes/heighfields is quite very slow, ranging from tens of seconds for low detail, to hours for higher detail levels. So I have to do something, and here is where my experience with landscapes comes in handy (have a look at my root-engine)...
Finally, have a look at the images before you leave and thanks for your interest, you're always welcome here!
 |
 |
| getting closer... |
...and closer; at the bottom of the image you can see some discontinuities caused by the finite accuracy of ray marching (this has nothing to do with the infinite detail of the landscapes itself; if anyone know a better algorithm than ray marching, please let me know! |
| |
| First MLRTA Screenshots | Wed Oct 25, 2006 |
|
scene traced without MLRTA. the intensity of blue describes the number of traverses needed to find an intersection. the intensity of green shows how many empty cells have been traversed.
After implementing a good SAH kd-tree the next target is MLRTA ( Multi Level Ray Tracing Algorithm ).
The target of MLRTA is to reduce the overhead needed for each ray to find a possible intersection. In MLRTA you trace a boundary for a group of rays (e.g. a pyramid) and find good entry points for traversng an acclereation structure.
Let's say you're a teacher, and you want the kids present a school lessons topic. Now instead of sending them wildly into the town you define a good entry point (EP) for their research or search: the library. Now with this EP, the overhead for each kid is already reduced. Further you have two main groups, one group will present arithmetics (group A), the other one german literature (group B). Starting from the first EP you look for a good one for group A and one for group B. You find out that "nature science" is a good EP for group A, "literature" a good one for group B.
You can now continue the search for good EP's for the sub- and sub-sub-groups. And when you found good EP's: Let your kids spread out. Now they will be able to find good sources for their researches faster than without MLRTA.
At the moment my implementation is not perfect and seems to be buggy in some special cases. Have a look at the images (they remind me of tron).
 |
 |
| simple EP search. the red regions mark packets of diverging (incoherent) rays. note that the algorithm is able to detect holes in the scene, which appear black on the images. |
EP search with adaptive tile splitting. if an EP is already the actual target of a search, it won't be further determined for smaller groups of rays. |
| |
| The gladius is beeing forged. | Tue Oct 17, 2006 |
|
 
After my system crash I began to write a new ray tracer from scratch. It will provide high performance rendering with single ray traversal.
Currently the top feature is a good SAH (surface area heuristics) kd-tree, which enables the ray tracing of thousands of objects at several frames per second (one demo renders 250.000 spheres). Today I will begin implementing the MLRTA-algorithm (multi level ray tracing), which will boost up the frames per second again.
Gladius will be a general purpose ray tracer, aiming on real time ray tracing as well as on fast global illumination. This time it's really serious.
| |
| Introducing Mr. Phong | Fri Sep 15, 2006 |
|
A wallpaper for you
size: 1280x1024, 1000 samples per pixel, rendertime 6.4hrs/384min
Imperfect Mirrors
 
Yesterday I found some time to implement specular shading/reflections via the Phong model ( wiki-article ).
The two images on top are currently the cream of my ray tracer (which is still unnamed). They show sculpture and dragon with a 100 percent reflecting material (but soft and unsharp reflection) in the center and some additional (also specular) objects, with mixed diffuse and specular material properties.
The images at the bottom show how the change of one or two parameters can change the whole appearence of the scene (the light [as far as I remember] has the same energy/color in all images).
Performance
The last renderings have shown, that with importance sampling and 400 samples per pixel you can achieve a noise-less image of the used scene at 640x480 (render time was about 35-45 minutes with a maximum path-length of 3)
    
Errata
-
The previous entry contained an linguistic error: "I've worked out on an extension to the standard path-tracing" -> What I meant: "I've worked on" (Thanks to Thomas Ludwig/lycium for the hint)
-
About the 'extension': While I was talking about Thomas Ludwig/lycium all the time at the fractographing, I (while being in a rush) forgot to thank him for help, and for the idea of connecting all secondary rays, so,
thanks lyc, keep your head up, mate!
| |
| Stochastic Importance | Tue Sep 05, 2006 |
| |
I've worked out on an extension to the standard path-tracing ( as presented in The Rendering Equation, Kayija 1986 ), which connects each point of the generated path with each other point. The effect is great, dito the noise-reduction.
Then I managed to implement simple importance-sampling, which is quite easy once you have done it. And dito the effect is great, but...
...at the moment this works for the standard path-tracing-algorithm only, not for my extension, so I have to work out an extension to my extension, which is called multiple-importance-sampling.
I am really interrested in the upcoming results. Not only the noise-reduction has to be done, but also a big couple of other things like mirror-like materials, hdr-environment maps (a kind of background for the images, that will really boost up the graphics) and, glimpsing on the future, sub-surface scattering (which will allow semi-translucent materials, think of very thin marbles illuminated from the behind) et ...
   
... cetera. But for now, thanks for reading! And maybe have a look at the images. The first two images show the power of bih-trees (see previous chapter in this category), and the other ones: Comparisons of renderings with and without global illumination. In my opinion the lighting comes close to the light-situation you have in a deep and dark forest.
| |
| A new approach... | Wed Aug 30, 2006 |
|
"How many clowns can be crunched into the car?" A benchmark to check how many spheres can be put into circa 320MBytes of available memory: around 2.5 million
...on photon movement
After pausing my studies on ray tracing (and even pausing the writing of a tracer itself) it looks like the problem of solving the rendering-equation catched me up again.
I've read the paper about the new bih-trees ( Bounding-Interval-Hierarchy ) by C.Wächter and A.Keller.
It will be presented at Eurographics 2006. It gives good performance on finding the nearest intersection and does not need the vast amount of memory like a good kd-tree does. With this tree even my poor 512MB-DDR-Computer is able to push 2,500,000 unique spheres on the screen (see the first image for this).
And now, having the bih-tree implemented, I can go further. Target is still global illumination (or simple GI). GI is what makes your ray traces look realistic. And GI is a giant topic. The two images on the left and on the right, which show some objects with an ideal diffuse surface (also called lambertian) just give you a glimpse on what is coming up.
This ray tracer will be the one for me (for the next time at least).
At last, some greetings to an old "friend":
I'll move you, lil' bug, to the trash-directory
| |
| |
