I decided that since I had accomplished so much by pretty much working non-stop for almost a month, I was going to take a break for a bit. So, I have not worked on my procedural planet for this past week. Of course, I could never really break myself away from it, so I have been reading books and websites to research the next phase. I even put together an HLSL project to do some experimentation. So, don't worry, progress is still being made, just at a much slower rate now. I'm guessing I will start working on it again this week. After I get my new laptop (sometime after the 28th) I'm hoping to really pick up the pace again. Although, I do have a word of warning: I may get distracted with DirectX 10 and Geometry Shaders. We shall see. (Not to mention that Too Human comes out on Tuesday, Tales of Vesperia next week, Infinite Undiscovery the week after, and Spore the week after that! Too many good games coming out so soon.)
Until next time.
Following my adventures in various graphics projects. These mainly consist of procedural development, image processing, and physics.
Sunday, August 17, 2008
Sunday, August 10, 2008
Success!
I have completed the items on my to-do list!
I finally stopped the terrain from disappearing (for the most part ... I still had two instances where it happened). I discovered that I had a key subtraction backwards. How it even worked at all before, I will never know.
I got each terrain level to move at its own stepping distance by storing and updating a world matrix for each level. Luckily my CPU was hardly being used at all so I could easily spare the CPU cycles to do these extra calculations.
I fixed the gap between separate levels by simply making the square mesh slightly larger. Previously, the mesh would extend from (-1, -1) to (1, 1), but I updated it so that the range is (-1.25, -1.25) to (1.25, 1.25).
Now for what you've been waiting for: a new video. In fact this time I have two new videos for your enjoyment. One showing off the new terrain, and another showing it in wireframe mode.
Normal Terrain:
Wireframe:
On a separate note I just ordered a new laptop, so I will finally be able to do development on my laptop again. My current laptop only has a GeForce 6100, so it couldn't handle my shaders anymore (no unified pipeline). My new laptop has a GeForce 9800 GT which is about 20 times faster than my current GPU. It will be awesome!
I finally stopped the terrain from disappearing (for the most part ... I still had two instances where it happened). I discovered that I had a key subtraction backwards. How it even worked at all before, I will never know.
I got each terrain level to move at its own stepping distance by storing and updating a world matrix for each level. Luckily my CPU was hardly being used at all so I could easily spare the CPU cycles to do these extra calculations.
I fixed the gap between separate levels by simply making the square mesh slightly larger. Previously, the mesh would extend from (-1, -1) to (1, 1), but I updated it so that the range is (-1.25, -1.25) to (1.25, 1.25).
Now for what you've been waiting for: a new video. In fact this time I have two new videos for your enjoyment. One showing off the new terrain, and another showing it in wireframe mode.
Normal Terrain:
Wireframe:
On a separate note I just ordered a new laptop, so I will finally be able to do development on my laptop again. My current laptop only has a GeForce 6100, so it couldn't handle my shaders anymore (no unified pipeline). My new laptop has a GeForce 9800 GT which is about 20 times faster than my current GPU. It will be awesome!
Friday, August 8, 2008
Huh?
Well I beat Braid last night. I think it took me about 6 hours total to beat it. It's a very good game and I highly recommend it. That is, if you enjoy "action puzzle" type games (think along the lines of Portal). There are 60 puzzles in the game and I was able to do 59 of them myself. I couldn't figure out one of them and I tried it for an hour. I finally looked online and I learned about a dynamic of the game that I wasn't even aware of.
I had read a posting on the XNA forums about how matrix transformations can cause slight errors over time, so I added code after my transformations to renormalize the vectors and even recalculate the cross products in order to maintain orthogonality. However, when I fired up the program, the terrain was disappearing even more! The angle between the two vectors is still randomly coming up as NaN and Pi.
Sigh, well I guess I know what I'm working on this weekend.
I had read a posting on the XNA forums about how matrix transformations can cause slight errors over time, so I added code after my transformations to renormalize the vectors and even recalculate the cross products in order to maintain orthogonality. However, when I fired up the program, the terrain was disappearing even more! The angle between the two vectors is still randomly coming up as NaN and Pi.
Sigh, well I guess I know what I'm working on this weekend.
Thursday, August 7, 2008
To-Do List
Here is a list of things that I want to get working before I create the next video:
- Fix disappearing terrain
- Make each level move at it's own step size (right now they all move at the smallest step size)
- Fix gaps between changing detail levels (you can see the gaps in the last screenshot I posted)
As for the disappearing terrain, in my previous post you will see that I've narrowed the problem down to the angle calculation. I've read the documentation on acos() and it says that NaN is returned as a result if the input parameter is < -1 or > +1. I'm passing in the dot product of what should be two normal vectors, thus the input should never exceed 1. Apparently I'm not sending in true normal vectors, so I'm going to add more normalization calculations, just to make sure they are coming out normal. That should remove the NaN results, but hopefully it fixes the Pi results as well. (I'm crossing my fingers tightly.)
I'll give it a try when I get home.
- Fix disappearing terrain
- Make each level move at it's own step size (right now they all move at the smallest step size)
- Fix gaps between changing detail levels (you can see the gaps in the last screenshot I posted)
As for the disappearing terrain, in my previous post you will see that I've narrowed the problem down to the angle calculation. I've read the documentation on acos() and it says that NaN is returned as a result if the input parameter is < -1 or > +1. I'm passing in the dot product of what should be two normal vectors, thus the input should never exceed 1. Apparently I'm not sending in true normal vectors, so I'm going to add more normalization calculations, just to make sure they are coming out normal. That should remove the NaN results, but hopefully it fixes the Pi results as well. (I'm crossing my fingers tightly.)
I'll give it a try when I get home.
Wednesday, August 6, 2008
No real progress
I have been busy playing Braid, which is a great game that just got released on the Xbox Live Arcade. Therefore, I haven't really put much time into the procedural planet.
I did put in some code that would always display the calculated angle between the camera and the terrain mesh in order to see if that was causing the disappearing errors. I actually believe it is, although I'm not quite sure why.
First, I was surprised to see that probably a quarter of the time, the result was NaN. Even more surprising is that my terrain works perfectly even when the result is NaN.
The errors occur when the result suddenly comes back as pi randomly. I should never be getting an angle that big back. Heck I shouldn't ever be getting pi/2.
I will continue to investigate this problem (when I have time between Braid of course).
I did put in some code that would always display the calculated angle between the camera and the terrain mesh in order to see if that was causing the disappearing errors. I actually believe it is, although I'm not quite sure why.
First, I was surprised to see that probably a quarter of the time, the result was NaN. Even more surprising is that my terrain works perfectly even when the result is NaN.
The errors occur when the result suddenly comes back as pi randomly. I should never be getting an angle that big back. Heck I shouldn't ever be getting pi/2.
I will continue to investigate this problem (when I have time between Braid of course).
Monday, August 4, 2008
Nothing is easy
I thought that my camera was moving way too slowly after I increased the size to 6.5 million meters, so I increased its default speed. I also have a couple of keys that act as multipliers in order to get really high speeds. Unfortunately I realized that my terrain couldn't keep up with me because I was moving too fast. This is because the terrain would only move a maximum of 1 step each loop. So, if I traveled 3 steps' distance in one update loop, the terrain would fall 2 steps behind.
I wrote a solution to this by calculating the number of steps the camera has moved and then rotate the terrain the appropriate number of steps. This worked great and the terrain always kept up with the camera. BUT! Yes, the big dreaded but. The terrain randomly disappears. It will be fine for quite a while and then flash on and off like crazy. Even worse, sometimes it completely disappears and doesn't return, no matter which way I turn or move.
I have no idea what is causing this problem and I have tried debugging the code for awhile now. So either I find a fix to this bug, or I'll have to limit the speed to be slow enough that the terrain can keep up.
I feel bad for not having any media for so long, so here is a screenshot to appease the horde. I desperately need to get better texturing on the terrain, but that will come after I get the terrain working to my satisfaction.
I wrote a solution to this by calculating the number of steps the camera has moved and then rotate the terrain the appropriate number of steps. This worked great and the terrain always kept up with the camera. BUT! Yes, the big dreaded but. The terrain randomly disappears. It will be fine for quite a while and then flash on and off like crazy. Even worse, sometimes it completely disappears and doesn't return, no matter which way I turn or move.
I have no idea what is causing this problem and I have tried debugging the code for awhile now. So either I find a fix to this bug, or I'll have to limit the speed to be slow enough that the terrain can keep up.
I feel bad for not having any media for so long, so here is a screenshot to appease the horde. I desperately need to get better texturing on the terrain, but that will come after I get the terrain working to my satisfaction.
Saturday, August 2, 2008
Everything revolves around the camera
Well I fixed the problems I was having with the camera. First, let me explain why I was having trouble. I had my planet centered at the origin (0,0,0) and I gave it a radius of about 6.5 million meters. I initialized the camera position to be right at ground level of the planet (6.5 million meters plus the height of the tallest mountain [I use 100,000 meters]). My camera always looks at a spot 1 meter in front of its position. Once you are dealing with positions up in the millions (about 6.6 million), the accuracy is lost and so it doesn't always register that 1 meter difference.
I found an article online where someone was having similar issues with having the sun at the origin and having the camera out at Earth's distance (about 150 billion meters = 1 AU). He fixed the problem by always making the camera situated at the origin and just positioning all objects based on the camera position. I thought I would give that a try.
I didn't have translation code for my planet yet, so I had to first write that and get it debugged. Once I had that working, it was pretty simple to switch the coordinates around (I added 2 lines of code and commented 1 out). Now my camera works perfectly even when dealing with a planet with a radius of 6.5 million.
I also managed to tweak the Z-fighting occuring with the depth buffer. So it looks alot better than what it did, but it's still not perfect and there are still triangles fighting with each other on the horizon. As soon as I have that fixed, I'll post some more screenshots.
I found an article online where someone was having similar issues with having the sun at the origin and having the camera out at Earth's distance (about 150 billion meters = 1 AU). He fixed the problem by always making the camera situated at the origin and just positioning all objects based on the camera position. I thought I would give that a try.
I didn't have translation code for my planet yet, so I had to first write that and get it debugged. Once I had that working, it was pretty simple to switch the coordinates around (I added 2 lines of code and commented 1 out). Now my camera works perfectly even when dealing with a planet with a radius of 6.5 million.
I also managed to tweak the Z-fighting occuring with the depth buffer. So it looks alot better than what it did, but it's still not perfect and there are still triangles fighting with each other on the horizon. As soon as I have that fixed, I'll post some more screenshots.
Subscribe to:
Posts (Atom)