Tell HN: My 3D terrain in Flash just went online

Ooh you're lucky. The inspiration for my previous "fun" project, openphotovr.org, came after I visited Barcelona and saw Sagrada Familia. Here it is: http://openphotovr.org/view.html#a57 :-)

Thanks! I think I fixed it. Clear your cache and try again.

Good suggestion. Done!

It's deliberate. I believe pg said it's to stop people effectively giving themselves the top comment on a link. Which is exactly what the submitter is trying to do here. Of course, he's the author of the link so it's fair enough. I guess pg would want him to add his comment like everyone else; or put the comment on the webpage itself; or put up with a unlinkified url.

Personally, I think it's a bit of overkill for a specific problem (and I don't know if it actually occurred in practice, or it was only predicted that it would occur). Maybe the HN community can be trusted to not abuse linkified links? OTOH, it's an extremely minor niggle, and I agree that pg's time is better spent on preventing spam and keeping the community civil etc. That's way more important.

Meta-discussion like this is frowned upon, but I wanted to answer your question and also offer a solution: I solve this problem with a customable dictionary lookup addon for firefox, by adding a rule that just opens the highlighted string directly. I come across unlinkified URLs quite often.

Nope. I don't adapt the mesh from frame to frame, I rebuild it completely on every frame. That's the first half of the "msec" diagnostic, so you can see I optimized that part quite a bit. The general idea (bintrees of right triangles, splitting based on screen-space error) is indeed taken from the ROAM paper, but everything else from that paper I threw away and made up my own algos.

Game developers today can afford to draw millions of triangles per frame running their terrain engines on their fast GPUs. Flash can't use GPU rasterization yet, so I had to use exceptional cleverness to fit in the budget of 1-2 thousand triangles per frame without visible popping. Maybe this could be useful for Flash games, though.

The intermediate steps of development were as follows:

1. Draw a big rectangle of flat-shaded ground (no textures, no heightmaps) tiled into triangles of equal size. Mouse navigation to fly over it.

2. Move the vertices vertically according to a formula - a procedural heightmap - e.g. a sine wave.

3. Add subdivision of triangles into smaller triangles as needed, like in ROAM (http://www.llnl.gov/graphics/ROAM/roam.pdf).

4. Solve hidden surface removal. This is easy because the triangles form a bintree-like structure, treat it as a BSP and draw back to front.

5. Implement loading of texture tiles. (Do you have those?) The scale of the texture to load for each triangle depends on its transformed Z value.

6. Implement loading of heightmaps in your preferred format.

7. Debug, optimize, debug, optimize, debug, optimize.

Maybe we will move in that direction, but I'm not sure. That depends on what our customers will want.

Thanks! I looked at the control schemes of all popular 3D maps and decided to make something better :-) It helps that terrain, unlike 2D map data, has a certain natural scale, so tilt can be tied to camera altitude.

Yep, seems to be a hole in our SRTM dataset. Such things happen. I'd certainly like a better dataset, because the current one is cut off at 60N and excludes a huge part of Russia.

Don't have access to such a system. Will fix if you tell me how.

I can confirm it. 64bit system, 64bit flash and browser. Don't know how to help though

Yes, I did an experiment with a uniform mesh about a month ago. It turned out to be a choice between awful detail level, miniscule view distance or unusably slow framerate, so I abandoned it after a day. But it was a useful experiment because it really made me understand my triangle budget.

I do have a large background in computer graphics. If I lost the knowledge and had to reconstruct it again, I would begin by writing simple demos in the lowest level environment I could find. Forget Papervision, try making a spinning textured cube by assigning colors to individual pixels using C code. This way you pick up the background awfully fast.

I'd certainly like to, but this was developed for my employer and would have to be cleared through them. Me and one other guy are trying to make the place more open source friendly, but it's slow.

I don't know much about world generation, but the commercial product Terragen looks pretty damn good. Are you trying to solve the same problem?

Yep, I've read that paper. What I did was actually simpler than any paper I've seen, so I will just describe it here.

The basic data structure is taken from ROAM: a bintree of right triangles. It is regenenerated from scratch on every frame, recursively, starting from several top-level triangles. (So it's technically a multi-tree, I guess.) A triangle is split if the midpoint of the hypotenuse has a screen-space error of more than 10 pixels. Each triangle knows its children and neighbors, so each split can cause neighboring triangles to split to avoid T-junctions. (This was by far the trickiest part of the code, similar in difficulty to balancing a red-black tree.) I also take many not-quite-correct shortcuts, like stopping the splitting process if the triangle lies completely behind the camera or outside the screen bounds.

I believe the main reason my engine looks so good is because it uses satellite photos for textures - they hint at a lot of 3D detail that isn't expressed by the triangles. I render only 1 or 2 thousand triangles per frame, but they pretend to be a lot more, if you don't look at the ridges too closely. Try the m and i keys to look under the hood.