Josh

There's basically no API to worry about. You just have a command to find a path, and don't have to worry about anything else. As far as controller movement goes, I think I'll just leave that to the user, and have some example scripts. It's very easy to just point it to the next node and go.

The reason it uses tiles is so that if a single tile changes, you can recalculate only that data, instead of the whole map.

I fixed our AI navigation problems and got pathfinding to work using navmeshes. Now you can easily make a horde of zombies chase after the player without setting up any waypoints. Which is the whole point of this, of course. The problem had to do with a polygon filter, and I am still not sure what is going on, so I disabled it for now.

Yep, that's what it looked like when I went back and watched it. Some polys in segmented tiles seem to be invalid.

They don't actually use physics, they just do a raycast in the manner I first described.

I'm testing the Leadwerks3D AI navigation and getting some interesting results. I'm not sure why it's acting this way, but we'll get it figured out soon. It seems like the navigation gets "stuck" on corners, fails to enter some tiles, and likes to take the scenic route to some destinations. B)

I believe this is just an OS thing

I have never seen a game that used that level of detail in character physics.

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/