Eventually, any project requires that we put some writing somewhere. This is a common issue in OpenGL projects, where there isn't native support for writing to the screen. After a look around possible solutions, I've decided to go with FTGL, which implements the functionality of FreeType 2 in a hopefully easy to use way.
Right now my interest is to throw some information up on the screen. Things like frames per second, for starters, so I have some notion of how different changes and platforms affect performance. Eventually, when more of a GUI is in place, it will be useful to have a library in place.
Thankfully SDL offers some handy ways of finding out time in milliseconds, as opposed to system time which runs in seconds.
Sunday, May 22, 2011
Saturday, May 21, 2011
Noisy terrain
A quick update. Waiting for a few books to arrive, but in the meantime I've been messing around and finally decided to add some funky terrain.
The way this works, I stored the values of calling the simplex function and then when I drew the ground I replaced the height with the value for the correct point. The grid is 100x100 in the picture. That's 10,000 squares, or 20,000 triangles. I stored the values of the height in double precision, 10,000 points. A double, in this implementation, is 8 bytes. That means it takes 80,000Bytes (78KB) to store just the heights.
Of course, there are ways to make it better. The important thing is that it looks pretty nifty.
That's the result of applying the simplex function only once, by the way. By running it several times at different frequencies and amplitudes, more interesting terrain should be produced.
The way this works, I stored the values of calling the simplex function and then when I drew the ground I replaced the height with the value for the correct point. The grid is 100x100 in the picture. That's 10,000 squares, or 20,000 triangles. I stored the values of the height in double precision, 10,000 points. A double, in this implementation, is 8 bytes. That means it takes 80,000Bytes (78KB) to store just the heights.
Of course, there are ways to make it better. The important thing is that it looks pretty nifty.
That's the result of applying the simplex function only once, by the way. By running it several times at different frequencies and amplitudes, more interesting terrain should be produced.
Sunday, May 15, 2011
Creating a world
The complex bit for this next leg of the journey, creating a world, is being able to cut the world up into small chunks that can be shown to the player at any point. I can think of two ways of solving this.
One is to load only the area immediately around the player, running the algorithms for terrain generation on the fly. The downside to this is that it is computationally intensive, and the terrain suffers from not being able to have several passes done, so it's going to be simplistic. The upside is that it is quick and easy to get it working.
The alternative is to create the world on a previous pass and store it in some manner, then send it to the program to display. This requires some computation upfront, and space to store the results, but allows a more complex world to be created since you can run several functions over the data set.
Clearly, in either case, you can't try to display the whole world at once. Instead, the attempt should be to display only portions at a time. An approach to try is to use oct-trees to store the data in memory and pass it to the program, after it has been created. I'm still not sure how that would work, actually. I have to do some reading up.
One is to load only the area immediately around the player, running the algorithms for terrain generation on the fly. The downside to this is that it is computationally intensive, and the terrain suffers from not being able to have several passes done, so it's going to be simplistic. The upside is that it is quick and easy to get it working.
The alternative is to create the world on a previous pass and store it in some manner, then send it to the program to display. This requires some computation upfront, and space to store the results, but allows a more complex world to be created since you can run several functions over the data set.
Clearly, in either case, you can't try to display the whole world at once. Instead, the attempt should be to display only portions at a time. An approach to try is to use oct-trees to store the data in memory and pass it to the program, after it has been created. I'm still not sure how that would work, actually. I have to do some reading up.
Saturday, May 14, 2011
Simplex Noise, done!
Well, I managed to get this working. It took entirely too long, had to deal with a few silly mistakes, but it is done.
Wow, underwhelming.
Interestingly, it's fairly slow. I'll have to find a few different ways of doing it. I also sort of cheated a bit. After my implementation of the simplex algorithm refused to work (would just produce 0 everywhere) I copied someone else's. I'll work on fixing that.
It's also given me an appreciation of just how computationally intensive it is. When run without compiler optimizations it crawled along, although it's fairly smooth otherwise.
With this worked out, I can work on the next part of the project. That's going to be creating a sphere which is deformed by the noise I generate. The good thing is that only requires calculating the vertices that need it, as opposed to a texture where each pixel has to be done.
Another aspect to look into is combining the noise with itself, to create smaller ripples and such which result in more realistic and detailed, sharper textures.
Finally, I've been looking into getting some kind of Source Control software. I'm torn between Subversion and Git right now. I'll be looking at reviews and the like to help me make a decision.
That's all from me right now.
Wow, underwhelming.
Interestingly, it's fairly slow. I'll have to find a few different ways of doing it. I also sort of cheated a bit. After my implementation of the simplex algorithm refused to work (would just produce 0 everywhere) I copied someone else's. I'll work on fixing that.
It's also given me an appreciation of just how computationally intensive it is. When run without compiler optimizations it crawled along, although it's fairly smooth otherwise.
With this worked out, I can work on the next part of the project. That's going to be creating a sphere which is deformed by the noise I generate. The good thing is that only requires calculating the vertices that need it, as opposed to a texture where each pixel has to be done.
Another aspect to look into is combining the noise with itself, to create smaller ripples and such which result in more realistic and detailed, sharper textures.
Finally, I've been looking into getting some kind of Source Control software. I'm torn between Subversion and Git right now. I'll be looking at reviews and the like to help me make a decision.
That's all from me right now.
Wednesday, May 11, 2011
Simplex Noise, almost done
I have been working with a couple of implementations of Simplex noise, trying to make sense of it so I can describe it in the technical specification. I've made some decent progress, even. I'm at the point were I could grab the java implementation, port it to c++ and get it to work.
But I won't.
The bit I'm at right now is the attenuation function. After I've figured out the influence of each vertex of a simplex on a point within it, the point on the gradient where it falls for each, I have to attenuate the gradient so that the vertex's influence ends at the simplex and doesn't spill over. While I grasp why this is necessary, I'm not so certain about the numbers I saw being used in other implementations. They all agree, so I expect I can figure this out easily enough. But I'm trying to reach that point first.
There definitely is some merit to writing this all down, as opposed to trying to work it out in my mind as I code it. I'll have to add drawing when I get the chance.
Back to trigonometry, I guess.
But I won't.
The bit I'm at right now is the attenuation function. After I've figured out the influence of each vertex of a simplex on a point within it, the point on the gradient where it falls for each, I have to attenuate the gradient so that the vertex's influence ends at the simplex and doesn't spill over. While I grasp why this is necessary, I'm not so certain about the numbers I saw being used in other implementations. They all agree, so I expect I can figure this out easily enough. But I'm trying to reach that point first.
There definitely is some merit to writing this all down, as opposed to trying to work it out in my mind as I code it. I'll have to add drawing when I get the chance.
Back to trigonometry, I guess.
Spec'ing Out
So my last post offered a functional specification for a simple program with a simple goal. Functional specifications describe the way the program works.
This is all well and good, and every project should start with something along those lines. However, when I tried to work that out I found myself stuck again. Not due to inability to do something (the way I was stuck with the textures before) but because I didn't know what the best way to get about doing what I wanted to do was.
To solve that, you need a technical specification. The two specs essentially design the program in English, before you get down to translating the program for the computer. So coming up, I'll be making the technical specification for this little program. Not now, though, because it's pretty late.
This is all well and good, and every project should start with something along those lines. However, when I tried to work that out I found myself stuck again. Not due to inability to do something (the way I was stuck with the textures before) but because I didn't know what the best way to get about doing what I wanted to do was.
To solve that, you need a technical specification. The two specs essentially design the program in English, before you get down to translating the program for the computer. So coming up, I'll be making the technical specification for this little program. Not now, though, because it's pretty late.
Friday, May 6, 2011
So Much Noise
I have decided that some of the parts I need for the overall project are modular enough that it may be best to develop them in a stand-alone project before adding them to the larger project.
One such example is the noise function. I am torn between the standard Perlin noise and the improved Simplex noise. Because I'm going to be running it a lot, however, the speed benefits in the Simplex noise is probably best.
The project I'm planning to make will be a single screen with a changing texture, the texture being just two dimensional Simplex noise.
One such example is the noise function. I am torn between the standard Perlin noise and the improved Simplex noise. Because I'm going to be running it a lot, however, the speed benefits in the Simplex noise is probably best.
The project I'm planning to make will be a single screen with a changing texture, the texture being just two dimensional Simplex noise.
Wednesday, May 4, 2011
Stuck on textures
I've been working on creating textures on the fly, instead of reading them from a file. Having issues sticking them on a quad. Not sure what the problem is. Will keep at it until I figure it out.
--
UPDATE
--
Ok, that got fixed. I had to set up some parameters before it would let me get the texture working. So some basic texturing is now in effect. So I can get back to working out how to make noise now.
--
UPDATE
--
Ok, that got fixed. I had to set up some parameters before it would let me get the texture working. So some basic texturing is now in effect. So I can get back to working out how to make noise now.
Subscribe to:
Posts (Atom)