Live data from Hacker News

WebGL Terrain Flyover Demo

zephyrosanemos.com

111–120 of 121 posts

Re: WebGL Terrain Flyover Demo

#111

Out of curiosity, do you use dynamic index buffers to accomplish the geomipmapping, or do you just trample the vertex buffers every frame?

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).

Re: WebGL Terrain Flyover Demo

#112
post #68

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.

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

Re: WebGL Terrain Flyover Demo

#113

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.

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

Re: WebGL Terrain Flyover Demo

#114
post #49
post #8

Earlier quoted context omitted.

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 :)

Woah, I just realized that you draw the entire GUI by yourself. Don't get me wrong, that's pretty awesome in itself, I've done things like that myself. But I'd like to suggest (or perhaps inquire) why you wouldn't just overlay some html?

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!

Re: WebGL Terrain Flyover Demo

#117
post #73

Earlier quoted context omitted.

> depending on who you ask Yeah. Personally, lens flare drives me nuts. It's like instagram - you can show me a perfect picture, but instead you're applying a can't-see-shit filter.

It's actually an interesting debate: is it more believable, from the perspective of immersion, that A) the player is a character actually in the world that they're navigating. or B) that they're controlling a character with a video camera. If you frame it that way, I think B is more believable, because it accounts for the television/monitor, the controller, and the general fact that the player doesn't experience any…

I should have been clearer with my post.

Lens flare in photography and videography tends to be seen as a defect and something to be avoided. That's why lenses have use expensive chemistry for anti-reflective coatings.

When lens flare is used it should be a conscious choice.

Lens flare tends to be reserved for scenes in space. And most of these scenes are not real, but created in a computer, and the flare is added to create "realness". Well, that's fine. Sometimes it works, sometimes it's mocked. ('NEEDS MOAR LENS FLARE' has some useful web search results.)

But, for games, I tend to like lens flare, and it tends to help immersion. (If used carefully.) I have no idea why. It's probably a good idea to allow users to turn it on or off.

Re: WebGL Terrain Flyover Demo

#118
post #73

Earlier quoted context omitted.

> depending on who you ask Yeah. Personally, lens flare drives me nuts. It's like instagram - you can show me a perfect picture, but instead you're applying a can't-see-shit filter.

It's actually an interesting debate: is it more believable, from the perspective of immersion, that A) the player is a character actually in the world that they're navigating. or B) that they're controlling a character with a video camera. If you frame it that way, I think B is more believable, because it accounts for the television/monitor, the controller, and the general fact that the player doesn't experience any…

Interesting point. I would pick B because a game's virtual camera doesn't necessarily stick around in the head of your player avatar the whole game, but can shift behind, beside, overhead it as well as flying around the scene cinematically.

If someone is going to start to nitpick about the unreality of B versus A, then they ought to also address the lack of a dynamic focus and changine depth of field that our visual system handles so automatically that we are unaware that it is even happening and that CG doesn't do this.

Re: WebGL Terrain Flyover Demo

#119

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 cle…

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.

Re: WebGL Terrain Flyover Demo

#120
post #78

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…

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 'flat…

Could you add a cheap procedural function in the rendering pipeline to get more depth variety (past the 255 limit)? You might avoid adding the byte that way, though I'd guess it depends on how much of the pipeline is locked into that limit.
Post reply on HN