You are currently browsing the category archive for the ‘Programming’ category.
After finally getting Ruby and Rails to work, I’ve started playing around with various IDE’s (Integrated Development Environment). Although there’s nothing wrong with SciTe (it comes standard with the one-click installer), I feel that more is needed once you get past the basic tutorials. This is especially obvious when it comes to debugging and code completion. I’m kinda ashamed to admit that I’ve become spoiled when it comes to code completion and I can’t imagine working without it. In other words, I’m lazy.
Anyway, the first IDE – RadRails. RadRails is basically Eclipse-like IDE for Rails that is added to the Aptana Studio. I’ve never been a big fan of Eclipse. I don’t feel “at home” when using it, there’s just something missing for me and I’m always wary when dealing with Eclipse plug-in’s. RadRails, apart from the familiar Eclipse looks, offers debugging (even profiling with the pro version, which probably is pro expensive as well), all sorts of editors (CSS, JS, SQL, …), code completion, testing, integrated server and so on. All in all, it doesn’t seem like a bad choice. There are, however, two quirks that I’ve came across. Firstly, a couple of exceptions were thrown during the installation. Clicking the retry button a couple of times seems to have solved it, but who knows what did or didn’t get installed properly. Secondly, HTML source code viewer is bugged. Instead of showing me the code, all I get is a black screen with mysterious white lines appearing everywhere I click. Here’s a picture to show what I mean.
A bugged HTML code viewer.
Not exactly a serious problem since there’s an easy way to fix it (just hit the Add new preview button and you’re done), but it becomes annoying after some time. Still, with so little choice when it comes to IDE’s, you should at least give it a try, especially if you’re already familiar with Eclipse. Personaly, I’ll stick with NetBeans for now (a review is coming after RubyMine).
Next time, RubyMine, the most intelligent Ruby IDE (or so they claim). See you then.
In my previous post, I’ve commented on how hard it was to manually install Ruby on Rails. The easiest solution was to grab the 1-Click Rails Installer. However, 1-Click Rails Installer doesn’t come with the latest Rails or RubyGems version.
Updating Rails is a no-brainer: just use gem install rails and you’re done with it.
Updating RubyGems is easy as well, once you figure it out. If you try to start the server using updated Rails version but with outdated RubyGems, you will be told to update your RubyGems with the command gem update –system. This, however, doesn’t work. The two commands that will update your RubyGems are gem install rubygems-update, followed by a update_rubygems command. This will then remove the old version and install the new one. Starting the server afterwards will happily work and you’re ready good to go.
Apparently, this works on Mac as well.
Note: If you’re in Vista, you must start the command prompt as administrator. Under Mac/Ubuntu, use the sudo for both commands. I haven’t tried it on any other linux flavour so far, but I’m guessing that logging in as root will do the trick.
I’ve tested this when updating Rails from version 2.1.0 to 2.3.1 and RubyGems from version 1.1.1 to 1.3.4
I’ve heard so many good things about Ruby and Rails. How it will make web design a breeze, how easy it is to use and learn etc. As I’ve been using JSP and JSF in my last project, I was really excited to try and learn something new and more easy to use. JSP was just a pain when things got more complex. I’ve went through a couple of online examples, even tried the interactive online Ruby interpreter and everything seemed straightforward. Then I’ve tried installing it. The damn thing took almost a week before I’ve finally gotten a Hello world web page up using Rails. Gem packages would always whine about missing dll’s, so did MySql. Only after giving it up on MySql and installing SQLite did I get the thing to work.
Spending a week just for a proper installation doesn’t sound like making my life any easier. It was making my life a living hell. It has totally put me off and it’ll take a couple of days/weeks or another JSP project before I get the excitement back up again. It wasn’t so much of a Ruby’s fault as I’ve managed to get it working preety much right away. Getting Rails to work was just a pain. 1-click-Rails installer did the job just fine, but I wanted to install it manualy, which in Rails’ case, is a pain in the butt.
Per vertex shading, otherwise known as Gouraud shading, helps us achieve smooth shading results with relatively low computational demands. The idea is really simple, yet I haven’t seen a lot of information about it on the Internet, so I’ve decided to post about it myself.
Let’s imagine we want to display a simple 3D model using OpenGL. The model is made up from a large number of triangles or quadrilaterals (quads). I’ll refer to both as faces from now on. If you want to do any kind of shading, the first thing you need to do is calculate the normal of each face. A normal is simply a vector that is perpendicular to the face (imagine an arrow pointing outwards from the face). However, since we calculate each normal of face independently from other faces, the boundaries between the faces are very noticeable. This ruins the effect of a smooth surface as shown on the following image of a DC-10. You can very easily see the faces that make up the plane.
DC-10 model without per vertex shading
The process of calculating vertex normals is as follows: after we’ve calculated (and normalized) a normal vector for every surface of our object, we iterate through all the vertexes. For each vertex, we determine all neighbouring polygons. In other words, we have to find all the polygons that contain our given vertex. There are many approaches to this. There is of course a brute force approach where you check every vertex against every polygon. Although this might do for simple object or as part of a preprocess one time calculation, it’s not very practical. A better approach is to store neighbouring information for each polygon. If you can’t afford that, you could also generate a bounding box or a bounding sphere for each face. Looking for neighbouring polygons should be simple afterwards.
Anyway, after we’ve found the neighboring polygons, we have to calculate the average of all of their normal vectors. This is again very simple to do. Just separately sum up all the X, Y and Z values of all neighboring polygons and then divide by the number of such polygons. Save this averaged normal vector to our current vertex, repeat for all the remaining vertexes and you’ve just done your first per vertex shading. When it comes to the actual drawing, use glNormal3f(nx, ny, nz) before each glVertex3f command (with nx, ny and nz obviously being individual values that make up the normal vector). The result? A much smoother looking object. Add couple of textures and you’ve got yourself a nice looking model.
DC-10 model with per vertex shading
As we’ve seen, per vertex shading is very easy to do and offers nice results. However, when working with animated models, per vertex shading (as shown above) is totally useless as it’s simply not fast enough for any real-time animation (short of displaying a rotating cube in empty space). Vertex programming is the magic word when we want more advanced results. If you want to do it using OpenGL, take a look at the NV_vertex_program (or vertex shaders if you fancy DirectX). You should note that any serious shading done today is directly on the GPU. Most other methods are for educational purposes only as they help to explain certain graphical and geometrical principles. A topic for one of my future posts maybe. In the mean time, have fun with the above tips. If I haven’t explained it in enough detail, let me know and I can paste some actual code.
Denis
