mengecrowdsim / menge Goto Github PK

Should CMake fail, when requirements of Menge are not met?

The navigation mesh still has several issues:

Features

• Goals cannot be registered on a layer of a navigation mesh; they will all project down onto the highest level. This prevents the office scenario from actually being done in 3D.
  • Related, identity goals would cause an agent to move from where they start if they are not on the highest level when the identity goal is created.
• Planning on the navigation mesh doesn't properly respect clearance. If one of the polygons is a long skinny triangle, only the triangle edge lengths are considered and not whether or not an agent could actually traverse it.
• Planning is done w.r.t. the polygon's centroid. For large polygons, or polygons with strange aspect ratio, this becomes a bad approximation of the actual length of the path.
• Teleportation see related issues

Implementation

• The creation of the navigation mesh from the file description requires casting pointers as unsigned ints. This is not a good trick and has compilation issues on different compilers.
• Error handling (if positions/agents/goals/whatever be placed on the mesh). See related issue.

TODO: provide some examples that show these weaknesses.

Related issues:
#4 - Teleportation doesn't work on navigation meshes.
#2 - Silent crash when agents can't be placed on the navigation mesh.

I think the relevant infos are summed up in this screenshot.

I'm using: Windows 10 x64 (w/ May 31st, 2017 update) with VS Community 2013 and Menge v0.9.1.

From Menge v0.9.1, the file pluginMacros.props (w/ numbered lines) is displayed below:

1<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build" ToolsVersion="4.0">
2<ImportGroup Label="PropertySheets"></ImportGroup>
3<PropertyGroup Label="UserMacros">
4<MengeSrc>$(SolutionDir)..\..\..\src\Menge\</MengeSrc>
5<MengeLib>$(SolutionDir)..\Menge\build\lib</MengeLib>
6<PluginSrc>$(SolutionDir)..\..\..\src\Plugins</PluginSrc>
7</PropertyGroup>
8<PropertyGroup/>
9<ItemDefinitionGroup/>
10<ItemGroup/>
11</Project>

The extra ( \ ) on line 4 was carried over into paths using $(MengeSrc), resulting in paths with ( \\ ). Here is a .txt of the error in VS 13.

[SOLVED] Remove the extra ( \ ).
<MengeSrc>$(SolutionDir)..\..\..\src\Menge</MengeSrc>

The run example script doesn't work. The references are mostly out of date. It needs to be updated to use the project syntax.

When using the c-api, the getAgentPosition and getAgentVelocity methods take parameters for vectors in R^3, but the y-component is always zero. This is fine for simulations on the plane, but doesn't work for 3D heightfields or navigation meshes. The function needs to take the elevation into account.

Is there some known keystrokes that enables controling the visualisation?
pressing "space" starts the visualisation.

But, what about "back", "forth", "zoom", etc?

Using clang 3.5.0 under a mac I get compiler errors.

cmake -DCMAKE_CXX_COMPILER=clang-omp++  -DCMAKE_C_COMPILER=clang-omp   ..
make

The new examples\plugin\stressRegion.xml has a scenario with a central circular obstacle. As the agent approaches the obstacle, it ends up getting stuck on the obstacle. Two ORCA constraints are introduced that place the agent's velocity at a local minimum of zero.

Force-based agents get a force for every obstacle neighbor (so long as the force formulation's fall-off limit is not nearer than the obstacle). For these agents, more distant obstacles that are occluded by nearer obstacles should be automatically omitted from the neighbor set to avoid redundant, meaningless forces.

This becomes especially apparent in the maze scenario.

One of the design issues is to determine if complete occlusion is necessary, or if partial occlusion is sufficient to exclude an obstacle from the neighbor set. At the end of the day, the solution is probably a combination of occlusion and distance.

NOTE: This issue does not affect the RVO-derived models because the line constraints implicitly account for occlusion.

The hack that fixed the linux code for writing out scb files broke the windows build.

The constant BUFFSIZE had been killed and replaced with the posix constant PATH_MAX. PATH_MAX is not defined in windows. Thus the build fails because PATH_MAX is undefined.

Currently the log displays no time stamp info. While it would be overkill to apply it to ever log entry,
at the very least, the header should include time stamp info.

Menge currently uses pre-C++11 functionality. We should bring it up into the real world using unique_ptr's, C++ thread semantics, etc.

I've installed freeglut3-dev and mesa-utils, but I seem to be having the following error when calling make:

[ 79%] Building CXX object Menge/mengeMain/CMakeFiles/menge.dir/home/alyssa/Desktop/Menge-master/src/Menge/mengeMain/mengeMain.cpp.o Linking CXX executable /home/alyssa/Desktop/Menge-master/Exe/menge /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glCallList' /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glPopAttrib' /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glPointSize' /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glLoadName' /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glRenderMode' /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glBegin' /home/alyssa/Desktop/Menge-master/Exe/libmengeVis.so: undefined reference to 'glClear' ...

For the demo videos like for example this one

it would be helpful to have the project files so that people can try it.
(nice to have for lectures)

When an agent teleports from one location on a navigation mesh to a new location, the path planning algorithm uses the old position instead of the new position; the teleportation does not cause the navigation mesh to update its knowledge of the agent's localization.

This impact would only affect a single frame, because in the beginning of the next frame, the localization task would be responsible for re-aligning the nav mesh localizer's knowledge of the agent position. However, for that one time step, it would get the wrong elevation from a nav mesh elevation, it will get the wrong obstacles from the nav mesh obstacles, and path planning will be starting with the wrong initial point. Essentially, when an agent is being affected (in some way) by a navigation mesh, teleportation should cause the navigation mesh localizer to refresh.

In initializing a scene using a navigation mesh, if the agent generator seeks to place an agent at a position that doesn't align with the navigation mesh, menge crashes without any information in the log.

When using a navigation mesh-based spatial query object, when there is a navigation mesh polygon over an agent, the obstacles selected for that agent are the covering polygon and not the polygon the agent is actually on.

In the attached example (images shown below), the agent is walking down a ramp and about to cross under an overhang. As soon as the agent center crosses into the projection of the upper polygon, its obstacles will come from that polygon and the agent will not be able reach its goal because the upper polygon has an obstacle between the agent and its goal.

The project for evaluating this can be found below.

Fig 1. Agent walking down a ramp, underneath an overhang.

Fig 2. Agent about to pass under the overhang.

nav_mesh_fail.txt
nav_mesh_failB.txt
nav_mesh_failS.txt
nav_mesh_failV.txt
simple_NM.txt

I was trying to modify the built-in pedModelSwap example by adding one obstacle in the middle of the intersection. The only part that I modified is adding one obstacle in the pedModelSwapS.xml.
However, the obstacle seems to be invisible to agents in the beginning. Agents can enter inside of the obstacle (as shown in the Figure) rather than avoid it. After that, the agents seem to be trapped inside.
In order to make the obstacle visible, should I change something? Any suggestions? Thanks.

Add a new profile selector.

Select from a set of defined profiles with a weighted uniform probability. Looking something like this:

 <ProfileSelector type="weighted_set">
    <Profile name="named_profile" weight="1.0"/>
    <Profile name="named_profile2" weight="1.0"/>
    <Profile name="named_profile3" weight="0.5"/>
  </ProfileSelector>

The Menge code base isn't compatible with Visual Studio 2015. This is a known problem that comes down both to compilation as well as linker problems.

Hi, how can we open and see the output SCB file? Any software that we need to install? Thanks.

We desperately need unit testing and regression tests. Integrate google test and begin building test suites.

The configuration mechanism was intended with the following design:

1. Hard-coded default values serve as the default values.
2. Specifying the values in the project config file will replace the hard-coded values.
3. Any values provided on the command-line will trump all previous rules.

Currently, this isn't properly implemented. In mengeMain.cpp, the mapping from command-line arguments are handled incorrectly. The values for some unspecified command-line parameters are configured to render un-specified indistinguishable from configured.

• verbosity
• sub steps
• scb version
• seed

The solution is to change the command-line parser's default values and, in some cases, update the logic which conditionally sets the configuration parameters based on recognized user-values.

In some cases, it would be appropriate to issue a warning indicating recognition of a bad user-specified value.

There is no facility for placing agents on arbitrary levels of a navigation mesh. For example, if a two-story building were modeled with a navigation mesh, placement onto the mesh at position (x,y) would project the point down from an infinite height and stop at the first polygon encountered. Thus, if two polygons project to the same (x, y) point, an agent will only be initialized on the upper polygon.

Use Case:

to spawn new agents and to remove agents during simulation.

In XMLSimulatorBase.h

/*!
 *	@brief		Add an agent with specified position to the simulator whose properties
 *				are defined by the given agent initializer.
 *
 *	It uses the agent initializer to define the values of the remaining agent
 *	parameters.
 *
 *	@param		pos			The 2d vector representing the agent's position
 *	@param		agentInit	The AgentInitializer necessary to parse AgentSet properties
 *	@returns	A pointer to the agent (if initialization was succesful) or NULL if
 *				failed.
 */
virtual BaseAgent * addAgent( const Math::Vector2 & pos,  AgentInitializer * agentInit ) = 0;

The only way to add new agent is in SimXMLLoader.cpp

// Second pass, parse Generators
for( child = node->FirstChildElement(); child; child = child->NextSiblingElement()) {
	if ( child->ValueStr() == "Generator" ) {
		AgentGenerator * generator = AgentGeneratorDB::getInstance( child,
																	_sceneFldr );

		if ( generator == 0x0 ) {
			logger << Logger::ERR_MSG << "Unable to instantiate agent generator "
				"specifcation on line " << child->Row() << ".";
			return false;
		}
		// Now instantiate the agents
		const size_t AGT_COUNT = generator->agentCount();
		Vector2 zero;
		for (size_t i = 0; i < AGT_COUNT; ++i) {
			BaseAgent * agent = _sim->addAgent(zero, profileSel->getProfile());
			generator->setAgentPosition(i, agent);
			_sim->getInitialState()->setAgentState(agent->_id, stateSel->getState());
		}
		_agtCount += (unsigned int)AGT_COUNT;

		generator->destroy();
	}
}

if we could expose SimulatorInterface in menge_c_api.h

class MENGE_API SimulatorInterface: public XMLSimulatorBase

we can get into the getInitialState() of XMLSimulatorBase to:

/*!
 *	@brief		Sets the state for the given agent.
 *
 *	@param		id			The identifier of the agent.
 *	@param		stateName	The name of the state to which the agent belongs.
 */
_sim->getInitialState()->setAgentState(agent->_id, stateSel->getState());

OR

/*!
 *	@brief		Reports the state name for the given agent.
 *
 *	@param		id			The identifier of the agent.
 *	@returns	The name of this agent's start state.
 */
const std::string getAgentState( size_t id ) const;

The dll should report its version and be queryable.

The roadmap is not currently well defined. It is our hope to engage our user base in helping us define a high utility roadmap (and our further hope that our users will help us implement it as well.) We'd like to maximize community engagement. So, let's talk about what we'd like to see and what's important to us.

The Menge team has provided an initial list here. Weigh in on your own desires and thoughts.

Following the instructions here

I' m trying to compile Menge in

cmake says something about MACOSX_RPATH.

  MACOSX_RPATH is not specified for the following targets:

   aircraft
   dummyPed
   formations
   fundDiag
   helbingPed
   johanssonPed
   karamouzasPed
   mengeCore
   stressGas
   terrain
   zanlungoPed

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/chraibi/Workspace/Menge/projects/g++

Ignoring this warning (apparently not a good idea) leads to make error:

g++ (master*) » make
[  3%] Built target tinyxml
[  3%] Building CXX object Menge/MengeCore/CMakeFiles/mengeCore.dir/Users/chraibi/Workspace/Menge/src/Menge/MengeCore/Agents/AgentGenerators/AgentGenerator.cpp.o
In file included from /Users/chraibi/Workspace/Menge/src/Menge/MengeCore/Agents/AgentGenerators/AgentGenerator.cpp:39:
In file included from /Users/chraibi/Workspace/Menge/projects/g++/../../src/Menge/MengeCore/Agents/AgentGenerators/AgentGenerator.h:47:
In file included from /Users/chraibi/Workspace/Menge/projects/g++/../../src/Menge/MengeCore/mengeCommon.h:56:
/Users/chraibi/Workspace/Menge/projects/g++/../../src/Menge/include/macros.h:15:11: fatal error:
      'tr1/unordered_map' file not found
        #include <tr1/unordered_map>
                 ^
1 error generated.
make[2]: *** [Menge/MengeCore/CMakeFiles/mengeCore.dir/Users/chraibi/Workspace/Menge/src/Menge/MengeCore/Agents/AgentGenerators/AgentGenerator.cpp.o] Error 1
make[1]: *** [Menge/MengeCore/CMakeFiles/mengeCore.dir/all] Error 2
make: *** [all] Error 2

Any help is appreciated. ;-)

PS: I'm trying to compile Menge "out of the box". Maybe I could use it for demo purposes in my classes.

For now the Goals class define a number of good primitives (e.g. point, circle, AABB, and OBB) and operations on those primitives (e.g., squared distance, direction towards closest point, get centroid, etc.). It is impossible to re-use this functionality in a more generic manner. Furthermore, the ability to parse such a shape from the XML would be of use in multiple locations.

It would be good if this functionality and logic were refactored into a more generic context such that other entities could make use of them.

is it possible to integrate Menge to be called by a third party software which provide the two input files and receive e.g. as callback the simulated agent coordinates? If so, how to go about it

Why running

    ./menge -p ../examples/core/headon.xml

yields

** Demo doc read from disk: ** 

** Printing via doc.Print **
<?xml version="1.0" standalone="no" ?>
<!-- Our to do list data -->
<ToDo>
    <!-- Do I need a secure PDA? -->
    <Item priority="1" distance="close">Go to the
        <bold>Toy store!</bold>
    </Item>
    <Item priority="2" distance="none">Do bills</Item>
    <Item priority="2" distance="far &amp; back">Look for Evil Dinosaurs!</Item>
</ToDo>
** Printing via TiXmlPrinter **
<?xml version="1.0" standalone="no" ?>
<!-- Our to do list data -->
<ToDo>
    <!-- Do I need a secure PDA? -->
    <Item priority="1" distance="close">
        Go to the
        <bold>Toy store!</bold>
    </Item>
    <Item priority="2" distance="none">Do bills</Item>
    <Item priority="2" distance="far &amp; back">Look for Evil Dinosaurs!</Item>
</ToDo>
** Printing via operator<< **
<?xml version="1.0" standalone="no" ?><!-- Our to do list data --><ToDo><!-- Do I need a secure PDA? --><Item priority="1" distance="close">Go to the<bold>Toy store!</bold></Item><Item priority="2" distance="none">Do bills</Item><Item priority="2" distance="far &amp; back">Look for Evil Dinosaurs!</Item></ToDo>
** Demo doc processed: ** 

<?xml version="1.0" standalone="no" ?>
<!-- Our to do list data -->
<ToDo>
    <!-- Do I need a secure PDA? -->
    <Item priority="2" distance="close">Go to the
        <bold>Toy store!</bold>
    </Item>
    <Item priority="1" distance="far">Talk to:
        <Meeting where="School">
            <Attendee name="Marple" position="teacher" />
            <Attendee name="Voel" position="counselor" />
        </Meeting>
        <Meeting where="Lunch" />
    </Item>
    <Item priority="2" distance="here">Do bills</Item>
</ToDo>
** Demo doc processed to stream: ** 

<?xml version="1.0" standalone="no" ?><!-- Our to do list data --><ToDo><!-- Do I need a secure PDA? --><Item priority="2" distance="close">Go to the<bold>Toy store!</bold></Item><Item priority="1" distance="far">Talk to:<Meeting where="School"><Attendee name="Marple" position="teacher" /><Attendee name="Voel" position="counselor" /></Meeting><Meeting where="Lunch" /></Item><Item priority="2" distance="here">Do bills</Item></ToDo>

** Basic structure. **
[pass] Output stream correct.
[pass] Root element exists. [1][1]
[pass] Root element value is 'ToDo'. [ToDo][ToDo]
[pass] First child exists & is a comment. [1][1]
[pass] Sibling element exists & is an element. [1][1]
[pass] Value is 'Item'. [Item][Item]
[pass] First child exists. [1][1]
[pass] Value is 'Go to the'. [Go to the][Go to the]

** Iterators. **
[pass] Top level nodes, using First / Next. [3][3]
[pass] Top level nodes, using Last / Previous. [3][3]
[pass] Top level nodes, using IterateChildren. [3][3]
[pass] Children of the 'ToDo' element, using First / Next. [3][3]
[pass] 'Item' children of the 'ToDo' element, using First/Next. [3][3]
[pass] 'Item' children of the 'ToDo' element, using Last/Previous. [3][3]

** Parsing. **
[pass] Element parsed, value is 'Element0'. [Element0][Element0]
[pass] Reads attribute 'attribute0="foo0"'. [foo0][foo0]
[pass] Reads incorrectly formatted 'attribute1=noquotes'. [noquotes][noquotes]
[pass] Read attribute with entity value '>'. [>][>]
[pass] Error row [3][3]
[pass] Error column [17][17]

** Streaming. **
[pass] Stream round trip correct.
[pass] String printing correct.
[pass] Query attribute: int as double [0][0]
[pass] Query attribute: int as double [1][1]
[pass] Query attribute: double as double [2][2]
[pass] Query attribute: double as int [0][0]
[pass] Query attribute: double as int [2][2]
[pass] Query attribute: not a number [2][2]
[pass] Query attribute: does not exist [1][1]
[pass] Location tracking: Tab 8: room row [1][1]
[pass] Location tracking: Tab 8: room col [49][49]
[pass] Location tracking: Tab 8: doors row [1][1]
[pass] Location tracking: Tab 8: doors col [55][55]
[pass] Location tracking: Declaration row [1][1]
[pass] Location tracking: Declaration col [5][5]
[pass] Location tracking: room row [1][1]
[pass] Location tracking: room col [45][45]
[pass] Location tracking: doors row [1][1]
[pass] Location tracking: doors col [51][51]
[pass] Location tracking: Comment row [2][2]
[pass] Location tracking: Comment col [3][3]
[pass] Location tracking: text row [3][3]
[pass] Location tracking: text col [24][24]
[pass] Location tracking: door0 row [3][3]
[pass] Location tracking: door0 col [5][5]
[pass] Location tracking: door1 row [4][4]
[pass] Location tracking: door1 col [5][5]

** UTF-8 **
WARNING: File 'utf8test.xml' not found.
(Are you running the test from the wrong directory?)
Could not test UTF-8 functionality.

** Copy and Assignment **
[pass] Copy/Assign: element copy #1. [element][element]
[pass] Copy/Assign: element copy #2. [value][value]
[pass] Copy/Assign: element assign #1. [element][element]
[pass] Copy/Assign: element assign #2. [value][value]
[pass] Copy/Assign: element assign #3. [1][1]
[pass] Copy/Assign: comment copy. [comment][comment]
[pass] Copy/Assign: comment assign. [comment][comment]
[pass] Copy/Assign: unknown copy. [[unknown]][[unknown]]
[pass] Copy/Assign: unknown assign. [[unknown]][[unknown]]
[pass] Copy/Assign: text copy. [TextNode][TextNode]
[pass] Copy/Assign: text assign. [TextNode][TextNode]
[pass] Copy/Assign: declaration copy. [UTF-8][UTF-8]
[pass] Copy/Assign: text assign. [UTF-8][UTF-8]
[pass] Copy/Assign: document copy.
[pass] Copy/Assign: document assign.

** Parsing, no Condense Whitespace **
[pass] Condense white space OFF.
[pass] GetText() normal use. [This is text][This is text]
[pass] GetText() contained element. [1][1]
[pass] GetText() partial. [This is ][This is ]
<xmlElement>
    <![CDATA[I am > the rules!
...since I make symbolic puns]]>
</xmlElement>
[pass] CDATA parse.
[pass] CDATA stream.
[pass] CDATA copy.
[pass] CDATA with all bytes #1.
[pass] CDATA with all bytes #2.
<xmlElement>
    <![CDATA[<b>I am > the rules!</b>
...since I make symbolic puns]]>
</xmlElement>
[pass] CDATA parse. [ 1480107 ]
[pass] CDATA stream. [ 1480107 ]
[pass] CDATA copy. [ 1480107 ]

** Fuzzing... **
** Fuzzing Complete. **

** Bug regression tests **
[pass] Test InsertBeforeChild on empty node. [1][1]
[pass] Test InsertAfterChild on empty node.  [1][1]
[pass] Entity transformation: read. 
[pass] Entity transformation: write. 
[pass] dot in element attributes and names [0][0]
[pass] Entity with one digit. [1][1]
[pass] Entity with one digit. [1.1 Start easy ignore fin thickness
][1.1 Start easy ignore fin thickness
]
[pass] Correct value of unknown. [!DOCTYPE PLAY SYSTEM 'play.dtd'][!DOCTYPE PLAY SYSTEM 'play.dtd']
[pass] Correct streaming of unknown. [<!ELEMENT title (#PCDATA)>][<!ELEMENT title (#PCDATA)>]
[pass] Comment formatting. [ Somewhat<evil> ][ Somewhat<evil> ]
[pass] Comment streaming. [<!-- Somewhat<evil> -->][<!-- Somewhat<evil> -->]
[pass] White space kept. [ This has leading and trailing space ][ This has leading and trailing space ]
[pass] White space kept. [This has  internal space][This has  internal space]
[pass] White space kept. [ This has leading, trailing, and  internal space ][ This has leading, trailing, and  internal space ]
[pass] White space condensed. [This has leading and trailing space][This has leading and trailing space]
[pass] White space condensed. [This has internal space][This has internal space]
[pass] White space condensed. [This has leading, trailing, and internal space][This has leading, trailing, and internal space]
[pass] Parsing repeated attributes. [0][0]
[pass] Parsing repeated attributes. [blue][blue]
[pass] Embedded null throws error. [1][1]
[pass] Embedded null throws error. [1][1]
[pass] ISO-8859-1 Parsing. [C�nt�nt�������][C�nt�nt�������]
[pass] Empty document error TIXML_ERROR_DOCUMENT_EMPTY [13][13]
[pass] Test safe error return. [0][0]
[pass] Low entities. [�][�]
<test>&#x0E;</test>
[pass] Throw error with bad end quotes. [1][1]
[pass] QueryValueAttribute [0][0]
[pass] QueryValueAttribute [0][0]
[pass] QueryValueAttribute [0][0]
[pass] QueryValueAttribute [2][2]
[pass] QueryValueAttribute [1][1]
[pass] QueryValueAttribute [1][1]
[pass] QueryValueAttribute [1][1]
[pass] QueryValueAttribute [1][1]
[pass] Attribute [0][0]
[pass] Attribute [1][1]
[pass] Attribute [1][1]
[pass] Document only at top level. [1][1]
[pass] Document only at top level. [16][16]
[pass] Missing end tag at end of input [1][1]
[pass] Missing end tag with trailing whitespace [1][1]
[pass] Comments ignore entities.
[pass] Comments ignore entities.
[pass] Comments ignore entities.
[pass] Comments ignore entities.

Pass 119, Fail 0
Program ended with exit code: 0

Attributes can be configured and automatically parsed of various types (ints, floats, strings, even distributions of numbers.) It would be good if an enumeration could be provided such that only a set of strings (case insensitive) would be successfully parsed and an enumeration value would be returned.

Hi, I am trying to compile the project on Mac, I tried to use Apple llvm+clang, and brew installed llvm with clang, both of them have "cannot found OpenMP" error, then I moved on to gcc and g++, using the command like:
cmake -DCMAKE_C_COMPILER=gcc-7 -DCMAKE_CXX_COMPILER=g++-7 -DOpenMP_C_FLAGS=-fopenmp -D CMAKE_MACOSX_RPATH=1 ..
cmake succeed. However, when I tried the make command, I met "the duplicate symbol" error:

...
duplicate symbol float Menge::Math::abs(Menge::Math::Vector2d const&) in:
CMakeFiles/mengeCore.dir/Users/leizhang/Projects/Laipac/src/Menge/MengeCore/Agents/AgentGenerators/AgentGenerator.cpp.o
CMakeFiles/mengeCore.dir/Users/leizhang/Projects/Laipac/src/Menge/MengeCore/resources/WayPortal.cpp.o
duplicate symbol float Menge::Math::absSq(Menge::Math::Vector2d const&) in:
CMakeFiles/mengeCore.dir/Users/leizhang/Projects/Laipac/src/Menge/MengeCore/Agents/AgentGenerators/AgentGenerator.cpp.o
CMakeFiles/mengeCore.dir/Users/leizhang/Projects/Laipac/src/Menge/MengeCore/resources/WayPortal.cpp.o
ld: 12660 duplicate symbols for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [/Users/leizhang/Projects/Laipac/Exe/libmengeCore.dylib] Error 1
make[1]: *** [Menge/MengeCore/CMakeFiles/mengeCore.dir/all] Error 2
make: *** [all] Error 2

Is this the same problem as what described in #28 ? Any suggestions about the solution? Thanks.

Hi,

In Menge, is there a "magic" setting to disable or enable the GUI as needed?
If it has to be done in the source code, what do you suggest as a starting point?

Thanks a lot.

in #28 I had an OpenGL-related error.

Can FindOpenGL be used
in order to avoid this problem at compile time?

(used in another CMakeFile.txt)

The menge core currently encompasses simulation, visualization, command-line parsing, etc. This means if components (e.g., simulation) would be applied elsewhere, we have to drag along all of the dynamic libraries that mengeCore.dll is currently dependent on.

It would be better if menge was decomposed more strategically so that only those components of interest would be used.

As exposed in #47, the Action for resizing agents does not work with the elliptical GCF agents.

We need to introduce an interface that can account for arbitrary geometries that can be scaled and offset and appropriately restored.

Design idea

Give agents a "size" member. This is a virtual class: AgentSize. It can clone itself into a an instance that can be stored indpendently of the Agent. It supports operations such as scale and offset. It also supports "resetting" from another instance (e.g., the one that was cached.) The AgentProperty action will request the agent's size (at which point, it receives a clone of the original size). The AgentProperty owns this instance and will destroy it when it is finished with the agent (optionally resetting the agent size by passing the cached size object back.)

This might also have to address the concept of "radius" as a BaseAgent property. Perhaps it would be better as "size" or "scale", and have each agent type interpret size to mean something specific.

Adding

if(APPLE)
    set(CMAKE_MACOSX_RPATH ON)
endif()

in Menge/CMakeLists.txt and Plugins/CMakeLists.txt resolves these warnings and let Cmake correctly handles RPATH on OSX.

An earlier question had asked about running a scenario shown in a video (e.g., here (see #27.) These videos should come with clear instructions for locating the project files in the examples data and how to run them.

Currently, the "environment" is drawn as line segments for the obstacles (and, even now they aren't drawn well -- see #10 ). It would be good if we could import arbitrary geometric meshes to draw the agents on that environment.

First round would simply be illuminated materials.
Second round could include texture (and, generally, more advanced materials).

The big question is, should Menge be producing its own graphics engine, or is it time to tie it into something else?

The documentation for the --view parameter talks about a non-existent -i/--interactive argument. The documentation should be cleaned up.

Simply put, the Johannson model is broken. Agents pass through each other and obstacles.

The funnel algorithm creates a piecewise linear path where each segment of the path is delimited by polygon boundaries (i.e., interior edges). In some scenarios, a series of such line segments are actually co-linear and it is some distance away that an actual turn enters the scenario. This is a simple implementation and guarantees a collision-free path, but it has an issue.

If, for dynamic reasons, the agent is not able to cross the interior edge at the point on the funnel path, the agent will have an irrational desire to cross at that point. This leads to unnatural behavior (particularly for agents that lack the ability to use the full PreferredVelocity which would account for the portal width).

It is impractical to attempt to get every agent type to be able to reason about PreferredVelocity properly. So, that means the path itself should be smarter.

Proposal:

Coalesce colinear segments in the funnel path so that it only hinges on true direction changes. As the agent veers off to the side, it can cross the portal in a different direction.

Challenge: in this case, it is possible for the line segment connecting the current agent position to the next turning point to intersect an obstacle (the straight-line path is not collision free). We would have to do a test at every time step to see if the current path direction passes safely through the next portal.

• If the next turning point is in the next portal, it should trivially be true by construction.
• Otherwise, if the line intersects the portal with sufficient clearance, it is true.
• Finally, if it doesn't intersect the portal with enough clearance (or at all), the path should be broken to turn at the nearest point in the next portal that provides clearance.

NOTE: this still does not solve the problem where the next portal already has a turning point and the agent can't get to it. The flipside of this idea is to look forward as well. So, more generally, the goal would be to add and remove turning points dynamically to account for drift due to dynamic limitations in following the static path.

There are places in the code where some code is in place to support assertions. By design, assertions should be executed only in some form of debug mode. The code exhibits aspects like:

#if _DEBUG
...
#endif

Under g++ the documentation suggests that assert method are invoked unless the symbol NDEBUG is found prior to reading the cassert header. That would suggest a change to this:

#ifndef NDEBUG
...
#endif

It is important to make sure this solution works both in linux and windows. Does windows use the _DEBUG instead? Either way, this needs to be addressed to work with older compilers and g++5.

See #28 for an example.

The KD-tree implementation for spatial queries ends up breaking obstacles into sub-obstacles. I.e., a single segment can be decomposed into a set of disjoint subsets spanning the same wall. Some algorithms can detect these co-linear and coincident segments and handle it. Some cannot.

Force-based models create a repulsive force for each obstacle. That means, a single wall, depending on how it is dissected, could end up introducing multiple forces (giving an overall greater repulsive force for that wall.)

If an underlying algorithm decomposes the specified obstacles into sub-obstacles, this should be hidden from the pedestrian algorithms.

To that end, modify the KD-tree so that the obstacles it uses have knowledge about the "original" obstacle from whence it arose. When performing spatial queries, don't return the kd-tree obstacle, return the parent obstacle. In this case, it is possible that the same obstacle can be returned multiple times; it should be accounted for in building the neighbor set.

When a scene uses an Elevation element, the obstacles are drawn inaccurately. The end points of the obstacles are not being projected onto the correct point; this is particularly the case w.r.t. navigation mesh elevation elements.

We need an elevation-agnostic method of making sure the obstacles get drawn correctly.

Fig 1a. nav_mesh_placement with the rendered obstacles.

Fig 1b. nav_mesh_placement with actual obstacles rendered with navigation mesh.

Fig 2a navMesh scenario with the rendered obstacles.

Fig 2b navMesh scenario with true obstacles rendered wit the navigation mesh.

Apparently, providing the scb file argument to the linux build causes the system to hang.

Example:
./menge -p ../examples/core/headon.xml -o test.scb

Hi, I have a naive question here - can we convert the distance and speed units in Menge's local coordinate system to the corresponding units in real world?
For example, in the scene specification, when we set neighbor_dist="1", can we say that "1" equals to "x" meters (where "x" is the physical space in real world)?
Another example is the speed, e.g., pref_speed="1.04", can we convert its unit to meters per second?
Thanks.

In the event.xml example, the agents reach a state where moving agents enter a domain of stationary agents. The agents begin spinning violently.

To see:

menge.exe -m gcf --subSteps 19 -p ..\examples\core\event.xml