"When I tried to think of a project suitable for learning JavaScript, a terrain flyover demo came to mind."
Me too! But then I re-establish contact with the reality of my actual abilities and create a button which, when pressed, prints "Hello, world!" to an alert window.
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! :)
Cool demo. What caught my attention was this line in the description:
>The terrain is procedural, generated offline by a Delphi program (Delphi is a modern version of Pascal).
Nowadays I very rarely see new projects use Object Pascal or Delphi. This is somewhat disappointing since I think it really is a fine language that could be a viable alternative to C++ and Java due to its combination of high performance and clean syntax [1]. But then again, C# is very popular and it is pretty much the new Delphi.
Does anyone here use Object Pascal in their current projects?
[1] At least in theory. I'm not necessarily talking about the particulars of the Borland/CodeGear/Embarcadero implementation since Anders Hejlsberg left for Microsoft, which were not always perfect.
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):
I used Delphi for a 16-bit Windows game ages ago. However I skipped all of the UI builder stuff (which is the primary reason you'd want to use it in the first place) and coded directly against the Windows API, with the help of some inline asm.
So why not just use C? There were good reasons. In 1992 C/C++ compilers on the PC were slow -- pre-compiled headers were still mysterious -- and Delphi's handwritten compiler and integrated linker made the edit/compile/run cycle very very fast. It made small, fast, completely stand-alone (no MSVCRT.DLL or anything) binaries -- a feature which still supposedly makes it popular with malware authors.
The UI builder was excellent and perfect for knocking off one-off tools like the terrain generator described above. As long as you stuck to Windows, of course.
I don't know if I would necessarily go back though. While I sometimes miss some of Pascal's features like ranged types and sets (and bounds checking on arrays) the performance advantages of the specific Borland implementation have become less important, and there are other contenders that cover a bigger problem space than the delta between Pascal and C.
I think there's a lot of low profile software out there written in Delphi which doesn't get mentioned because it's not a reason to buy, and may be a reason not to buy. There's a nice windows installer tool I occasionally use written in Delphi.
I was very impressed when I found out that Pascal supports subrange types (that is types with custom, user-defined ranges). I had only seen it in VHDL / Ada before, where I found it to be very useful.
After using Delphi professionally for some years, I pretty much hated it. Some of my least favorite features are automatic and locale-dependent string/WideString conversions, and that there are multiple memory models: interfaces (IUnknown) uses reference counting, TComponent is owner-based, and lots of other classes require manual memory management.
On the other hand, the object system has some nice features. I miss AfterConstruction and BeforeDestruction in other languages, and I like virtual constructors.
I did a course on object pascal in 2002 (just before that college, like many others, switched to java). A few months ago, I had a look at Ada, and found it pleasantly similar to object pascal. If you've played with pascal, but not with Ada, I recommend having a look :-) Eg:
This looks great and that is a huge amount of effort. I have to ask about what I think is the elephant in the room: Surely you must have noticed that all your mountains are chopped off at the exact same altitude? Wouldn't the scene look way better if you just increased the maximum, with basically no effort?
It's as though you spent a month painstakingly mixing 64 channels of crystal clear audio, but, right at the end, threw your hands up and clipped the final mix into oblivion.
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.
FYI, directly working with WebGL code is painful just because of the amount of basic infrastructure that has to be built before anything can be done. I strongly suggest using an existing framework like three.js as a starting point and going from there. Three.js is complete enough that a basic scene can be created quickly and extensible enough that complex scenes and shading can be created by extending it with custom objects.
For example, I was working on creating a WebGL setup for playing around with the Oculus Rift and used three.js to create http://sxp.me/rift/. It's mostly three.js code, but I added a custom camera object which handles the offscreen rendering and distortion required for the Rift. It was much faster and easier than starting from scratch which was what I originally did before giving up.
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)
That looks really nice. A lot of WebGL demos these days don't really show the full extend of what WebGL can do, so to my eyes it's basically equivalent to something like VRML (anyone remember that?). Of course WebGL/OpenGL and VRML are totally different but you get the idea. Yeah I know there's stuff like Quake in WebGL but it's not really the same thing, because Quake was designed for lesser powered machines.
I'm still waiting for someone to make a fully fledged game in WebGL because I can totally see it happening.
Looks nice but runs at awfully slow 4-5 fps on my Ubuntu 64bit system. Is Radeon HD 4200 to weak for WebGL or is there something you need to configure?
Sounds about right. I get up to 11 fps on Ubuntu 64bit on an AMD E-350/Radeon HD 6310 system fullscreen on 1366x768 with the catalyst drivers and hidden GUI and a quick search for benchmarks seems to indicate that it is about twice as fast as the HD 4200 ( http://www.notebookcheck.com/ATI-Radeon-HD-4200.20492.0.html ). You may get a few fps by switching to the proprietary drivers if you do not yet use them, but I wouldn't expect wonders.
[Edit:] And I see up to 13 fps if I fly away from the sun, the author seems to be right when he writes "Calculating sun visibility the geometric way (by casting rays through the terrain and the clouds) can be expensive if not done carefully."
Runs well on my machine (32-bit Ubuntu, NVidia drivers, Firefox). You shouldn't need to configure anything for it to be fast in general (if it's blacklisted, it won't run at all), but non-NVidia drivers on Linux can be slower in some cases. Do other WebGL demos run ok for you?
Gentoo 64-bit here, Radeon HD 4350 and managed to get 20-30 fps depending. (git versions of Mesa, libdrm, xf86-video-ati, and a recent kernel, all of which are probably required to get best HW rendering, unfortunately).
60 FPS here, Ubuntu 64, nVidia GTX 660. Cool demo, thanks. For most people though I doubt they will have good video hardware so I think 3D in the browser is still several years of for the everyday user.
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.
Outstanding work.
I noticed that resizing my browser window actually changes my view portal size. I expected it to keep the same portal resolution but shrink/stretch/distort the view as I resized the browser. I'm not sure what the implications are, but it was a fun surprise. I also noticed that the framerate scales very nicely with the changing portal view resolution as I resize the browser. Very impressive.
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).
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).
Every time I click on a WebGL demo I think to myself... here comes my CPU fan and my lap is about to get hot! Seriously though, this demo makes me realize how much programming knowledge I lack. It it totally fascinating. Where would be a good place to start learning this type of programming?
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!
That's very cool. Nicely polished, that's a lot of hard work and effort. Congrats!
I can relate to your story of building the UI framework yourself. That's kinda what I ended up doing myself too, and I've learned a lot of fundamentals through that approach.
Let me take this opportunity to plug a 3D terrain I made in Flash about three years ago: http://kosmosnimki.ru/3d. It uses actual satellite images and heightmaps.
Incredibly impressive. I, like you, began my first endeavor into learning JS by building a GUI. Unlike you, my resulting product was ugly as sin. This is seriously awesome work.
[+] [-] sramsay|13 years ago|reply
Me too! But then I re-establish contact with the reality of my actual abilities and create a button which, when pressed, prints "Hello, world!" to an alert window.
[+] [-] nestoras|13 years ago|reply
[+] [-] networked|13 years ago|reply
>The terrain is procedural, generated offline by a Delphi program (Delphi is a modern version of Pascal).
Nowadays I very rarely see new projects use Object Pascal or Delphi. This is somewhat disappointing since I think it really is a fine language that could be a viable alternative to C++ and Java due to its combination of high performance and clean syntax [1]. But then again, C# is very popular and it is pretty much the new Delphi.
Does anyone here use Object Pascal in their current projects?
[1] At least in theory. I'm not necessarily talking about the particulars of the Borland/CodeGear/Embarcadero implementation since Anders Hejlsberg left for Microsoft, which were not always perfect.
[+] [-] nestoras|13 years ago|reply
http://www.anadelta.com/index-en.php?s=exported
You may recognize the sky :)
[+] [-] sehugg|13 years ago|reply
So why not just use C? There were good reasons. In 1992 C/C++ compilers on the PC were slow -- pre-compiled headers were still mysterious -- and Delphi's handwritten compiler and integrated linker made the edit/compile/run cycle very very fast. It made small, fast, completely stand-alone (no MSVCRT.DLL or anything) binaries -- a feature which still supposedly makes it popular with malware authors.
The UI builder was excellent and perfect for knocking off one-off tools like the terrain generator described above. As long as you stuck to Windows, of course.
I don't know if I would necessarily go back though. While I sometimes miss some of Pascal's features like ranged types and sets (and bounds checking on arrays) the performance advantages of the specific Borland implementation have become less important, and there are other contenders that cover a bigger problem space than the delta between Pascal and C.
BTW, here's where Google Trends says Delphi is popular nowadays: http://www.google.com/trends/explore#q=delphi&cmpt=q
[+] [-] Tloewald|13 years ago|reply
[+] [-] jevinskie|13 years ago|reply
[+] [-] knutae|13 years ago|reply
On the other hand, the object system has some nice features. I miss AfterConstruction and BeforeDestruction in other languages, and I like virtual constructors.
[+] [-] e12e|13 years ago|reply
http://blogs.fsfe.org/thomaslocke/2013/02/10/using-the-ada-w...
[+] [-] aubergene|13 years ago|reply
[+] [-] rorrr|13 years ago|reply
[+] [-] lalc|13 years ago|reply
It's as though you spent a month painstakingly mixing 64 channels of crystal clear audio, but, right at the end, threw your hands up and clipped the final mix into oblivion.
[+] [-] nestoras|13 years ago|reply
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.
[+] [-] BHSPitMonkey|13 years ago|reply
[+] [-] sxp|13 years ago|reply
For example, I was working on creating a WebGL setup for playing around with the Oculus Rift and used three.js to create http://sxp.me/rift/. It's mostly three.js code, but I added a custom camera object which handles the offscreen rendering and distortion required for the Rift. It was much faster and easier than starting from scratch which was what I originally did before giving up.
[+] [-] nestoras|13 years ago|reply
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)
[+] [-] mcmire|13 years ago|reply
I'm still waiting for someone to make a fully fledged game in WebGL because I can totally see it happening.
[+] [-] Aurel1us|13 years ago|reply
Very impressive!
[+] [-] bjourne|13 years ago|reply
[+] [-] fhars|13 years ago|reply
[Edit:] And I see up to 13 fps if I fly away from the sun, the author seems to be right when he writes "Calculating sun visibility the geometric way (by casting rays through the terrain and the clouds) can be expensive if not done carefully."
[+] [-] nestoras|13 years ago|reply
[+] [-] mbell|13 years ago|reply
[+] [-] azakai|13 years ago|reply
[+] [-] mpyne|13 years ago|reply
[+] [-] jebblue|13 years ago|reply
[+] [-] teamonkey|13 years ago|reply
[+] [-] nickpresta|13 years ago|reply
http://i.imgur.com/F04X6D8.jpg
[+] [-] daenz|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
The result is used for modulating the intensity of both the lens flares layer and the glare layer.
Nice article!
[+] [-] DanBC|13 years ago|reply
wait, what? Lens flare is not common in photography.
[+] [-] grannyg00se|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
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! :)
[+] [-] angersock|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
[+] [-] shanelja|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
[+] [-] kurd_debuggr|13 years ago|reply
[+] [-] th0ma5|13 years ago|reply
[+] [-] pyalot2|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
[+] [-] jakejake|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
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!
[+] [-] suprfsat|13 years ago|reply
[deleted]
[+] [-] shurcooL|13 years ago|reply
I can relate to your story of building the UI framework yourself. That's kinda what I ended up doing myself too, and I've learned a lot of fundamentals through that approach.
[+] [-] nestoras|13 years ago|reply
[+] [-] cousin_it|13 years ago|reply
[+] [-] satori99|13 years ago|reply
Is there a reason you decided to implement a WebGL UI, instead of using HTML for the user interface elements?
Is native browser compositing too slow with multiple HTML elements on top of the WebGL canvas?
[+] [-] ntaylor|13 years ago|reply
[+] [-] nestoras|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]