Josh

I've finally got the Asset Store looking the way I want: http://www.leadwerks.com/werkspace/files If you are a content author, get your files ready for July 25, when I will announce the launch. To apply to the merchant program, visit this page: http://www.leadwerks.com/werkspace/page/merchants There will be some promotions going around for new licensees to get free store credit, so that means people will be spending in the store to buy your assets. If you have any questions, just post here or PM me.

Leadwerks Engine 3 will run on your computer. Leadwerks Engine 2 will not.

I don't think there's anything I could even do to support it. LE is just a DLL, and I think this needs to be integrated into the main executable. I don't think it has to hook into the renderer in any way. I think it can be set up without modifying your EXE.

I don't know what is involved in setting up a program to run on Steam, but I imagine it is pretty easy. There's even been some Blitz3D programs on Steam, so it can't be too difficult.

I don't think so, I don't even know what those extensions do. Anyways, it's fixed now.

I wouldn't call LE3 even in the "pre-order" stage yet. There's no product to use at this point, even in a limited manner.

You're going to laugh when you see the fix. This is for version 2.43. I don't know if this will work for the evaluation kit. Find this line, around line 97 of "terrain.frag": height = vertexposition.y; Change it to this: height = texcoord0.y;//vertexposition.y; There is NO REASON I know of this should make any difference, because they are the same value, but through trial and error I found this worked. The shader does not give any warnings and works fine on NVidia and older ATI drivers, so I have no idea what is wrong with their drivers, but this fixes it on my test card.

ATI's drivers magically stopped working in an update they put out. There's no errors, no warnings, the shader just doesn't display right. A single texture lookup in the fragment shader screws up the vertex positions.

Terrain and models are two different things. Rendering the whole terrain using tessellation to handle the LOD isn't a good idea. Everything else here makes except their culling recommendations don't work. Just because a patch is back-facing does not mean a resulting triangle on it will be! Just because a patch is out of the frustum does not mean a triangle that results from subdividing that patch will be. It may be possible to add a buffer distance equal to the maximum tess extrusion distance, in which case culling in the shader would work. But not for terrain.

It certainly will work with VB.NET but it's up to you to retrieve the function pointers from the DLL.

I can never remember which is which. The engine automatically corrects your paths.

LE3 will initially support Windows, OSX, and iOS (iPhone and iPad). Android support is planned on following this.

Sorry, I didn't realize the image was linked from the gallery. I removed the image in the gallery because it didn't belong in the LE2 gallery. You can attach the image in your post if you like. They chucked a single vertex buffer at the GPU, which is the worst way you can render terrain. LE2 renders a set of instanced patches, and uses the displacement map for the height info. If you draw a single quad and tessellate it, you will lose the ability to show and hide sections of the terrain, even areas behind the camera. That means the tessellated approach will have to process maybe 3-4 times as many vertices. Because the tessellation pipeline is completely programmable, the hardware can't anticipate and cull offscreen patches. That discrepancy won't be apparent when you are rendering the whole terrain onscreen at once. Now you can still use tessellation on terrain patches, and have the speed of our existing terrain rendering, along with fine surface geometry detail. This reinforces my original statement, that tessellation is good for surface detail and not really useful aside from that.

Leadwerks Engine 3 is being coded in C++. As far as I know it is impossible for Leadwerks Engine to run on XBLA because they do not support C++ programing.

I already have it implemented. That image is so incredibly misleading. They are comparing a tessellated terrain to the most inefficient possible method of rendering terrain, and dismiss the displacement map in their memory totals The old ATI tessellation extensions are not the same thing as OpenGL4/DX11 tessellation shaders.

I'm working on this issue today. There's nothing wrong the the shader, but I'm going to have to find a way around this since ATI isn't going to fix their drivers. I wish they would just roll them back six months and stop releasing updates.

A few weeks ago, I was getting pretty nervous about all the known unknowns in going cross-platform with the Leadwerks Engine 3 code. All my libraries and languages are platform-agnostic, but there's always going to be small issues, and I wanted to get those worked out while the code was still malleable. Here's a few things I found. -OSX file paths don't have a drive letter, so the only way to specify a relative path is to add ".\" to the beginning. This had some significant implications for the asset reloading system. -iOS file paths are case-sensitive. -iOS projects require that all external files included in the project as a resource! Good thing the editor will be able to gather these up and generate a project automatically. -OSX child windows can't have their own menus. This means I have to make sure the tool windows in the editor have a complete toolbar for every function you might need to use. -OpenGLES doesn't allow shader uniform initializers. Although I rely on these to define default uniform values in the editor for the visual controls, the editor is actually never going to be running OpenGLES, since it's for embedded systems only. That's odd but convenient. -The default OSX default font is Lucida Grand 13 pt, a bit larger than the default Windows font, which required more space on some interface elements. -The minimum button dimensions on OSX you should use are 31x31. Otherwise those rounded corners won't have enough space to display properly. -There is no consistent OpenGL compressed texture format. Windows and OSX support DXTC, and iOS uses PRVTC. This is annoying, because it means uncompressed RGBA is the only cross-platform texture format. However, I think we can do an automatic PRVTC compression in the editor's "Publish" step for iOS, on DXTC compressed textures only. I don't even know if PRVTC format will even appear in the editor. -Aside from deferred rendering, OpenGLES2 can do pretty much anything OpenGL3 can. Pretty amazing potential here. Here's the current editor, showing the texture, material, and shader systems fully working together to make this skybox material. It presently works with OpenGL 3.2 on Windows, and OpenGL 1.4 on Windows and OSX. OSX Lion comes out this month, at which point I hope to have the GL3 renderer running on Mac as well: Android is the platform I am least worried about, in terms of initial implementation. I'm not sure if the NDK supports pure C++ programming yet, but that seems to be the direction they are heading in. The OpenGLES implementation for iOS should work the same on Android devices. iOS was definitely that hardest implementation to write, and it's not nearly complete, but I've seen enough I am confident we can become platform-agnostic with our code. I'm going to take a stab at the ATI terrain bug this afternoon. I don't think I'll get it fixed today, but it looks like ATI isn't going to fix their drivers, so I need to find a way around it.

Then they aren't potential customers. Definitely. You want your major software applications to be an ongoing relationship so that your input matters. I'm sure you've had a piece of software you used that stopped producing updates even though you would have paid for one. Unlimited expansion doesn't happen. I'm planning on an OpenGL 1 / Lua "indy" version for free or cheap. Generally, you want to segment your market so that you can get the most you can out of each type of customer. Some want all platforms and will gladly pay for them all, while some want a cheaper solution on one platform. I also want to have data on which platforms devs actually pay for, so I know what they value. I'm leaning towards making Windows/OSX the base package and then having add-ons for mobile platforms. This also means when a new mobile platform comes along, the addition of support for it can be self-funding; it doesn't rely on attracting new customers through added benefits.

I don't think Windows service packs will have anything to do with it, but you should update your drivers: www.ati.com The demo version is rather old so it's not a good reflection of the current engine. I'm working to get a new demo out.

Tessellation and LOD don't really have anything to do with each other. Unfortunately, I can't rely on tessellation for terrain LOD because it only works on a very small fraction of total supported hardware. It would be awesome to just draw a quad and let the GPU create all the terrain detail dynamically by distance. I don't think the results would be much different, but it would cut down on the complexity of the code I write. There's a lot of confusion about tessellation, and I think they've done a poor job of explaining it. As I see it, tessellation is the final answer to surface detail. First there was plain diffuse textures, then bumpmapping, then various parallax shaders, and finally real surface geometry with tessellation. You could replace LOD with carefully designed tessellated models, but it require your assets be modeled that way to begin with, and since it would only work with SM5 cards I don't see this being relied on any time soon. Tessellation detail is controllable dynamically in the shader, so you just supply a detail parameter, and then my shader will use that in the calculation. The shader actually has to calculate distance from camera, so it's quite low-level. Changing detail level on the fly is no problem.

1. Yes. 2. Like LE2, the LOD distances will be near, medium, far, infinite, with control over what each of those values is. This is so the engine can sort objects in a list of objects for each distance, and discard far away objects without having to iterate through each one. For example, if the "far" distance is 200, and the closest point between the camera and a certain octree node is 220, then we know we don't have to check any of the entities in the "far" list for that node.

There is code in the forum from the editor that shows how to do this. It's not super easy, but it's definitely fast and doable.

Yes, that's what I define maintenance as.

Bug fixes and maintenance will continue. Mostly I worry about new driver bugs coming up.

I think iOS was the hardest platform so far to implement, due to the Objective-C nonsense, but ongoing support demands will be relatively low. The Android implementation should be easier, if they are finally doing away with the Java nonsense, but ongoing support will be more demanding. So I intend to make the sales on iOS first so I can afford the support demands of Android.