Check it out. I actually finished something! (click it!)
Edit (14.04.13): Updated it. Finally had the time to add some sounds and fix some bugs.
I recently found the solution why the my little god ray program didn’t updated the light position correctly.
So, for starters, I needed to convert the light world coordinates to screen coordinates. But, to make things simpler, the coordinates could remain normalized between -1 and 1.
Here is the function:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | function get2dPoint(point3D, modelViewMatrix, projectionMatrix) { var np = [point3D[0], point3D[1], point3D[2], 1.0]; var np2 = [0.0, 0.0, 0.0, 0.0]; var np3 = [0.0, 0.0, 0.0, 0.0]; mat4.multiplyVec4(modelViewMatrix, np, np2); mat4.multiplyVec4(projectionMatrix, np2, np3); var rp = vec3.create([0.0, 0.0, 0.0]); if (np3[3] === 0) return [0.0, 0.0]; rp[0] = np3[0] / np3[3]; rp[1] = np3[1] / np3[3]; rp[2] = np3[2] / np3[3]; var dest = [rp[0], rp[1]]; return dest; } |
The thing I didn’t realized: The texture coordinates for the framebuffer are between 0 and 1, so I had to normalize the screen coordinates to this range.
1 | lightScreenPosI = (lightScreenPosI + 1.0) / 2.0; |
And voilĂ !
(click it)
Just found that inside the threedlibrary for webgl:
1 2 3 4 5 6 7 8 9 10 11 12 13 | /** * Array of the indices of corners of each face of a cube. * @private * @type {!Array.<!Array.<number>>} */ tdl.primitives.CUBE_FACE_INDICES_ = [ [3, 7, 5, 1], // right [6, 2, 0, 4], // left [6, 7, 3, 2], // ?? [0, 1, 5, 4], // ?? [7, 6, 4, 5], // front [2, 3, 1, 0] // back ]; |
Even Google has no idea what they’re doing. Made my day.
Aaaand God said: “Let there be rays!”

click it!
edit:
The code has some bugs, for one, the light coordinates are wrongly converted – so they are always passed as [0.0, 0.0] to the fragment shader. (The light source will always be coming from the left bottom.)
There is still lots of room for improvement for my planet renderer. Here’s a short list of what I plan to work on the next months:
- Fixing the neighbor search for the different sides of the quadcube.
- Store the quadtree structure externally – there is really no need for computing it every time the application starts.
- Fix the terrain “popping” through alpha-blending
(or geomorphing, I’m not sure yet). - Do some occlusion culling with PVS.
This should increase the rendering speed. - Fix the backface culling for the patch bridges.
- Add a detail texture for near-ground view.
- Maybe add high(er) resolution textures though mipmapping and/or streaming.
Oh, in other news: I got my Bachelor of Science degree today. World domination is only a few steps ahead.
Now that I’ve finished my bachelor thesis, I can finally continue coding my C# 3D engine. Well, I’ve been doing this for my thesis… but half of the time spend on the thesis was spend on writing it. I’m very proud of it, but it WAS a pain in the a**, especially because I’m not used to write scientific texts. I wanted to write everything in LaTeX, but reverted back to MS Word so I wouldn’t spend all my life trying to format the text.
I think the result is kind of presentable…
So now I will be focusing on the planet renderer. It has still a lot of room for improvement… so stay tuned.
Annnd here come the shadows… only hard shadows for the time, hope I’ll get to the soft shadows soon.
Finally, the diffuse lighting works and I managed to kill some bugs.
It’s really easy to make once you’ve managed to get the math into the code…
So there I was, checking my code over and over again for some errors I simply can’t seem to find… and after a few changes, I got this nice… well, kaleidoscope. Funny thing.







