Josh

Use the character controller.

I'd use a cubemap. Real-time reflection for a small pool of water is sort of overkill.

Navmeshes can have multiple levels and overhangs, so you only need one for a small or medium sized scene. It's not a per-model thing, it can handle all geometry, and the engine will take care of that automatically. Dynamically recalculating sections can be done by running it on a separate thread and getting the results a few frames later. Again, the engine just does it automatically for you. I don't know if mobile devices will have enough power for this, but when was the last time you worried about waypoint AI not being dynamic? For very large scenes, I think you will need to create multiple navmeshes in the editor, because otherwise the navmesh data might exceed system memory. If you have ten miles of terrain and three towns, you would probably create navmeshes for each town, and then link them together with conventional waypoints that just follow the roads between them.

So after about three weeks of pain and frustration, I have successfully calculated my first path using Recast navigation. This has been a new experience for me. I've implemented half a dozen low-level C++ libraries, and never had any serious trouble, but Recast Navigation is something else. The technology underlying Recast is impressive. First they take triangle geometry, convert it to voxels, then calculate navigation, and convert it back into rough polygons. You can read about the process in more detail here: https://sites.google.com/site/recastnavigation/MikkoMononen_RecastSlides.pdf The results seem pretty reliable, and although the speed of regenerating a tile is slow, it can be done on a separate thread and doesn't have to be updated all that often. I have two criticisms of the library. First, the code is a total mess. I can't complain too much since it's a free library, and I definitely appreciate Mikko putting it out there, but integrating it into the engine was a hellish process. I wouldn't even call Recast a code library so much as it is an open-source program. The amount of work it took to figure out what was going on was far beyond any library I have worked with, and it could have been wrapped up into a set of much simpler commands (which is what my end result was). Second, I believe converting polygons to voxels and back is the technically wrong way to go about this. Constructive solid geometry is perfect for navmeshes, autogenerated or otherwise. It would be very fast to generate. It could be dynamically updated quickly. The results would also be 100% accurate virtually all the time. However, it would require all navigation geometry to be modeled with CSG, and although I would be fine with that, I know others will want to use arbitrary polygonal geometry. So that's one thing I would do different if I were making an engine for just myself. There's an example of why you need to be flexible with your goals sometimes. Still, it's great to be able to build navigation data for any scene and make a character walk around in it without any waypoints or ray casts. Below is my very first result with Recast. There's some obvious strange results with the path, but the point is that it's working, to some extent. It's a minor miracle I am able to plot any kind of path at all. The hard part is done, and I'm sure I'll get any remaining issues ironed out pretty quickly: Building AI features right into the engine will give us better integration than using a third-party add-on, or trying to build it on top of the engine. First example, we can use physics geometry instead of visual polygons, and make the engine automatically invalidate and update sections of a map when objects move. This will give you powerful AI features that work perfectly with the rest of the engine, so you can control characters with just a few lines of script code. When this is done, it's reasonable to expect to be able to program something like Left 4 Dead in just a couple hundred lines of script (or less, if you just feel dragging some premade scripts around and attaching them to entities). Once the pathfinding is all tidied up, it will be a big moment, because it means at that point I will know everything I need to finish Leadwerks3D! When setting out with Leadwerks3D, the things I hadn't done before were what I was most worried about. I attacked the unknown issues first. Now that we are coming to the end of this long research and development phase, all that remains is a lot of hard work. It's all stuff I have done before, so I expect the remaining tasks to go pretty quickly. It's also pretty awesome to have a clear picture of how this massive piece of technology all works...four platforms, with rendering technology stretching from fixed-function graphics all the way to Shader Model 5 hardware tessellation...plus the easiest art pipeline ever and a script and flowgraph system that no one has ever done. The scope of this engine is just so much bigger than anything I have ever done, and it actually works! B)

LoadAnimation() can be used to load animations from a GMF file into another mesh, but the hierarchy needs to match.

It's using LuaJIT 1.1.6, but I don't know if that makes any difference.

HDR uses RGBA16.

There are a few different configurations that get used depending on hardware.

You don't need material files for the model to show up, but without the model file there is no way for us to tell what might be wrong.

Local size:Int size=luastate.StackSize() lua_getglobal(luastate.L,"UpdatePhysicsHook") If lua_isfunction(luastate.L,-1) luastate.PushObject(Self) luastate.invoke(1,0) EndIf luastate.SetStackSize(size) Method StackSize:Int() Return lua_gettop(L) EndMethod Method SetStackSize(size:Int) {hidden} Local currentsize:Int=StackSize() If size<currentsize lua_pop(L,currentsize-size) EndIf EndMethod Method Invoke:Int(in:Int=0,out:Int=0) Local error:String Local result:Int Local time:Int Local dummy:Object Local debugmode:Int ?debug debugmode=True ? If debugmode result=lua_pcall(L,in,out,0) Else Try result=lua_pcall(L,in,out,0) Catch dummy:Object HandleException() EndTry EndIf If result HandleError() Return False EndIf If autogc If CollectGarbageFrequency>0 time=MilliSecs() If time-lastcollectgarbagetime>CollectGarbageFrequency lastcollectgarbagetime=time ' CollectGarbage() EndIf EndIf EndIf Return True EndMethod

Without a code example, I doubt your assertion that this is the case.

I can't run your code because their does not appear to be a LEO VC2008 template. Don't do this.

Distance culling is extremely efficient because it skips entire categories based on distance. I can't make any more specific of a comment than that without example code I can run.

No, they are unrelated. Don't worry about occlusion culling. It's automatically used for light and animated models.

Occlusion culling of individual entities will almost always be slower than not using it. The test itself has a cost

See the driver example script.

http://www.leadwerks.com/werkspace/files/category/23-nature/

The character controller uses my own physics routines which have been very stable. I can't say what the problem might be without seeing an example.

You are attempting to make worlds bigger than what 32-bit floating points can handle. The only solution is to make it smaller.

Interesting modification.

Well, I guess Newton is not officially compatible with Android yet. I have PhysX for Android, Windows, and Mac, but the iOS version is not released yet. Newton going open source is not a good sign, because it means if you have a problem, you have to fix it yourself. I know Bullet won this poll, but I think it would be the worst option of the three: Open source (=bad documentation and support), no corporate marketing campaign to convince people it's the best, and I am not familiar with it. It's a tough call because PhysX means restricting the world size below what we have now, but my guess is people would rather have it, even if it's full of bugs, just because it has a nice logo. Upper left at 0:07: I guess I'd better start talking about THE AMAZING POWER OF PHYSX 3 since AFAIK Leadwerks will be the only major engine using the new version.

I think you are thinking of STALKER, they called it a "rain shadowmap". That's just it, you do a depth render to a texture, then use that in the shader to tell where the rain is allowed.

You just get the world position and normal of each pixel, round off to the nearest XZ direction (there are four possible). Use that for the vertical component of rain sliding down. Then add in raindrops based on the Y component of the normal. You can do something similar for snow accumulation...someone posted a video of it working.

It's possible to do this with a post-processing shader that perturbs the normals using an animated texture and a calculation of the surface normal.

Thanks for releasing this!