Interesting terrain article

@Sploreg and @normen check this out :slight_smile:

This guy did some really interesting things with terrain and published his ideas. Not sure if any of it can be helpful in your work but certainly interesting to read.



http://www.decarpentier.nl/scape-render

1 Like

Wow, he did some Really nice work on that… The video really drives home the difference in speed between doing the calculations on the GPU as opposed to doing it on the CPU.



Though my guess it that he would implement it in OpenCL today, as he alluded to in the article

wow

I really like those editing tools!

It would be nice to push the height editing onto the GPU, CPU terrain editing is always slow.

Well LWJGL’s OpenCL integration definitely works, I did a bit of light tinkering with it this morning after I read that article :smiley:



Yeah his brushes looked really excellent, better than anything I’ve seen quickly done in a typical 3D modeler

Hi! I found this post referring to my article some time back.

Those who found the initial article interesting might also like the two follow-up in-depth articles on that project,

this time focussing on many of its procedural algorithms.



An optimized Perlin noise implementation, and a number of turbulence functions:

http://www.decarpentier.nl/scape-procedural-basics



Two novel algorithms, focussing on generating features typically seen in eroded landscapes:

http://www.decarpentier.nl/scape-procedural-extensions



About whether or not I would prefer OpenCL: Specifically for procedural terrain generation, I don’t think would offer many advantages over good old fashioned pixel shaders. The more complex issues for me had to do with memory management: supporting terrain larger than the max. texture size, building a paging system, supporting multiple undo steps while doing per-page RLE delta compression to save memory, being able to look into neighboring pages from within shaders as a special ‘border area’ case, and much more.

Also, because I needed the data to reside in main memory after being edited for undo purpose anyway, I didn’t mind creating new vertex buffer tiles from that main mem data, instead of doing that part all within video mem. But that choice really had more to do with keeping the minimum specs as low as possible for that project (so, I didn’t want to assume support for reinterpretering data from a rendertarget as a vertexbuffer).

So, using pixel shaders to generate heightfields wasn’t much of a problem, but if OpenCL would be able to improve the efficiency in some of the other areas, you would probably be better of using that (as well).



Regards,

Giliam

4 Likes

Thanks for the details and links Giliam, they are quite informative. Now I know who to talk to when we start implementing more of this stuff :slight_smile:



OpenCL has been thrown around a few times. I haven’t settled on using it yet, there are other areas that I feel need worked on first. But as much info and experience related to it helps with this decision making.



cheers

1 Like