A late update.
First try on fluid simulation. The fluid simulator is very hard to use, given that the accuracy is not high enough. For a still image, each droplet must be manually adjusted; otherwise, the droplets will go halfway through the walls.
Most of the time was used to edit the water. I didn't pay much attention to the bathtub, and I think it is too reflective and too smooth. Luckily it is blocked by vapour.
(Click image for larger version.)
4000 samples, 8 hours rendering time.
Cycles is official in Blender 2.61. So, what is the best way to celebrate? Use it, of course.
This is my first scene with Cycles, second render.
This is also my first try on texture in Blender (which turns out pretty bad)...
(Click image for large version.)
For this render, I mistakenly turned off the "caustics" option. This makes the glass piece lack the "shininess", and look more like plastic.
Made with Blender 2.6.1, rendered with Cycles.
3000 samples. 5-something hours of render time.
Using C++ as a teaching language is a very dumb idea.
Programming is about all the programming concepts. Languages implement those concepts. Which language you use doesn't matter, as you are using the same way of thinking[1], expressing the same concepts.
While this is true for programming, learning programming is whole another thing. When you don't have the concepts, simultaneously learning the specific language syntax will distract you. That's why things like loop and conditional are usually taught without mentioning syntax at first. Learning semantics and syntax at the same time is hard. With C++'s complex and cryptic syntax, the distraction is so big to the point where some students never understand the programming concepts.
Take the for loop for example. In C++, the syntax of a for loop is:
for (initialization; condition; action-to-counter;)
An example is :
for (int = 0; i < 10; i++)
You can omit any one of those. In fact, you can omit all of them. Therefore, the following is a valid statement in C++:
for (;;)
This is a way to achieve an infinite loop in C++. The problem is, this obscure the line between for loop and while loop. Yes, this is a valid command, but it does not convey the concept well. Compare to the usual pseudo-code:
for i in 1 to 10
one can really see the syntax from Python:
for i in range (10)
and the one from Ada:
for i in 1 .. 10
is clearly superior, and the C++ one is really cryptic. C++ is too close to the metal; the high-level programming concepts is behind too many abstractions, or rather, details of the underlying hardware. Some may argue that it is this thing that distinguish brilliant programmers from the mediocre, but I say that this undermines so much brilliance.
Actually, this syntax of for loop comes from C, and I condemn every language that copies it. This includes but is not limit to C++, C#, Java, JavaScript, and PHP. For a programmer, learning a new syntax of a different language is a matter of minutes, if not seconds. But, for a newcomer, learning the concept of for loop from this syntax can be a painful process.
Using C++ to teach programming is a very dumb idea, especially when teaching someone who has never learnt programming before.
Pedantic footnote:
[1] With some variation. due to the characteristics and limitations of different languages, you may or may not convey some ideas or concepts in a language.
"Why do I need to reed the book about programming now? How much will be taught in a lecture session? Less than a chapter? Then I have time. There is no need to hurry."
After hearing this, I felt very in danger as a group-mate.
Programming is not something you can simply read and do. Programming is abstract; there are things that you need to remember, think, and practice. This is more true considering we are learning C++.
When I first learnt pointers (and reference, simultaneously, which is a pretty bad learning plan), I had a really hard time understanding what was going on in the code. It just didn't make sense to me. For the next two years I didn't even touch programming, let alone C++ and pointers. But when I re-learnt pointers later, suddenly I could understand the code.
Even if you're not thinking about it, your brain continuously reorganises things you have learnt. You just have to give your brain some time to digest.
If you think you are going to learn programming sometime in your life, you had better read something about it now.
My primary development platform is a notebook of my father. A few days ago, his another notebook broke down, and he needs a replacement to comtinue to work. Naturally, my working station is retracted by its owner.
Now, falling back to the original 10-year-old notebook, limited by computational power and supported standard, there isn't much that I can do. Mesa with software rendering brings me OpenGL 2.1. Fair, but it does not allow non-power-of-2 or rectangle texture. Very bad for tone mapping and HDRR, which a screen-size texture woulde be the best option.
HDRR algorithm should be picked and implemented before any lighting is done. Otherwise lots of parameters will need to be reviewed and adjusted after HDRR is applied. Furthermore, I don't want to remove a fully functioning part from tthe project now just to make it run on an inferior system.
That's why all developments are halted.
Since a friend of mine is learning Java at the moment, let me join him before I get a new computer (whick must support at least OpenGL 3.3, and preferably 4.0+).
Project G:
Changes are highlighted.
Details:
Performance is not the main reason for porting to C. Using the Python implementation, frame per second is still above 200 when there are more than 1000 triangles, and even with a simple yet expensive shader. That is, Python is not the bottleneck.
What forces me to migrate is the limitation of PyOpenGL. With it, things like VAO, framebuffer need to come by extension. For the current version PyOpenGL 3.0.1, that means importing one more file for each functionality. Yes it is a one-liner, yet it is still very annoying (and uncertain. Why should I use ARB extensions if that those are core functionality of 3.0+?). Another thing, PyOpenGL officially supports OpenGL only up to 3.2, I want 3.3 (much easier to programme).
With PyOpenGL 3.0.2 up, the problem of extensions seems to disappear, but 3.0.2 is still in early development stage, and I can find no easy way to install it. In fact, I cannot even find the source. The problem will go away if I can find some OpenGL extension loader, like GLEW and GLEE. Sadly, GLEE has OpenGL support up to only 3.0 (and there is no Python binding), and PyGLEW has not been updated since 2007 (even before OpenGL 3.0 is out).
Combine the hope of OpenGL 3.3 functionality, I turn to C. Waiting SDL 1.3 to be finalized, now I use freeglut as a temporary solution for manage OpenGL context window creation and simple mouse / keyboard detection.
But... Using freeglut, which is capable of creating at least a 4.0 context, I am still only getting 3.1. After updating the NVIDIA driver from Fujitsu website, I finally see a 3.3 context. Going back to Python with Pygame and PyOpenGL, I see 3.3 too...
Anyway, we are in the middle of the way to Canaan now. When SDL 1.3 turns gold, I do not want to wait for Pygame to catch up, so we will migrate to C by this year nevertheless, it is just a matter of time. Hope we will not be stuck for 40 years.
When the C version of renderer first ran, I thought there would be a huge increase in FPS, as the window (running pretty much the same code) on OpenGLBook.com runs at about 3000 FPS. My own calculation suggests that my window (at the same 800x 600 resolution) is only running at 500 FPS at most. The difference is so huge that I immediately suspected either the (still-empty) rendering pipeline or the FPS-counting algorithm went wrong. Inspection failed to support the suspicion. It is hard to believe that it is hardware limitation. Before I move the programme to other computer, this remains a mystery.
As of why it is C and not C++, it is because C++, from the core of the specification, is just a mess.
Changes are highlighted.
Details:
Lighting did not work properly. It turns out, when I import normals from the Wavefront .obj file, I forgot to append a 0.0 (the w component) to the normals. So, complying with the GLSL specification, the compiler appends a 1.0 to the normals, turning them into positions instead of directions. That's why the computations all go wrong. After updating the Wavefront .obj file loading code, the normals turn back to directions, and the resulting rendering is pretty.
In the above screen shot, Gaussian specular model (a quite expensive one) is in action. Shading for the capsule is not good (look at the abrupt brightness changes and rough edges), not because the shading algorithm is bad, but because the mesh data is badly constructed. The cylinder on the left looks perfect. That is the power of more than 500 triangles.
Texturing has been postponed, again. As I don't have any texture by now, there is no incentive. Even if I have done it, there is no way to debug and ensure functionalities. Anyway, with shaders, we can achieve lots of wanders, even without textures. So I will focus on lighting computation in the not-so-distant future.
For HDRR to work, frame buffer, which is what I'm studying, is required. Once the mechanics is clear, implementing it should not be very hard. Moreover, with frame buffer, many post-rendering effect and in-engine (I won't call it in-game for now) screen shot could be achieved.
IELTS is coming; therefore working progress of early August will be very slow, if not totally halted.
Changes are highlighted.
Details:
Perspective projection is just matrix multiplication. After setting up the matrix and importing the code that actually does the maths, it's basically done (no, I'm not going to reinvent the wheel here). All left is the tweaking. One of the outcome of tweaking the numbers that go in the matrix is that, you get different zoom effect; so the zoom functionality is a by-product. Nonetheless, this functionality is crucial for navigating in the vast space that I'm going to make.
Currently, the rotation algorithm is based on matrix. Yet, due to how floating point numbers work in computers, errors will accumulate, and rotations will eventually become something more than just rotations. Unwanted transformation and scaling is expected when the programme runs for a long time. Planing to move to quaternion-based algorithm.
Lighting works, if totally flawed:
Not particularly convincing. In fact, it looks awful. Both the per-vertex (directional) and per-fragment [or per-pixel, in Direct3D parlance] (point light) lighting are enabled. Apparently, neither of them function properly. I'm still investigating whether it is the surface normals or the algorithms, or both, that get wrong.
