Point Sprites and Leafy Trees

I finally managed to get point sprites working to a decent state, thanks to the magic of the Alpha Test, as can be seen in the latest screen shot. Only problem now is that the leaves displayed are all standing on end, rather than in a sensible direction...

One solution is to create a 3D texture with multiple rotations of the sprite, and then specify an r texture coordinate during calls display points. While this would undoubtedly work, a more sensible solution is to use a textured quad instead. Takes a little more programming, but ultimately it's a lot more flexible. And thanks to the geometry of the tree generated by Arbaro being a set of eight vertices making six trianges, I can get the direction the leaf is in, cross it with the camera vector and get the relevant vectors to displaying a textured quad.

I'll post a screen shot when I've done this...

Rain

Today I added a particle-based rain system, which you can see in the latest screen-shots. Currently it generates one thousand particles which are updated every frame based on their velocity. The system itself introduces gusts of wind at random intervals for random lengths of time, and this affects the movement of the particles.

Because rain tends to be at terminal velocity by the time we see it, the particles are given a starting velocity that only changes in the x- and z-dimensions (i.e. horizontal plane). Each frame, before gust influence is calculated, these values are decreased so that the particles will go back to straight downward motion, to simulate air resistance and to give a smooth reduction when a gust stops.

Trees

In the interest of making the simulator more realistic, I have started adding trees to the scene. Initially, I looked at implementing Weber and Penn's algorithm described in Creation and Rendering of Realistic Trees, however it became apparent after reading through and starting to implement a generator that this was not going to be easy, or fast. However, I came across a wonderful application called Arbaro, which is a java implementation of said algorithm for creating trees for POV-Ray.

Arbaro generates POV-Ray inclue files (.inc) which are text descriptions of the vertex, normal, and face data of the tree created. While this makes POV-Ray very portable, it also means it's not the simplest of files to read (binary files are easier, read a header, allocate some memory, read the rest...). So, after a bit of work deciphering the file, and trying to ignore unimportant sections, the simulator now reads in trees generated with Arbaro.

Since Arbaro is generating for a raytracer, it creates leaves for it's trees. Each leaf is comprised of six triangles. I decided that, in order to conserve precious rendering time, I would render leaves as either points, or point-sprites (i.e. particles). That meant I had to average the vertex positions of each triangle, and then average the averages for each leaf to leave me with one vector for each leaf.

The result is this:

Which looks pretty good, so far. Currently the leaves are rendered as anti-aliased points, and with blending enabled this makes them rougly circular. Since the number of leaves is constant, point sizes increase exponentially as the camera approaches the tree, so that gaps aren't left, and foliage appears thicker.

Constant point size:

Variable point size:

The only problem with this is that it makes the trees look a little cartoony close up:

However, I plan to implement point sprites in an effort to rememdy this.

Sprite Fonts

I decided it was time to add text capabilites to the application. Initially, I looked into it and thought that rather than writing my own sprite font class, it would be easier to use the free library glFont2. However, after failing to get it to work correctly (It was just displaying coloured squares on the screen...) I decided to write my own handler.

The result is this:

The font colour can be changed by simply using glColor3f, and is written with a function DrawString(char *, int, int) which allows you to specify a string, and x ad y coordinates on the screen.

It is currently in use to display the camera location within the field in the upper-left corner of the screen, like so:

Implementing this was actually suprisingly easy. ASCII values for the characters needed are in the range 32 to 127, so converting from a char* to a set of ints was easy. With the value for each character, texture coordinates are calculated on a base "font" bitmap file, and drawn to the screen as a textured quad. Simple!