Niosop

DXT5nm typically also clears out the R and B channels of the texture and reconstructs the Z component of the normal in the shader from the X and Y (A and G) components.

Grab substance player (http://www.allegorithmic.com/products/player), it comes with some free substances and you can pull the height map out of it and use it as the alpha channel. There's some other free substances out there if the ones it comes with aren't good enough, or if you need something special let me know and I'll create some for you.

My last terrain shader used RGB for albedo, Alpha for specular, then a separate Alpha8 texture for height. To determine which texture to display it would take splat value * texture height value. There would be some blending at very close values, but mostly it resulted in well defined transitions that looked pretty good. If there's room in the shader then adding a base offset and height multiplier could add some flexibility. Since you have the height you could use it for POM if you wanted as well. An early version of the system is shown here: I believe that BF3 uses a similar system.

I'm guessing the texture stages are generated on the GPU? So this doesn't give you the constant VRAM usage that mega-textures traditionally do, but does give you unlimited texture layers and decals w/ only a small VRAM overhead?

Haven't worked w/ LE in a while, so there might be some reason I don't remember why this wouldn't work, but how I always handle deforming clothing is just to have every possible deforming clothing item weighted to the same armature and exported in the same file as the character, but as different objects. Then in the engine just disable all the clothing that they are not wearing. I've used this method before and am using it right now for a game I'm working on and it works great.

The main advantage TCP gives is "guaranteed delivery". Packets you send via TCP will be processed in the order they were sent (packet reordering) and will be retransmitted if lost. Also, having a TCP stream associated with a client allows you to do authentication when the stream is established and not worry about it after that. It also makes spoofing the source IP much, much harder due to TCP's three way handshake. Everything TCP does can be implemented on top of UDP application side, but eventually you end up just remaking TCP, but with all the additional stuff having to be handled in your application instead of by the networking stack. Many game libraries use UDP and selectively re-implement those features of TCP that they need, such as discarding late packets or requesting retransmittal of lost packets. It comes down to using the right tool for the job. Often a mixture of the two is the correct approach.

There's no way you can account for every possible use case in the general release editor, and even trying would result in an unusable mess with a bunch of features that most people have no use for. Say I want to select a bunch of empty game objects, either exported from my modeling program or manually placed. I want to select an arbitrary number of models and have it randomly place one of those models at each of the empty positions, as a child of that empty, based on a seed value I provide, deleting any existing children. It should then randomly rotate each of these models about an axis I specify, scale them between a min and max value I provide, and then drop them onto the ground using either physics or a raycast. These should be placed at edit time, not runtime, so that I can use that as a base and then manually tweak them. The LUA script to do this isn't difficult at all, but having some way to run this script on demand (a menu item or button I can click) and an API so I can create an interface where I can select the empties I want to use, the models I want to use, the random seed, the axis of rotation and the min/max scale factors to use, and finally a "Run" button is what makes it powerful and painless to use. This might or might not be useful enough to be included in the general editor, but I don't want to wait for you to implement it (no matter how fast you are) when I could spend 5 minutes and do it myself. And what if I didn't want to select the empties myself, but just have it select any object with a name that starts with "PH1"? Being able to customize the editor to fit the needs of a particular project is a MASSIVE workflow enhancer. On any given project I usually have a half dozen or so editor scripts that are unique to that project and would be totally useless in any other project, but save me a ton of time on that particular project. Anything from automatically assigning materials to characters based on name to automatically assigning scripts to game objects based on name or some other criteria. I love the LE engine. But I don't really use it due to workflow issues. LE3 is addressing the biggest of these (asset importing), but editor scripting is right up there with it.

It's kind of frightening to me that people are already unsatisfied with a tool that isn't even done. What needs to be fixed? As you know, I'm a big fan of both LE and Unity. As I see it there's a few reasons why Unity has gained popularity. 1) Multi-platform deployment. LE3 takes care of this, and if it's all included in the base license then it's even better than Unity which charges separately for Android and iPhone/iPad deployment licenses. Only thing missing is web deployment in LE but it's not a huge deal to me. 2) Component based programming. LUA scripting in LE does this and it's great for making reusable and share-able components. 3) Excellent art pipeline. LE3 is addressing this and looks really promising. This is a huge one for me. 4) Being able to script and extend the editor. This has been instrumental in the huge ecosystem of 3rd party plugins available for Unity. It's not what we think is missing right now, but what we may find to be missing later. You'll always be behind feature-wise if you try and do everything yourself. While I agree with your earlier post about small dev teams being more agile than big teams, neither can really compete with crowd sourcing when everyone is trying to scratch their own particular itch in their area of expertise. A quick example: Unity terrain sucks, so I wrote a mesh terrain painting system and shader set. I have a giant multi-million poly mesh terrain with cave entrances and overhangs, wrote a Blender script to break it into smaller chunks to stay under the 64k vert limit of Unity and allow frustum and occlusion culling to be of use, then import them all. I then need to assign the same material to hundreds or thousands of chunks. I can either spend a ton of time dragging materials onto each chunk, or write a quick editor script that allows me shift select all the chunks and pick my "Multi Object Material Assigner" menu item, pick the material and have the script assign the material to all the selected objects at edit time. I also write an asset postprocessing script that looks at the name of the object being imported and sets it up to create colliders, not import animations and not create materials for anything with "chunk" in the asset name, as well as scale the import. It's very specific to my needs, so it's not really something I would expect in the general editor, but it saves me many hours of tedious work and makes me happy. The "Multi Object Material Assigner" script is general enough to be usable elsewhere, so I often drop it into other projects where it's needed and instantly have a menu item for it. For the same system, I need to average the vertex normals of the edge verts so there isn't a visible seam between chunks. The number of verts to be modified isn't that many, but searching through them to find those that need to be does take a while (many minutes on a medium sized terrain). So doing it at runtime isn't an option, instead I have an editor script that searches through them, records the object, vert index, calculated normal and tangent in a file I specify, then at runtime I can just load that file and apply it in less than a second. TL;DR - Being able to customize the editor to make it have features specific to your project is a really good thing.

Is Lua going to be a problem for IOS devices? IIRC, Apple is pretty down on any scripting languages being used. Would all the scripts be run through a Lua AOT compiler first? Or am I misunderstanding Apple's policies?

No, I was talking about actual 3D voxels, then reskinning it to create a (hopefully) simplified mesh.

I'd say get in touch with this guy: http://www.arongranberg.com/unity/a-pathfinding/ and see if he'd want to do it. His Unity implementation is pretty nice, offers good performance and a bunch of features including grid based, point based, imported navmesh and recast based navmesh generation. I like having the option of using different types, as navmeshes are very performant if you don't need to change it at runtime, but grid based is a lot faster to update if you need to dynamically add obstacles at runtime. Multithreading is also a huge plus, since I usually don't care if a path takes a couple frames to solve, as long as it doesn't impact framerate while it's solving. Anyways, just my two cents, which isn't worth much in this economy. P.S. I *think* recast works by voxelizing the poly mesh then generating a navmesh that fits that. But that's just the impression I got from reading something somewhere and may be totally incorrect.

You could always apply a blurring algorithm to get softer shadows afterwards. But having visually appealing shadow resolution at various distances would be great.

When you do go for some first round funding, I'd consider spending it on some middleware licensing and integration. Even if you got a couple additional programmers, it would still take forever to implement stuff that's already out there. Something like CloakWorks could probably be had for very cheap as it's just starting up. Scaleform or another GUI middleware would also be very nice to have. An integrated lightmapper could do wonders as well. You already have one of the best dynamic lighting systems out there, but it's never going to compare to precalculated lighting. Combining the two could give awesome performance and quality gains. The main problem I have w/ LeadWerks at the moment is just workflow. Having to close the editor to reimport an asset, run separate tools to do file conversions, etc is a turn off. But I think you were already planning on addressing this in 3.0. Anyways, keep on keeping on. I look forward to what Leadwerks can become and will probably pick up a 3.0 beta license once it's available depending on the state of the editor.

Oh, one other thing you might have to do is merge verts/remove doubles on the edges that connect when you do a 360 degree spin. Also, you may need to remove interior edges along that portion to allow for proper normal calculation.

Yes, there is. Look at the Spin button on the left when in edit mode. Using that with a curve or series of points should give you what you want. If you need to be able to see the inside, add and apply a Solidify modifier to it afterwards.

It's an alpha mask (usually in the form of a grayscale image) that determines what parts are painted. So you could have a streaky one that would allow you to paint streaks of a texture to the terrain.

Someone else had the same issue. If I recall correctly, you're not doing anything wrong, it's an LE "feature". May want to search the forums for the other post and see if there were any fixes in that thread.

Just saw this: http://berkelium.org/ It's a BSD licensed wrapper around Chromium. Since Awesonium licensing is so expensive, this might be a good replacement that could be integrated into LE. Anyone want to work on it?

Actually pretty much every engine I've used works pretty much the same as LE in this regard. Unless you're referring to something specific?

And here's the download: http://leadwerks.com/werkspace/index.php?app=downloads&showfile=89

This copy protection is different than the standard, run of the mill stuff because it actually moves some of the game functionality onto their servers. For instance, saving/loading games now saves/loads to/from their servers. Other (undisclosed) things are also handled by them and not the local client. The cracks that were released early on only bypassed the standard checks allowing you to start the game, but didn't replace any of the functionality that was missing, so they didn't give you a fully working game. Of course, even this will be cracked (if it hasn't by now, haven't payed much attention) via a proxy program or someone adding in the missing code. But the copy protection wasn't intended to stop crackers, just to slow them down for a while after launch in the hope it would increase sales the first week/month. Nobody knows if it actually helped any. How many pirates, finding that there wasn't a working pirated available, actually purchased the game? How many legitimate customers were lost due to annoying DRM? How much repeat business was lost when customers couldn't play for a whole weekend because Ubisoft's servers were under a DDOS attack? Anyways, personally I think DRM is a stupid waste of resources. I used to routinely use cracked versions of games that I bought because the cracked version loaded faster and removed a lot of the copy protection related bugs and kept me from having to swap CDs all the time. I haven't encountered nearly as many copy protection related bugs recently, but I don't buy as many games as I used to either due to less free time. Plus, since almost everything I buy nowdays is off of steam I don't have to worry about swapping CDs anymore.

It's about time. Khronos has until now pretty much dropped the ball and let the OpenGL spec languish. Hopefully Josh will jump straight to 3.3 so we can get the features that are supported by current hardware and it will be less of a jump to 4.0 when supported hardware arrives.

This post and the comments on it are pretty interesting. The comments by sinbad (of Ogre3D) and Aras (of Unity) seem pretty reliable to me since both engines have both DX and OpenGL rendering systems and are cross platform, so they don't have a vested interest in promoting either.

DX uses +Y, OpenGL uses -Y. If you have a lot of things already done +Y, then you can modify the shader to invert the Y instead of redoing your normal maps.

That code sets it to almost black. Is that what you wanted?