[Up! (Part 1)]

Great, looking forward to your feedback!

[Patchwork]

Thanks, Aggror - nothing compared to your tutorials, of course...

[Patchwork]

Oh, cool, didn't know that - thanks!

[Large-scale terrain algorithms]

Hi shadmar, thanks for the link. I've actually stumbled acros that site a couple of weeks ago - pretty niice stuff! Is it really WebGL, though? I thought that is comparable in functionality to OpenGL ES 2? The shader-based terrain generator is pretty interesting as well.

[Large-scale terrain algorithms]

Yes, the terrain height will be set in the shader (in the final version in the tessellation evaluation shader). I've stumbled across a blog where the author is basically sneering at all the geo clipmap implementations doing vertex displacement every frame in the shaders rather than deforming the terrain once on the CPU (see http://nolimitsdesigns.com/tag/terrain-rendering/). This was confusing for me - if you displace the patches on the CPU, aren't they then different vertex buffers? Anyways, I'll try the shader displacement approach first.

[Large-scale terrain algorithms]

Thanks, but don't cheer too soon - I will most certainly need help with a couple of shaders... :-)

[Leadwerks 3.1 Pre-orders Now Available, Indie Edition coming to Steam January 6th]

About the

 

Coming to Steam 1.6.14

 

on your landing page - at least every European will read that as "June 1st"...

[Procedural Terrain]

That's awesome! Now, what would be really cool is if this could be combined with an imported heightmap. E.g., if you use real-life elevation data, their resolution is typically too low for games (for SRTM data it's 30m per pixel in the US and 90m worldwide). So you have to "enhance" them to make them visually interesting, like adding some Perlin/fractal noise and eroding some of it afterwards.

[Virtual Texture Terrain]

Interesting article and awesome stuff! The concentric textures reminded me of the geometry clipmapping technique for terrains as describes in GPU Gems 2. Maybe this can be used together for vast Terrains?

[Beginning work on Leadwerks 3.1]

If I remember correctly, Josh stated somewhere his business model was "paid upgrades" which included upgrade fees for 3.1, 3.2 etc. Which is underlined by the "terrain in 3.0 at no extra cost" statement...

[Native Code Tutorials]

Don't aim for the stars and choose a scope that is too big ("key game development topics", "C++ programming"). Also have a clear vision of your target group (complete game dev newbie? familiar with some other game engine? LE2 veteran migrating to Leadwerks 3?).

Personally, I would favor (as kennan suggested) tutorials that simply extend the somewhat sparse API docs with examples. If they create a complete demo game in the end - nice. But a stand-alone physics tutorial, for example, that simply deals with falling boxes and the like but covers the relevant API would be as helpful.

[The Road Ahead]

The road map's looking good so far. A few comments, of course...

 

1) At some point you were mentioning that you wanted to do "something special" with terrain. Any hint what that might be? Streaming? Voxels?

 

2) With hardware like the Tegra 4 coming on the market and probably being used in devices like the next Ouya, the OpenGL 4 / advanced rendering should get a higher priority, even if we're still mainly targeting mobile.

 

3) If we're talking about an upgrade fee of 20-60% of the current (LE 2 licensee) price, I'm OK with that. If it's meant to be that share of the "normal" $1000 my guess would be that we're having the same uproar and discussions that we've just been through...

 

4) I think it would be nice to have some transparancy in this process (same for bugtracking), so maybe an accessible issue tracker like JIRA or Trac. There everybody could see proposed features (and issues) and vote for them.

 

5) And of course, some idea of the timeline would be interesting.

[The Road Ahead]

No, I don't

[The Road Ahead]

I don't have permission the access that page?