In my research into rivers, I’ve found another option that’s yielding interesting results: use pathfinding…
Basically, I just identify a source for the river and then try to leave the map area, weighing the results like in pathfinding (for example, better cost for downhill)…
The results are much better than the previous system:
Then I took a long time to add some code to merge the rivers that cross and increase the width:
I haven’t flattened the river yet, that’s the next step… I also want to add a poligonal object on top to create something like water flow, but that’s the last thing…
One of the challenges with this approach though is to create actual lakes, but I’ll get to that after I flatten the river…
Now listening to “Shatter Me” by “Lindsey Stirling”
Today I did a lot more water experiments, trying out different ways to make the rivers…
The results weren’t very good… Either I have very short rivers (because the water doesn’t have anywhere to go) or I have flooding (the most common result):
I’ve even tried approaching it based on sedimentation and erosion, but the results seems very unpredictable and not too fun…
Of course, I can go back to the initial approach, which is to draw a line through the map, using some better rules for it than I currently do to fix the existing problems, but it also seems like an ugly hack…
Think I have to go back to the drawing board and study how everyone else is doing rivers…
Now listening to “Black Sails at Midnight” by “Alestorm”
I’m trying out using a cellular automata in creating the river courses…
The results work great to make lakes, but not rivers:
Here you can see the iterations of the automata:
The problem it seems to be that the current algorithm checks for each grid element if a neighbor has water in it, and if it is higher, and it fills the current one with water if that’s the case, but in most cases, that creates the effect you’re seeing, instead of a river, since it’s likely that a lot of grid blocks have the same height around a water element, instead of creating a sort of “river bed”.
I can see two ways to fix this: one is not to use the cellular automata, and use a more direct approach: for each water block, check the lowest neighbor and walk that way, and repeat the process.
Another way is to actually dig a trench. So when I place a water element, I dig it down a bit so that it’s the lowest element in the direct vicinity, and move forward with that…
Going to try these tomorrow!
Now listening to “Pristine in Bondage” by “Amaran”
Started work on the new river system…
The current rivers are just a line lowering the terrain and replacing the voxel material:
It has a lot of bugs (floating rivers, but that could be sorted), but it’s impossible to animate (especially because it doesn’t have an actual direction) and it doesn’t actually look like a river (too regular).
So now I’m working on a new system for this.
My idea is to work a bit more like nature: find a high spot and make water flow down… When the water can’t flow down more, create a lake, and start making new rivers from there… That will probably create more natural looking planets (hopefully). The problem is making the lake not take over the whole map (which would be possible in some circumstances).
Today I started with the code for this, hopefully tomorrow I’ll be able to start the first tests…
Now listening to “The Metal Opera” by “Avantasia”
Link of the Day: For me, the best graphical adventures in the last few years were the ones from Wadjet Eye Games, excellent retro style and great writing… The new one is shaping up to be another amazing one:
Today it was bug-fixing time…
First bug was an old one that was annoying me, even if it was simple to solve: the screen would turn purple on transition between areas…
The second bug was the normals on the objects… For imported objects, I’m using the 3ds format (because it was simple and I already had a function to load them), but the 3ds format doesn’t store normals, so they have to be computed after importing…
What I was doing so far was building smooth normals: assume all points that share a (X,Y,Z) are the exact same point and as such they should share the normal and should be smooth along the surface…
This would lead to weird results in stuff that should be more “straight” in nature, by smoothing stuff that should be flat:
You can see that on the console and especially in the “power generators”…
Now I’ve added a tolerance factor, which basically makes all adjacent triangles that differ by less than the tolerance angle to be treated as continuous…
Below you can see the effect with the new normal generation:
Much more accurate and in line with what I actually want from the system in visual terms…
Now listening to “Red Shift” by “Asgaroth”
Link of the Day: The game doesn’t seem much like my thing, but the graphical style is amazing!
Today I worked on some bug fixing and optimization, namely on the voxel raycasting… I already suspected that my raycasting function was a bit iffy and missed some intersections, but today I got to confirm that and to fix it, while optimizing it a lot…
So yesterday, while in debug mode, the game would drop to 20-30 FPS while raycasting two or three shots, today it doesn’t even change the frame rate…
I’m counting this one as an optimization, so next step is to fix a bug so I can move to another polish item!
Now listening to “Valley of the Damned” by “Dragonforce”
After a long time (too long, really), finally got the OpenGL decals working…
The problem ended up being something quite simple: in the Direct3D pipeline I was storing the W value for depth, while on OpenGL I was storing the Z value… Although the two values are quite similar in my test scenes, they’re different enough that it would cause the system not to work properly…
Up next: a bit of optimization and some bug fixing before going back to some more polish! 
Now listening to “Damnation and a Day” by “Cradle of Filth”
Still in the middle of a massive flu, which might explain the fact that I can’t get decals to work on OpenGL…
They almost work, but there’s something wrong somewhere, and I can’t figure out where!
They only display if I remove one of the box checks (the Y axis), so my guess is that somewhere a Y coordinate is not being correctly computed… It’s not the “screen to real world coordinate”, because I did a series of checks on that and it’s being correctly computed for sure…
So it must be one of the transforms (the primary box axis or the secondary ones, or the center maybe), but I don’t even know how to test that… 
Oh well, maybe tomorrow I’ll have a new pair of eyes… 
Now listening to “Youthanasia” by “Megadeth”
I’m in the grip of a massive flu, so just some minor writing, proof-reading and other stuff I can do on my laptop… Hopefully tomorrow I’ll be back to normal coding… #nobreaksforindydevs
Now listening to my own breathing sounding like Darth Vader
Old version:
New version:
Way better, no?!
In movement is looks even better… I think I can even improve the effect more, making it branch out on some points, but I’ll leave that for another day…
Only the OpenGL version of the decals missing and I can move on to the next task… As I decided before, the next one has to be a bug, and I have to tackle an optimization as well before going back to a polish task…
Now listening to “Siren Charms” by “In Flames”
