Topic: 3D Procedural Landscape using Canvas

So this is why I was playing with Perlin Noise...

http://lonelypinkelephants.com/random/landscape.html

It requires a browser that supports get/putImageData, though I'll be working on removing that requirement (eventually... using drawImage to make Perlin noise is so elegant). I was surprised that this wasn't hard to do. I'm not much of a 3D guy, but smart people have already done all the math for me, so putting all the pieces together wasn't actually too bad. The hardest parts were figuring out how to distribute polygons efficiently and trying to remember how to scan-convert a polygon. (My implementation of that, by the way, is a complete and utter mess. There has got to be a much cleaner way of doing it.)

The main thing that's killing me are those pesky cracks between polygons. My current plan of attack is to extend the vertex of each triangle away from it's centroid by half a pixel... any better suggestions?

I wonder if it would be possible to interpret google map elevations and make the terrain map.
It would be fun to try.
Maybe do some edge detection, then use the edges to define heights?
Anyway, I've been playing with this for a few days.
Figured I would post it. I can't stop playing with scroller script. all it does is scroll the page based on clicks and mouse moves, but it's so fun. To start the scroll click and hold for a moment, then move your mouse. It stops when you click again.
http://stirfrydesign.110mb.com/javascript/canvas/gmap/CanvasMapWithIsometricViewAndSpinScaleControls.html

The difficulty with using the typical heightmap => polygon mesh scheme is that a grid is actually a terrible way to specify a heightmap if you are looking to use as few polygons as possible (which we are, since Canvas isn't very fast). You also tend to get a lot of distortion that way since we're using affine textures. Going with a equilateral/hex grid minimizes both of those problems, but then you need a new way to generate the heightmap. (In my case, I build the polygon mesh first, convert it into a heightmap, and then use the heightmap to make the texture map.)

You could just use a normal heightmap and sample points in a hexagonal fashion, but you run the risk of "skipping" over mountains, which tends to look weird.

Updated. Now doesn't use any getImageData or putImageData operations, so it's more compatible across a wider range of browsers (including Chrome, in which it is a thing of beauty). It also isn't crippled by Safari/Chrome's horrible image interpolation (as I generate the Perlin noise manually).

Now to fix those accursed seams in everything except Chrome...

Very cool stuff. I know it's not that important but it bugs me that there's some water on the slopes

Cool. Man! I wish I had the time and energy to geek. So many things I want to do.

Iron_wallaby: to tackle the gap between polygons, I usually resort to draw the canvas onto itself and if need be I scale it down a bit or shift it by a pixel here and there and draw in destination-over mode.

Arthurio: heh, yeah. I don't think there's a good way to solve that the way I'm currently doing it. Luckily, the "final" view (for the project I'm toying around with) will be nearly top-down, so that artifact will hopefully not be noticeable.

poi: that is a pretty evil hack, but I can see how it would work. My original idea was to extend the vertices of each polygon away from the polygon's centroid by a pixel or so, but I'm not sure that that would actually solve the problem. I guess I have some experimentation ahead.

(\/)oO(|) ...snap double post

(Edited by poi on 05-20-2009 16:16)

"Extending" the vertices will have the side effect of having the tip of the triangles overlap on sibling triangles.

Ideally we should compute the silouhette of the object and use it as a clip path before drawing the canvas onto itself, but it might be expensive and tricky in the case of concave shapes with intersecting edges.

Well, I've been working on this off and on for the last couple weeks. It's looking much nicer these days (and runs much faster, due to a number of optimizations placed here and there).

http://lonelypinkelephants.com/landscapes.html

It also has some very nice reference functions in the source, for rasterizing a polygon, generating perlin noise (by hand), and the miscellaneous 3D stuff, so it may be worth looking at for those who don't know how to do such things.

Still havn't fixed the seams -- every solution I've tried so far has artifacts that look just about as bad as the seams themselves. I notice that Satoshi Ueyama has made some attempt to use the 2D Canvas as fallback and try the newer 3D things if they exist ( http://gyu.que.jp/jscloth/touch-opera-gecko.html ), but I can't get any of them to work other than the 2D one, so it's probably worth waiting another few months to see if any standardization comes along.

@Arthurio: I've minimized the amount that water creeps up onto the hills (and improved the overall quality of the terrain) by passing the terrain through a "flattening" step: after the terrain is generated, the heightmap is normalized to roughly -1 (deepest ocean) to 1 (tallest mountain). After that, I square the height, which has the benefit of keeping mountains tall but making land near sea level very flat and even. Thus, since terrain near water tends to be flatter, water creeps up the hills less.

(Edited by iron_wallaby on 06-06-2009 23:30)

Very interesting. I wonder if future browsers will make use of hardware acceleration in graphics cards...

----------------------

Without plugins? I wouldn't pretend to know.

As far as HW-acc. web APIs, possible candidates could be Google's O3D, Papervision3D, Sandy3D, Alternativa3D, or Away3d (Flash?). Does anyone know which of these is viable and hardware accelerated? From what I gather, most of these are (or have recently become) open source. I didn't even know the field was so varied.

(Edited by White Hawk on 06-07-2009 13:42)

Of course browsers will use HW acceleration. It's just a matter of time. The BIG problem is how to support multiple platforms and not ditch "older" or less capable platforms without leaving some code to rot or requiring to increase significantly the number of developers in order to maintain multiple rendering pipelines.

My personal opinion is that canvas, java and flash are all we need for interactive web graphics ... and canvas is the least important of them. It's better if the development of this kind of thing is handled by someone other than the browser developer. Keeps it consistent across platforms. Take flash for example, it's quite fast and feature rich despite the lack of serious competition. It works in every major browser and operating system. So despite it's little quirks it's generally a pleasure to develop. Contrary to canvas, js in general and html that are a major pain in the ass because all the implementations are different.

I tend to disagree. Java is too heavyweight to be useful a lot of the time (though it's feature set makes it awesome it certain cases), and if you think Flash is well supported everywhere, Linux would like to have a word with you. (It's better than it was a year or two ago, but it's still pretty horrifying.)

Linux is actually a big sticking point for me, since I use it (most of the time) myself, and netbooks are using it with increasing frequency.

Additionally, if you ignore MSIE, JS and HTML are pretty consistent and easy to work with. Besides, it's very easy to make fallback content in MSIE.