Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGL Terrain Flyover Demo

zephyrosanemos.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: WebGL Terrain Flyover Demo

#101

Post by jakejake »

nestoras wrote: post #66
jakejake wrote: post #61

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?

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

Cool thanks so much!

Re: WebGL Terrain Flyover Demo

#103

Post by snogglethorpe »

dualogy wrote: post #100
snogglethorpe wrote: post #99

Earlier quoted context omitted.

> > the colon vastly improves readability > We have gofmt for that :) Er, what? gofmt doesn't improve the readability of declarations at all... [there's really not much it can do]

It spaces them evenly if you have multiple subsequent lines of them. Readable enough: var ( i, j int foobarStuff string bebop bool ) What's not readable?

Er, ok, it can slightly mitigate the problem in a few cases. Even to the extent that it work though, this is a very fragile "solution" — (1) declarations often occur alone, (2) multiple declarations can have similarly sized variables, meaning there's no big whitespace chunk to act as a separator, and (3) one shouldn't have to run one's code through a code formatter, or use awkward formatting practices, to get basic readability....

Simply following standard practice (over decades), and including a colon, on the other hand, would have made all declarations more readable, and be more familiar, for no real cost.

Really, some of Go's syntax decisions are completely baffling...

[Sure there are lots of crazy computer languages around, but these guys really should have known better—and anything they do is much more likely to have an impact than most random languages, so it'd be nice if they could take a bit more care...]

Re: WebGL Terrain Flyover Demo

#104

Post by BHSPitMonkey »

lalc wrote: 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…

I felt the resulting plateaus were nice, though I'll admit it's a tad distracting that they're all the same height.

Re: WebGL Terrain Flyover Demo

#105

Post by nestoras »

Tloewald wrote: post #72
nestoras wrote: post #38

Earlier quoted context omitted.

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

Not discussion that I can see of your rendering techniques. Are your shadows baked?

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!

Re: WebGL Terrain Flyover Demo

#106

Post by nestoras »

jevinskie wrote: post #85
networked wrote: post #28

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…

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.

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

Re: WebGL Terrain Flyover Demo

#107

Post by nestoras »

rorrr wrote: post #84
networked wrote: post #28

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…

I used to write Pascal a decade ago. Does it still have endless begin-end statements?

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

Re: WebGL Terrain Flyover Demo

#109

Post by nestoras »

lalc wrote: 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 '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.

Re: WebGL Terrain Flyover Demo

#110

Post by nestoras »

grannyg00se wrote: post #93

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

Thank you! :)

Post reply on HN