nestoras

When I started development, I didn't know that DOM controls could overlap, let alone lay over a WebGL canvas :) I had zero HTML (and general web development) knowledge at the time. Since I have some experience doing this kind of stuff, instead of diving into the scary DOM details, I took the path of least resistance for me (begun implementing a GUI on a nice, clean drawing surface).

Joking aside, it didn't start as a fully-fledged UI. Some scrolling text strings to show a message log first, the ability to move them out of the way later, then implementing a proper window container for them, then introducing the concept of a 'widget', then getting really excited and thinking about a layout system to be able to present multiple widgets per window... that's the way it usually goes :) The GUI turned out a lot more demanding than the terrain engine itself, both in development time as well as rendering load.

In the end, it's all about learning!

Thank you. You're right, that's how learning is done :)

Thank you! Building a GUI is quite challenging and very interesting as well :)

There is only one vertex buffer per patch that contains all of the vertices. Index buffers are being used, all of them pre-generated of course and uploaded to the graphics card. Rendering a patch then becomes a simple matter of selecting the right index buffer (or index buffers, since stitching requires more than one drawing call).

That was the behavior in the early development stages. I wanted to include both behaviors for educational purposes (it is very instructive to be able to observe what happens when you change the rendering window and how the frustum adapts - or not).

The scaling in frame rate has to do with the amount of terrain patches that have to be displayed. You can see the same scaling by changing the frustum viewing angle (i.e. without resizing the browser window).

Thank you! :)

Very good question! Actually, I can't increase the maximum without going to two bytes per elevation. All of the (top) plateaus are at a height equivalent to 255.

Q: OK, why not put them a bit lower than that, with some variety between peaks?

A: I already have. If you take a closer look, you will notice that there is another layer of flat surfaces, lower than the top.

Q: I'm not convinced. Why only two layers of 'flatness', one at the top, another a bit lower?

A: In the end, it's all about the dynamic range that you have to work with. When using a single byte, there are only 255 distinct height values. The key point is to understand that these values must not differ by much (i.e. they cannot be scaled by large values), since this will affect the appearance of the rest of the terrain (think very, very sharp, unnatural triangles everywhere). On the other hand, the scale factor must be large enough to allow for distinct terrain 'features', avoiding the appearance of a deflated terrain. Two layers of flatness, safely away from each other, was the best compromise.

Q: I'm still not convinced. Just vary the top layer by a small amount between peaks.

A: Using a small value wouldn't make much of a difference. If the amount was large enough, the distinction between the two 'flatness' layers would be lost and the terrain would lose that specific character that it currently has.

Going to two bytes per elevation (and thus be able to use a small scale factor) would allow me to keep the style intact (of some specific geological procedure that has formed the terrain), while varying the peaks and keep the rest of the terrain smooth.

I hope this made some sense. However you're right, it is noticeable! I just didn't think it detracts that much from the overall feel, while it still has advantages, so I went with it.

Does C++ still have endless opening and closing braces? :)

Yes, that has been a feature of the original Pascal design, since the 1970s. Very useful for catching out of range errors.

Yes, they are generated offline. It's the most time consuming step when generating the terrain.

Doing the lighting and shadow generation in real-time (during tile initialization) is a very interesting problem! The great advantage is the bandwidth reduction and the ability to move the sun of course. A Web Worker can (probably should) be used for that purpose. The problem is that in order to correctly light a tile, you need access to its adjacent tiles as well (since peaks near the border on their side may be casting shadows on our tile).

All in all, very interesting and certainly doable!

Thank you! I know what you mean about the fan :)

For learning, you can try game development sites, graphics programming books, online Geomipmapping tutorials (for terrain stuff), forum discussions when facing problems... However, the most important thing is general programming experience, I guess.

I remember though that Learning WebGL (http://learningwebgl.com/blog/) was very useful when I began learning things specifically for the web!

Thank you! Quite frankly, I'm surprised the demo even runs (I don't have a smartphone currently). On what device did you test it?

I agree! Three.js is excellent and already a de facto standard for developing in 3D. However, some points:

1. As the demo stands, it doesn't really need a 3D engine. Including one (any one) wouldn't help with anything, except for maybe skipping some (miniscule) setup code. Surprising, but true. Things definitely change as soon as you wish to render a flying ship though.

2. Learning has been the main reason for this demo. There's no better way to learn than to take apart or build something from scratch. In fact, I've built a 3D engine as well during this time (not used in this demo at all), along with a 3D model viewer and an application I hope to turn into a start-up some day. If I've been developing a 3D game (for example), with the express purpose of releasing it as soon as possible, I'd certainly use Three.js!

And last but not least:

3. When I decided to get into web development, about one and a half years ago, I didn't know about Three.js! :) (I found out quite soon though)

Thank you!

Can't say for sure, because I didn't make it all in one go. The first time I opened the browser with the intent of developing for the web was a year and a half ago. During that time, I've built some other things as well (a 3D graphics engine, a CAD-like 3D model viewer to test the engine with and an application I'd like to turn into a start-up someday :)).

If I had to guess, I'd say that the terrain took me 3 to 4 months, the GUI a bit more than that, plus two more for really polishing the demo. Hard to say though, since everything was done in parallel, with even a few dead periods in-between.

Thank you :) I'm glad that you liked the write-up as well. Yes, I've received many requests for the source code. I'll clean it up and make it public as soon as I find some time.

Thank you! I wish I've been more thorough when I was developing everything and keep a journal. The progression is very interesting. I do have older versions though, I may use them to illustrate some points in future blog posts (when I figure out how to setup a blog :)).

Haha thanks :) I've done these things in the past many times, only on different platforms. The real kudos go to the browser guys (especially at Mozilla and Google) for all the superb work they've done on WebGL and JavaScript in general. Learning JavaScript and some of the intricacies of developing for the web has never been more fun! :)

Thank you. In fact, I may add a ship flying and shooting missiles, as soon as I get some free time. This will require the implementation of a shadow algorithm (you'll need a way to gauge the ship's height) and a particle system (for the smoke trails and explosions). Already done that in an old desktop implementation I've kept somewhere.

A motocross would be slightly more difficult :)

Thank you and I completely agree! I hold VCL especially in very high regard. As for Delphi, I think it doesn't get nearly the mindshare it deserves. As a side note, the CAD software we're making in my company is entirely written in Delphi (with some bits in assembly):

http://www.anadelta.com/index-en.php?s=exported

You may recognize the sky :)

You can accelerate by pressing the down arrow key and even overwhelm the tile prefetcher by pressing the 'O' key and accelerating even further (this is not a very publicized fact due to bandwidth concerns :)).

Thanks for the kind words!

Thank you! I didn't have time to implement image-space occlusion queries, plus I wasn't sure of the level of support they have on mobile hardware (not that this demo will run on anything mobile for the time being :)). I'm shooting a grid of rays through the terrain instead (see relevant screenshots), using various techniques to accelerate that.

The result is used for modulating the intensity of both the lens flares layer and the glare layer.

Nice article!

Thanks CamperBob2! :)

Thank you :) I'll clean it up a bit and make it public soon!

Thank you :)

Thanks :) I had a lot of fun making it!

Thank you :) The technology has matured to such an extent that I think we'll see many great things in the immediate future.

I think it's an issue with hardware acceleration on Linux :(

Thank you! I'm the guy who made it. It's very nice hearing these words from you. I remember checking out your blog many times in the past :)

It's not only the graphics. I am a few years older than the original poster and I very vividly remember the game that blew me away when I was (about) the same age: Thanatos.

http://www.youtube.com/watch?v=zVSSxwXkPjE

This game was simply a masterpiece, in every way. For a 12 year old, it was an unbelievable experience. The graphics were amazing, the animation free-flowing and beautiful, the stage where the drama was unfolding an almost infinite, dark world and the music so much unlike anything else that my trusty Amstrad's little speaker has ever sounded. The whole game had an eerie atmosphere, like a dream. Even the gameplay had original elements: your dragon did not seem to have hit points or an energy bar. Instead, the faster its heart was beating, the closer it was to death. Yet, you never knew exactly how close. Just like real life, that was the point. Being Greek, even the name had an impressive, majestic quality to me: Thanatos (the dragon's name) means Death.

Thanatos managed to create a completely immersive experience (at least to a 12 year old) through graphics, animation, sound, story, atmosphere and gameplay elements.

I clicked reply so that I could tell you that for a moment I envied you. Taking pride in your work while not being too concerned with the clock sounds to me like a perfectly balanced life to pursue.

I take extreme pride in my work and I am always aware of the clock ticking. Every. Second. A wise and accomplished person once said to me that in the end nothing remains but personal relationships. Take good care my friend, lest you lose in the process much more important things in life that you are now enjoying.

People outside the US need an invite for some reason. Can't guess why.