Josh

Yes, but those are all node or grid based, are they not? Recast handles dynamic changes by splitting the mesh into tiles and recalculating only tiles that have changed. That might not work well if you have thousands of objects rolling around, but most games don't tend to do that anyways.

It doesn't happen to me much anymore but when I get stuck on a difficult problem, I get very restless and short-tempered. I guess that's the point where most programmers give up on a project. Since I can't physically wrestle code to the ground and give it a good beating Billy Batts style, the fight or flight response probably is not conducive to sitting in front of a piece of glass and figuring out code. On the other hand, I have a tendency to get difficult things done, no matter how hard they are. Maybe a more patient programmer in the same situation would be too patient to produce useful output under his own volition. My understanding of how recast works is it turns upwards-facing triangles into a grid, then uses that grid to construct a navigation mesh. The results seem very robust, but the fundamental approach is an approximation. It is possible to construct a perfectly accurate navigation mesh out of CSG solids, because they have volumetric properties an arbitrary polygon soup does not. On the other hand, my instinct says people will prefer an approximation that works with any arbitrary geometry over a mathematically correct solution that requires constructive solid geometry. Another approach is to simply let the user construct the navigation mesh in the editor. Since the pieces need to be convex, a CSG editor is ideal for this. This also has the possibility of adding more advanced functionality like climbing up walls and jumping. (This is how Left 4 Dead 2 works.) Still, I know people will value a pretty-good solution that works with arbitrary polygon geometry more, and that gets into a land of approximations I don't really have any experience with. I suspect it would involve a lot of adjustments and fine-tuning to get the desired results. You can see here, the results are definitely an approximation, but they're a pretty good one: So here are the options I am looking at: 1. Hire someone with existing knowledge of recast to write the implementation. 2. Find someone with existing knowledge of recast and work off their knowledge to write the implementation myself. 3. Stare at incomprehensible code for days on end and hope that somehow imparts knowledge of how to use the library. Maybe other people can understand this, but I am awful at deciphering other people's code. 4. Write my own polygon-based solution. 5. Write my own CSG-based solution. I think the CSG-based solution is the best technical choice, but I think it would cause a lot of complaints. It's fine for Valve, but I think a lot of people would just get mad if I tried to explain why arbitrary triangle meshes have no volumetric properties. Another frightening thing about recast is that from what I am reading, a lot of people are using the demo application as a tool to generate their navmesh data, and just loading the saved files that produces in their own game. That's completely unacceptable. We need to be able to generate this data in our own editor. I know it's possible, but the lack of people able to do this is an indication of the difficulty of the task. The pathfinding stuff is actually the last bit of research I have to complete before I know how everything in Leadwerks3D works. The rest is just a matter of hard work, but all the unknown factors we started with will be resolved.

Everyone who claimed to be using recast has mysteriously disappeared.

Read the vertex and triangle data from one and add it to another. There are commands to retrieve all the data.

Please read this news item: http://www.leadwerks.com/werkspace/blog/41/entry-619-data-loss-announcement The ordering system is a recent addition to the site, and the majority of developers do not have a purchase record in the client area. However, your license is still valid and you have access to the entire site. You can download the installer here: http://www.leadwerks.com/werkspace/files/file/186-leadwerks-engine-updater/ And if you need your registration key re-sent just email support at leadwerks.com. We have separate records of all accounts, and your purchase is in our records.

ha...there's enough problems with people understanding the spelling as it is.

That would go in community tutorials.

It sounds like you want it travelling at the same velocity, perpindicular to the normal of the ground. Take the vertical velocity and use that to create a vector with the horizontal movement to calculate how much the horizontal movement should be reduced by, You should definitely multiply the movement by something like 0.1 when the controller is airborne.

The reason the engine doesn't store a list of collisions is because it can result in hundreds of dynamic allocations of memory each physics update, most of which will be unneeded.

It's behaving correctly. -You are applying horizontal force to the player, even when they are airborne. You should greatly reduce their movement when airborne. -Your movement is quite strong compared to gravity. Turn the movement down or increase the gravity, or both.

I think this is what we want the classes to be: #include "../le3.h" namespace le3 { class NavMesh { public: float radius; float height; float climbheight; float maxslope; float cellsize; void AddVertex(const float& x, const float& y, const float&z); void AddPolygon(const int& count, const short* indices); bool Build(); bool BuildTile(const int& tilex, const int& tilez); Path* FindPath(const Vec3& p0, const Vec3& p1) }; class Path { public: std::vector<Vec3> points; }; }

You do not need to buy any other software to convert models. You have not posted any files for us to try, so there is no way for us to know what the problem you are having is.

Recast uses a fixed radius, doesn't it? I mean, it can't dynamically handle characters with different radii, can it?

Yep, that is true.

Handmade navmeshes in the CSG editor might be much more optimal: http://www.ai-blog.net/archives/000152.html However, my instinct says people will prefer an automatic solution, even if performance was ten times slower.

I just tried this, and the ball joints are holding the chain together: SuperStrict Framework leadwerks.ENGINE Graphics 640,480 RegisterAbstractPath "C:\Leadwerks Engine SDK" RegisterAbstractPath AppDir If Not CreateWorld() RuntimeError "Failed to create world." Local camera:TCamera=CreateCamera() Local buffer0:tbuffer=CreateBuffer(640,480,BUFFER_COLOR0|BUFFER_DEPTH|BUFFER_NORMAL) MoveEntity Camera, Vec3(0,40,-30) RotateEntity Camera, Vec3(45,0,0),0 SetShadowQuality(1) Local light:tlight=CreateDirectionalLight()' Create light MoveEntity (Light, Vec3(0,10,0) ) RotateEntity (Light, Vec3(45,45,0) ,0) EntityColor(Light, Vec4(1)) AmbientLight (Vec3(.2,.2,.3)) Local ground:tentity= CreateCube()' Ground Local groundphy:tbody = CreateBodyBox(100,100,100) EntityParent (ground,groundphy) ScaleEntity(ground,Vec3(100,100,100)) MoveEntity (groundphy, Vec3(0,-50,0)) SetBodyMass(groundphy, 0); EntityType (groundphy, 1, 1); Local crane:TEntity= CreateCube() Local cranephy:tbody = CreateBodyBox(100,2,2) EntityParent (crane,cranephy,0) ScaleEntity(crane,Vec3(100,2,2)) MoveEntity (cranephy, Vec3(0,30,0)) SetBodyMass(cranephy, 0) EntityType (cranephy, 1, 1) Local cubePhy:tbody[10] Local cube:tentity Local joint:tjoint For Local i:Int=1 To 10 cube= CreateCube()'boxes cubePhy[i-1]= CreateBodyBox(1,1,1) EntityParent (cube,cubePhy[i-1],1) ScaleEntity(cube,Vec3(2,2,2)) SweptCollision (cubePhy[i-1], 1) MoveEntity (cubePhy[i-1], Vec3(0,i*2-1+10,0)) SetBodyMass(cubePhy[i-1], 1) EntityType (cubePhy[i-1], 1,0) If i=10 Joint:tjoint = CreateJointBall( cranephy,cubePhy[i-1], Vec3(0,29,0)) End If If i>1 Joint:tjoint = CreateJointBall( cubePhy[i-1],cubePhy[i-2], Vec3(0,i*2-2+10,0)) End If Next Collisions(1,1,1)' Important! Enable collision between bodys of Type 1 While Not KeyHit(KEY_ESCAPE) If KeyHit(KEY_SPACE) AddBodyForce(cubePhy[Rand(9)],Vec3(10000,0,10000),0)' apply force End If UpdateWorld(1) SetBuffer(Buffer0) RenderWorld() SetBuffer(BackBuffer()) RenderLights(Buffer0) DrawText ("Press SPACE to apply force to one of the boxes!",0,0) Flip 1 Wend

Your programmer must be smarter than me, because I just see pages and pages of gibberish.

If you download it with SVN there's a doxygen folder. There's a footer and header html files, but no index or main page: http://code.google.com/p/recastnavigation/source/checkout

If you had ordered it through the account you are posting on, your account would have automatically been moved to the "Leadwerks Developer" group. If there was an error please email support at leadwerks.com with the email address you used to order and explain the problem.

So where's the documentation?

I'm trying to figure this out myself. His library is completely undocumented...there's just a demo with SDL, a GUI, and who knows what else built into it, so it's impossible to tell what the actual commands to use it are.

That's not a bad idea. Yes, you can link from one actor on one entity to another actor on another entity.

Can you rephrase that? I think we'll be able to save flowgraphs as part of a prefab, so you can set logic up once for a set of entities and then save it as one prefab of interconnected objects.

Mike, the entities are referenced by a unique ID, so the name does not matter. What scares me is what happens when the user resaves a script and the outputs and inputs change. It's very hard to write an editor that dynamically reloads everything. The whole purpose is to have a standard way of making things interact, so that all our scripted objects can talk to one another.

Ah yes, it's in a passworded zip, and only the editor knows the password.