Josh

Fewer materials is better. Fewer polygons is better. Lower resolution textures are better. Fewer entities are better.

There is no formula for making models that will result in optimal rendering. There's a lot of ways a scene can be made slow. Generally, you want to keep your entity count to a minimum, so eliminate any entity hierarchy from your models unless it is needed. Turn full statistics on in the editor and post screenshots. I tried to run your executable, but it won't launch.

Turn full statistics on in the editor and post screenshots. I can't look at your models because they're all in a password-protected pak file.

Already compiling it into Leadwerks3D, thanks Darren!

File Name: Asphalt File Submitter: Josh File Submitted: 25 Aug 2011 File Updated: 27 Aug 2011 File Category: Materials Resolution: 1024x1024 This gorgeous asphalt material comes in three variations. Normal maps, material files, DDS textures, and TGA files are included, with a total of six textures. Click here to download this file

File Name: Concrete Floors File Submitter: Josh File Submitted: 25 Aug 2011 File Updated: 27 Aug 2011 File Category: Materials Resolution: 512x512 For the first time ever, this concrete floor set is available in a standalone package. TGA and DDS files are included, along with normal maps and Leadwerks Engine material files. Five materials are included, for a total of ten textures. These textures can be mixed and matched to create sidewalks and streets with a consistent design and feel. Click here to download this file

File Name: Brick Walls File Submitter: Josh File Submitted: 25 Aug 2011 File Updated: 25 Aug 2011 File Category: Materials Resolution: 512x512 For the first time ever, our brick wall textures are available in a standalone package. This pack of 15 brick wall materials, with normal maps included, for a total of 30 textures. You also get one long-lost painted variation that has never been released to the public, and an extra concrete base trim material. Click here to download this file

Right, a lot of people can do that, but the problem is we then branch the code, and each programmer becomes an island. This causes the rate of collaboration to be pretty low. With a built-in navigation system, we can share AI scripts and they will all work together. We can even write different AI scripts and make them battle. In the past, I figured that my job is to provide the graphics and physics foundation on which gameplay is built, and then let the user take over. I don't think that approach has worked out very well, except for a few people who already know how to write games.

I don't know if I would recommend that, although it would make the forces symmetrical. Joints have a parent and child, but I don't think they should work differently, as long as they are both the same mass. You'd have to ask on the Newton Dynamics forum for more detail.

I'm focusing on the gameplay features first and foremost. Pathfinding and flowgraphs are more important than having another post-processing effect.

Okay, I have a large amount of navmesh generation code compiling. It's nowhere near working, but I have learned some things. The most important thing to understand is that recast is NOT a library; It's an open-source program. The code doing the heavy lifting is very impressive, but this thing was not designed as a general library with commands to be called from an external program. You've got to extract the parts of the program you want, and try to comment out all the calls to things you don't want, like OpenGL rendering, the GUI, etc.

I found some recast code that actually makes some sense. Fingers crossed...

Yeah, but 2D voxels are just a fancy way of saying a grid.

Yes, but those are all node or grid based, are they not?

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; }; }