I would like to ask how tileLayers in detour work.
Can i layer any 2 tiles resulting in "cuts" being merged into bigger holes and in what manner, are there any limitations? How many of these layers can i have and how they interact when navigating. Can i have for example basic always unchanged layer with whole map and then multiple layers with user placed geometry etc...
I'am talking about dtNavMeshCreateParams::tileLayer from original lib. There is some implementation using it in TempObstackes example. But it is not well explained (it has many custom things inside but i'am interested only in function of those layers)
Thank you in advance, i cant find much info about this online so any help would really be appreceated.
So actually i finally (many hours) found my answer to what these layers are used for:
http://digestingduck.blogspot.com/2011/02/heightfield-layer-portals.html
(btw this seems to be blog of navmesh lib author, enjoy)
When importing CAD file like STL format file, sometimes, some of the facets are reversed so their normal vectors are directing inside the volume while others going outside. the "recalculate outside" comes in to fix the situation.
But, I am wondering how I can implement the function with CGAL. It would be appreciated if some guy show me the way about hint or code snippet.
Thanks in advance.
The Polygon Mesh Processing package introduced in CGAL 4.7 might help here.
In particular I think the function orient_polygon_soup() is what you need. Here is an example of how to use it.
You might also need the function polygon_soup_to_polygon_mesh()
for quite some time I've been working on an application. As programming is just a hobby this project is already taking way too long, but that's besides the point. I'm now at a point where every "problem" becomes terribly difficult to solve. And I'm thinking of refactoring the code, however that would result in a "complete" rewrite.
Let me explain the problem, and how I solved it currently. Basically I have data, and I let things to happen over this data (well I described about every program didn't I?). What happens is:
Data -> asks viewer to display -> viewer displays data based on actual data
viewer returns user input -> data -> asks "executor" to execute it -> new data
Now this used to work very well, and I was thinking originally "hey I might for example change command prompt by qt, or windows - or even take that external (C#) and simply call this program".
However as the program grew it became more and more tiresome. As the most important thing is that the data is displayed in different manners depending on what the data is and -more importantly- where it is located. So I went back to the tree & added someway to "track" what the parent-line is". Then the general viewer would search for the most specific actual widget.
It uses has a list with [location; widget] values, and finds the best matching location.
The problems starts when updating for new "data" - I have to go through all the assets - viewer, saver etc etc. Updating the check-mechanism gave me a lot of errors.. Things like "hey why is it displaying the wrong widget now again?".
Now I can completely swap this around. And instead of the tree datastructure calling to a generic viewer. I would use OO "internal" tree capabilities. The nodes would be childs (& when a new viewer or save-mechanism is needed a new child is formed).
This would remove the difficult checking mechanism, where I check the location in the tree. However it might open up a whole other can of worms.
And I'd like some comments on this? Should I keep the viewer completely separate - having difficulty checking for data? Or is the new approach better, yet it combines data & execution into a single node. (So if I wish to change from qt to say cli/C# it becomes almost impossible)
What method should I pursue in the end? Also is there something else I can do? To keep the viewer separate, yet prevent having to do checks to see what widget should be displayed?
EDIT, just to show some "code" and how my program works. Not sure if this is any good as I said already it has become quite a clusterfuck of methodologies.
It is meant to merge several "gamemaker projects" together (as GM:studio strangely lacks that feature). Gamemaker project files are simply sets of xml-files. (Main xml file with only links to other xml files, and an xml file for each resource -object, sprite, sound, room etc-). However there are some 'quirks' which make it not really possible to read with something like boost property trees or qt: 1) order of attributes/child nodes is very important at certain parts of the files. and 2) white space is often ignored however at other points it is very important to preserve it.
That being said there are also a lot of points where the node is exactly the same.. Like how a background can have <width>200</width> and a room too can have that. Yet for the user it is quite important which width he is talking about.
Anyways, so the "general viewer" (AskGUIFn) has the following typedefs to handle this:
typedef int (AskGUIFn::*MemberFn)(const GMProject::pTree& tOut, const GMProject::pTree& tIn, int) const;
typedef std::vector<std::pair<boost::regex, MemberFn> > DisplaySubMap_Ty;
typedef std::map<RESOURCE_TYPES, std::pair<DisplaySubMap_Ty, MemberFn> > DisplayMap_Ty;
Where "GMProject::pTree" is a tree node, RESOURCE_TYPES is an constant to keep track in what kind of resource I am at the moment (sprite, object etc). The "memberFn" will here simply be something that loads a widget. (Though AskGUIFn is not the only general viewer of course, this one is only opened if other "automatic" -overwrite, skip, rename- handlers have failed).
Now to show how these maps are initialized (everything in namespace "MW" is a qt widget):
AskGUIFn::DisplayMap_Ty AskGUIFn::DisplayFunctionMap_INIT() {
DisplayMap_Ty t;
DisplaySubMap_Ty tmp;
tmp.push_back(std::pair<boost::regex, AskGUIFn::MemberFn> (boost::regex("^instances "), &AskGUIFn::ExecuteFn<MW::RoomInstanceDialog>));
tmp.push_back(std::pair<boost::regex, AskGUIFn::MemberFn> (boost::regex("^code $"), &AskGUIFn::ExecuteFn<MW::RoomStringDialog>));
tmp.push_back(std::pair<boost::regex, AskGUIFn::MemberFn> (boost::regex("^(isometric|persistent|showcolour|enableViews|clearViewBackground) $"), &AskGUIFn::ExecuteFn<MW::ResourceBoolDialog>));
//etc etc etc
t[RT_ROOM] = std::pair<DisplaySubMap_Ty, MemberFn> (tmp, &AskGUIFn::ExecuteFn<MW::RoomStdDialog>);
tmp.clear();
//repeat above
t[RT_SPRITE] = std::pair<DisplaySubMap_Ty, MemberFn>(tmp, &AskGUIFn::ExecuteFn<MW::RoomStdDialog>);
//for each resource type.
Then when the tree datastructure tells the general viewer it wishes to be displayed the viewer executes the following function:
AskGUIFn::MemberFn AskGUIFn::FindFirstMatch() const {
auto map_loc(DisplayFunctionMap.find(res_type));
if (map_loc != DisplayFunctionMap.end()) {
std::string stack(CallStackSerialize());
for (auto iter(map_loc->second.first.begin()); iter != map_loc->second.first.end(); ++iter) {
if (boost::regex_search(stack, iter->first)) {
return iter->second;
}
}
return map_loc->second.second;
}
return BackupScreen;
}
And this is where the problems began to be frank. The CallStackSerialize() function depends on a call-stack.. However that call_stack is stored inside a "handler". I stored it there because everything starts FROM a handler. I'm not really sure where I ought to store this "call_stack". Introduce another object that keeps track of what's going on?
I tried going the route where I store the parent with the node itself. (Preventing the need for a call-stack). However that didn't go as well as I wished: each node simply has a vector containing its child nodes. So using pointers is out of the question to point to the parent note...
(PS: maybe I should reform this in another question..)
Refactoring/rewriting this complicated location checking mechanism out of the viewer into a dedicated class makes sense, so you can improve your solution without affecting the rest of your program. Lets call this NodeToWidgetMap.
Architecture
Seems your heading towards a Model-View-Controller architecture which is a good thing IMO. Your tree structure and its nodes are the models, where as the viewer and the "widgets" are views, and the logic selecting widgets depending on the node would be part of a controller.
The main question remains when and how you choose the widget wN for a given node N and how to store this choice.
NodeToWidgetMap: When to choose
If you can assume that wN does not change during its lifetime even though nodes are moved, you could choose it right when creating the node . Otherwise you'll need to know the location (or path through the XML) and, in consequence, find the parent of a node when requesting it.
Finding Parent Nodes
My solution would be to store pointers to instead of the node instances themselves, perhaps using boost::shared_ptr. This has drawbacks, for example copying nodes forces you to implement your own copy-constructors that uses recursion to create a deep-copy of your sub-tree. (Moving however will not affect the child nodes.)
Alternatives exist, such as keeping child nodes uptodate whenever touching the parent node respective the grandfathers vector. Or you can define a Node::findParentOf(node) function knowing that certain nodes can only (or frequently) be found as child of certain nodes. This is brute but will work reasonably well for small trees, just does not scale very well.
NodeToWidgetMap: How to choose
Try writing down the rules how to choose wN on piece of paper, perhaps just partially. Then try to translate these rules into C++. This might slightly longer in terms of code but will be easier to understand and maintain.
Your current approach is to use regular expressions for matching the XML path (stack).
My idea would be to create a lookup graph whose edges are labelled by the XML element names and whose nodes indicate which widget shall be used. This way your XML path (stack) describes a route through the graph. Then the question becomes whether to explicitly model a graph or whether a group of function calls could be used to mirror this graph.
NodeToWidgetMap: Where to store choice
Associating a unique, numeric id to each node, record the widget choice using a map from node id to widget inside the NodeToWidgetMap.
Rewriting vs Refactoring
If you rewrite you might get good leverage tieing to an existing framework such as Qt in order to focus on your program instead of rewriting the wheels. It can be easier to port a well-written program from on framework to another than to abstract around the pecularities of each platform. Qt is a nice framework for gaining experience and good understanding of the MVC-architectures.
A complete rewrite gives you a chance to rethink everything but implies the risk that you start from scratch and will be without a new version for a good amount of time. And who knows whether you will have enough time to finish? If you choose to refactor the existing structures you will improve it step by step, having a useable version after each step. But there is small risk to remain trapped in old ways of thinking, where as rewriting nearly forces you to rethink everything. So both approaches have their merits, if you enjoy programming I would rewrite. More programming, more joy.
Welcome to the world of programming!
What you describe is the typical life cycle of an application, starts as a small simple app, then it gets more and more features until it is no longer maintainable. You can't imagine how many projects I've seen in this last collapsing phase!
Do you need to refactor? Of course you do! All the time! Do you need to rewrite everything? Not so sure.
In fact the good solution is to work by cycles: you design what you need to code, you code it, you need more functionality, you design this new functionality, you refactor the code so you can integrate the new code, etc. If you don't do it like this then you will arrive to the point where its less expensive to rewrite then to refactor. Get this book: Refactoring - Martin Fowler. If you like it then get this one: Refactoring to Patterns.
As Pedro NF said, Martin Fowler "Refactoring" is the nice place to get familiar with it.
I recommend buying a copy of Robert Martins "Agile Principles, Patterns and Practices in C#" He goes over some very practical case studies that show how to overcome maintenance problems like this.
i'm developing some kind of heuristics for a variation of the vehicle-routing-problem in C++.
After generating a solution, i want to plot this solution. The solution is a composite of various tours, all starting and ending at a common depot.
Therefore i have a vertex-set with all the coordinates and edges defined by two vertex-id's each. Furthermore i have all the distances between vertex-pairs of course.
It would be helpful to plot this in an extra-window opening in my program, but writing a plot to a graphics-file should be okay too.
What is an easy way to plot this? How would you tackle this?
First i tried to look for common graph-visualization packages (graphviz, tulip, networkx (python)), but i realized that all of them are specialized at graph-layouting (when there are no coordinates). Correct me when i'm wrong.
I don't know if it is possible to tell these packages that i already have the coordinates, helping the layouting-algorithms.
Next thing i tried is the CGAL library with geomview output -> no luck until now -> ubuntu crashes geomview.
One more question: Is it a better idea to use some non-layouting 2d-plot-libraries risking a plot, which isn't really good to view at (is there more to do than scaling?) or to use some layout-algorithm-based-libraries (e.g. graphviz, tulip, networkx), feed them with the distances between the vertices and hope the layouting-algorithms are keeping the distances while plotting in a good-to-view-at way?
If non-layouting-plotting is the way to do it: which library do you recommend?
If layout-based-plotting is the way to do it: how can i make use of the distances/coordinates in these libraries? And which library do you recommend?
Thanks for all your input!
Sascha
EDIT: I completed a prototype implementation using the PLplot library (http://plplot.sourceforge.net/). The results are nice and should be enough for the moment. I discovered and chosed this library because a related project (VRPH Software Package / Groer) used this plot and the source code was distributed. So the implementation was done in a short amount of time. The API is in my opinion bit awkward and low-level. Maybe there are some more modern (maybe not a c-based library) libraries out there? MathGL? Dislin? Maybe i will try them too.
The nice thing about drawing multiple tours in a vehicle routing problem is that "not so bad" algorithms tend to discover nice non-overlapping and divergent tours which is really good for the eye ;-)
It is not quite clear what you are trying to archive, but if I understand your question correctly, then you could do it using OpenGL. Having vertex coordinates, it should be fairly easy.
You can use Gnuplot with a input text file that contains your solution.
It is convenient to draw the points (vertex) then lines (agents paths) than link them.
To make the plot script easy, you can have a separate file for each vehicle, if the number
of vehicles is known.
check out:
http://www.cleveralgorithms.com/nature-inspired/advanced/visualizing_algorithms.html
I want to write a program for UNIX in C++ with GUI (planning it to be Qt). I haven't learned the Qt library yet btw. I want the program to be like a world map that will be divided into many cells like a grid(the grid shouldn't be visible) and when i start to ping some IP it will show me that IP location on the world map (select it like a highlight dot or something). The part for the ip discovery is finished and it successfully locates the location of the ip (via whois). Now what remains is the Gui part, which i guess is not that easy.
So i was looking for any ideas how to do the task ? Whoever had experience with similar issue - please write your suggestions and advices, or maybe some nice snippets of code.
It actually is pretty easy. Using Qt and its GraphicsView framework. Just display a big world map and draw a dot where you want.
However, converting lon:lat coordinates to x:y needs some basic maths (you can find formulaes by googling. It will depend on the projection of your map).
Another possiblity is to use existing map tiles (like from openstreet map). Look at
http://labs.trolltech.com/blogs/2009/08/04/openstreetmap-and-qt-and-s60/
http://labs.trolltech.com/blogs/2009/07/29/maps-with-a-magnifying-glass/
Have fun!