Rick

So if the size of my rectangles are all different sizes and don't share exactly the same edges, how could you get the center point of each rectangle edge to figure out where you need to go? MicroPather, looks sweet btw. Thanks for that!

?? maybe I look at it differently but when I did 2D A* with 2D squares all the same size with the grid being 5x5 for example, I didn't worry about the links between them because you had the information already to know where it's possible to go. I also didn't use any edges. Once I found the 2D squares I simply took each middle point of each square and that was the points I traveled along. So that is where my thinking is coming from. So why would I need to make the edges of the convex polygons the links between them? Could I actually give the information in each polygon where I want it linked to? I would basically link it to the immediate surrounding polygons, but manually via giving it information, or using the LE link system in the editor. I guess the reason I say this is because I'm thinking of just using rectangle planes as the polygons and just place them next to each other and assign the links between them manually. So once I find my list of polygons I use the center of the edge from the previous polygon to the next as my points?

OK that makes sense. So now my question would be given each mesh node can be any size, once you find the meshes that you can walk through to get to your goal, how do you get specific points in these meshes to move to that would produce the fastest route and or most realistic route? I can't imagine you would use center points or anything because if you have a large mesh by a T hallway, the center of that could be in the middle of the T and you would get a very 90 degree turning. Is that where the string pulling comes in? It doesn't seem like it from your description that it would provide a more realistic cutting of the corner to turn around the corner. So how do you determine the actual point(s) in a mesh node that is part of your path?

Hey Chris, I know the code has this in it, but I guess I would be first looking for a high level description of what things are and why we do them a certain way. I can get the how things are from code, but there is no detail on why generally in code, and it's also a big pain to decode things. Why? What is a string pulling algorithm? I'm almost more wanting to do this myself to learn about what it's doing. I'm also looking for a manual way to place mesh nodes myself in a map and link them and run my algo on it just for learning and testing, but I haven't seen much literature on using path finding methods with a nav mesh explained. Just code. Was hoping someone could give the high level basic idea with nav mesh and A*. Not 10k high, but more like 1k high level. If we go to high I already know that, but looking for a higher level than code at the moment.

But it seems it doesn't matter. It seems you can have any size of mesh for a node. If your environment is static then there wouldn't be much to worry about, I guess you could pick any point in a mesh node that is in your path randomly and it would work (although would give strange but funny results ). It feels like if your scene can be dynamic you might run into issues where you would need to do more within a mesh node. If a large mesh node was picked as part of the path and a box was placed inside that mesh node, then I would assume you'd have to do something to avoid that box. You wouldn't want it to invalidate your entire path that you found because the box could be really small inside this one large mesh node. I tried looking for string pulling but didn't find much.

I'm sure Josh does because it means more work for him

Load a texture and draw it with DrawImage(). If you want true 2D.

Wow, that was a super duper dumb question Just kidding. That's not a dumb question at all. What you are thinking is correct if you aren't using all lua. If you are using BMax, C++, or .NET then you would create your map in the editor and then load it in your language of choice. You would put things in your map that let your code know if it needs to do anything. Like a player start point or something.

I was thinking about creating a very simplistic navmesh thingoid. You drag it into your scene and it creates a plane object. You can resize it via properties and rotate it. You place it where you want, then make links between them (now that I know they need to be linked). When the game runs it would find these thingoids and store the plane information and then hide/remove the planes so they aren't visible. Then you could place a pathfinding thingoid in your scene to work with that data. This would of course be a very manual process but it would be something easier to create than the automatic detection. Plus it gives me a good reason to learn how navmeshes work. I can't seem to find any good tutorials on how to use a pathfinding process with the navmesh though. I understand I can use A* but that would return the navigation meshes that I can walk on. That's all fine and good, but those meshes could be rather large, and ideally you want points to move the object between. So once I get the meshes that could get me to the goal, how do you break that down further to points within that mesh that are the shortest?

So there is a question. Do you have to make links between nodes? When I did the 2D grid I didn't have to make links between the tiles since they were all lined up perfectly.

So my question is, even if I have a navigation mesh, what would I use for pathfinding through it? I've done A* before in 2D where it was a perfect 2D grid, but how would I implement A* in 3D where the navigation mesh has all different sizes and placed all over the place. Another question along those lines is do the navigation meshes all need to be touching each other? Can you have gaps between navigation meshes and still be ok?

I don't know if I would rotate the controller. Instead it would be nice if you could make oval shaped. Then you could change the shape of the controller instead to be long and narrow.

Maybe you can't, but I have 20/20 vision I would just use a raycast myself. I agree with you that I wouldn't see a need to create any mesh for a bullet.

I was wondering the same thing. It would seem unlikely to me that anyone would write their game in 2 languages.

I feel like CSG is a requirement for any mapping editor. You don't want your level designers to rely on the modelers for the core larger things in your level. The designer should be able to do those.

It would also depend on how you write it. You can bloat C/C++ to a point where you kill any performance gains from it. I think the benefit is that you have more control over how C/C++ works and can get pretty low level on speed intensive code to make a bigger difference. You could even mix some assembly in there to get even faster results if you so wanted to. The speed you will get will come from removing any "fanciness" that C++ has and get bare bones. That part of the code will probably look pretty ugly but it will run noticeably faster than any language where you can't get lower level access. This is why everyone in the industry uses C/C++. If you ever get points in your code that become bottlenecks you can most likely always optimize it better with C/C++ than any other higher level language. On a side note I actually find C/C++ much cleaner and crispier than any language I have seen before. Something about the brackets that I love. I'm so sick of typing 'End', 'Next' at work in VB.NET it's not even funny.

I got my recursion code working. I guess I don't see what you are describing in the code that you posted. I can only assume there is a missing piece that you didn't post. Maybe I'm wrong but it doesn't look like getWidget() transverses a hierarchy of parent/child relationship. I see the below code, but that just seems to say if the current widget is inside, check the child widget to this and return it. If getWidget() isn't called recursively then it seems you would only be getting the first child layer and not any nested children. // Check position if( pWidget->isPointInside( _uiX, _uiY ) ) { // This Point is inside, so check if the point is inside of a childwidget pReturnWidget = pWidget->getChildAtPoint( _uiX, _uiY ); // Do we have a child at this point? if( pReturnWidget != NULL ) return pReturnWidget; // return return pWidget; } I guess it depends on what is in m_liWidgets_Active list? Is this every widget? Maybe you do it differently than I do. What I do is create a container widget. I then add widget to that container widget as children. I then only add the container widget to the main gui manager list of widget. The only widgets are not added directly to this main gui manager list because they are indirectly there as children of the container widget.

Oh sweet. Where is that? Did you use that pathfinding code that recast uses also? Also from what I can see recast basically works on an obj file that would be your level. So since LE requires gmf files I assume this is a pre game process to calc the nav mesh on the obj file of your level, save it to disk, then read it in again in the game?

When it comes default with the library it's easier to use it because it's already built in than to make your own waypoints. I've actually just found the recast library last night and will be taking a look at it over time.

That would be one difference between LE and UDK right out of the gate then. LE users would have to make their own NavMesh code. That could be a chore right there.

How do you suppose they did the movement for the monsters? I'm not going to read that mess that is unreal script , just curious on what you guys think of a way to do that movement? Simple pivots and have them move point to point or what?

Very nice. I might have to give this a try.

But what about child's children and their children? That's my issue. Take a panel type control. Its parent is a sheet or form if you will, but it has children in it also. Now imagine embedding panel controls inside panel controls and then a button in that. There is this long chain of parent and children that goes past the first 2. That's the issue that I'm having. With the parent/child design you don't know how far the chain goes. That's why I need recursion.

Where is the recursive part? I don't see the recursion happening in what you posted.

Would be cool if you could rent the suite and software