Redmine: Issueshttp://dev.invrs.org/http://dev.invrs.org/favicon.ico?14046506542015-04-21T12:39:15ZRedmine
Redmine inVRs - Refactor #58 (Resolved): inVRs uses std::auto_ptr in several placeshttp://dev.invrs.org/issues/582015-04-21T12:39:15ZJohannes Zarl-Zierl
<p>Occurrences of std::auto_ptr should be replaced with C++11 smart pointers where available.</p> inVRs - Bug #57 (New): CollisionMap indirectly relies on undefined behaviour (warning -Waggressiv...http://dev.invrs.org/issues/572015-04-21T12:35:33ZJohannes Zarl-Zierl
<p>Compiling with a gcc 4.9.1, the following compilation warning is issued:<br /><pre>
[ 58%] Building CXX object tools/libraries/CollisionMap/CMakeFiles/inVRsCollisionMapBase.dir/CollisionLineSet.cpp.o
In file included from /home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/Xforms.h:12:0,
from /home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/Generate.h:21,
from /home/edvz/zing/scratch/inVRs_OSG/src/inVRs/SystemCore/DataTypes.h:42,
from /home/edvz/zing/scratch/inVRs_OSG/tools/libraries/CollisionMap/CollisionObject.h:42,
from /home/edvz/zing/scratch/inVRs_OSG/tools/libraries/CollisionMap/CollisionLineSet.h:41,
from /home/edvz/zing/scratch/inVRs_OSG/tools/libraries/CollisionMap/CollisionLineSet.cpp:28:
/home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/MatrixOps.h: In function ‘gmtl::Matrix<DATA_TYPE, ROWS, COLS>& gmtl::invertAffine(gmtl::Matrix<DATA_TYPE, ROWS, COLS>&, const gmtl::Matrix<DATA_TYPE, ROWS, COLS>&) [with DATA_TYPE = float; unsigned int ROWS = 2u; unsigned int COLS = 2u]’:
/home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/MatrixOps.h:335:10: warning: iteration 2u invokes undefined behavior [-Waggressive-loop-optimizations]
result[x][y] = src[y][x];
^
/home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/MatrixOps.h:333:7: note: containing loop
for (int y = 0; y < 3; ++y)
^
/home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/MatrixOps.h: In member function ‘std::vector<CollisionData*>& CollisionLineSet::checkCollisionWithLineSet(CollisionLineSet*, std::vector<CollisionData*>&, bool)’:
/home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/MatrixOps.h:335:10: warning: iteration 2u invokes undefined behavior [-Waggressive-loop-optimizations]
result[x][y] = src[y][x];
^
/home/edvz/zing/scratch/inVRs_OSG/external/gmtl-0.6.1/gmtl/MatrixOps.h:332:7: note: containing loop
for (int x = 0; x < 3; ++x)
^
</pre></p> inVRs - Feature #55 (In Progress): Add particle effects library to inVRshttp://dev.invrs.org/issues/552013-05-15T14:35:57ZJohannes Zarl-Zierl
<p>Somehow the particle effects library from the original LNDW project was not included with inVRs when the project moved to svn.</p>
<p>-> add the code</p> inVRs - Refactor #54 (New): Refactor SystemCore to be Scenegraph Independenthttp://dev.invrs.org/issues/542012-12-01T14:18:19Zsam g
<p>in the current implementation the SystemCore depends on OpenSG as for example the threading is implemented using OpenSG threads. In order to use a different scenegraph implementation (e.g. OpenSceneGraph) these library specific types needs to be extracted.</p>
There are different ways to realize this:
<ol>
<li>use boost for threading, locking,...</li>
<li>write a wrapper around the OpenSG specific classes, which can also be implemented e.g. using OpenSceneGraphs OpenThreads and decide during compile-time which implementation should be used</li>
<li>like b but this time, decide at runtime (i.e. during initialization)</li>
</ol> inVRs - Feature #51 (New): Implement non-GUI version of OpenSGApplicationBasehttp://dev.invrs.org/issues/512012-11-07T19:38:23ZJohannes Zarl-Zierl
<p>Most of the time the glut window of OpenSGApplicationBase is not used anyways, and as mentioned in bug <a href="http://dev.invrs.org/issues/19" class="issue tracker-1 status-1 priority-3 priority-lowest" title="Using option controlWindowImage causes huge performance loss over remote X (New)">#19</a> using the GLUT window to display something can easily lead to a huge performance loss.</p>
<p>For Applications using CAVESceneManager, a better default would be to make the main application GUI-less entirely, as the rendering exclusively takes place in the renderservers.</p> inVRs - Bug #50 (New): Interaction: reset environment scalehttp://dev.invrs.org/issues/502011-06-09T19:19:08Zsam g
<p>if you pick an entity, the defined environment scale settings will be reset to 1.00</p>
<p>the interaction should only update the translation and rotation part but not the scale part</p> inVRs - Bug #49 (New): EventPipe initialization & PreloadModuleshttp://dev.invrs.org/issues/492011-06-06T16:21:40Zsam g
Scenario: (under windows)
<ol>
<li>custom call to NavigationResumeEvent in the Application Class</li>
<li>from that, link the Navigation.dll to the Application</li>
<li>from that, Navigation will be part of PreLoaded Modules</li>
<li>Navigation acquires during Constructor its eventpipe</li>
<li>however during initialization all the existing pipes will be nulled (EventManager::init)</li>
<li>send from the Application an event to the Navigation<br /> -> a new pipe will be opened</li>
<li>Navigation checks its (constructor fetched) pipe, but this pipe is different than that in the EventManager and therefore never contain any events</li>
</ol>
<p>possible solution: lazy initialization of the pipe</p> inVRs - Feature #48 (New): Normalized Entitieshttp://dev.invrs.org/issues/482011-05-23T11:07:56Zsam g
<p>it's quite common that you have models, which have a different scale. Therefore you can set the scale option within entities.xml. However this is an annoying task, if you have to start from scratch.</p>
<p>Therefore the idea to add an option or pseudo loader for models, which ensure that the model will get normalized (boundingsphere center: 0,0,0, r: 1) after the model has loaded.</p>
<p>This would help to simplify the configuration process, because you only have to take care about the relations between the objects, not the individual sizes of the objects</p> inVRs - Feature #43 (New): OpenSceneGraph supporthttp://dev.invrs.org/issues/432010-12-01T08:36:20Zsam g
<p><a class="external" href="http://www.openscenegraph.org/projects/osg">http://www.openscenegraph.org/projects/osg</a></p>
<p>branch: <a href="http://dev.invrs.org/projects/invrs/repository/entry/branches/inVRs_OSG" class="source">source:branches/inVRs_OSG</a></p> inVRs - Refactor #42 (New): introduce DEBUG_POSTFIX "d" for all the librarieshttp://dev.invrs.org/issues/422010-11-26T12:38:37Zsam g
<p>it would be useful to introduce a debug_postfix "d" like in OpenSG or OpenSceneGraph to be able to separate the Release and the Debug build, if the are installed at the same location</p> inVRs - Feature #41 (New): add dynamic representation file typehttp://dev.invrs.org/issues/412010-11-11T21:02:48Zsam g
<p>up to now you can load model files in VRML, OSG,.. format.</p>
<p>the problem is if you have a complex object, which for example requires to specify a shader, like the terrain of the medieval town tutorial. The current solution is to export a partial scenegraph in the OSG format and import it afterwards.</p>
<p>Unfortunately the OSG format changed between OpenSG 1.8 and OpenSG 2.</p>
<p>So the idea is to be able to specify a classname instead of an existing file, e.g. with the type=INSTANCE. The class builds a custom scenegraph and returns the root node.</p>
<p>So one could specify the terrain in a portable way and build other dynamic representations.</p> inVRs - Refactor #31 (New): refactor glutdevice and glutsensordevicehttp://dev.invrs.org/issues/312010-10-21T10:40:16Zsam g
<p>up to now, the switch between the glutdevice and the glutsensordevice has to be done in the application base using some non configurable predefined key.</p>
<p>One could refactor these both classes and extract a common glut Singleton, which uses the observer pattern to notify the input device instances.</p>
<p>Furthermore the glut sensor device could also provide the mouse axis and a configuration for a key, which switches between the sensor and the axis mode.</p>
<p>So you don't have to explicitly switch in the application base between these two devices, you just have to use the glutdevice just for the keys and the glutsensordevice for the axis and the sensors.</p> inVRs - Feature #29 (New): support properties in the configurationhttp://dev.invrs.org/issues/292010-10-19T09:30:37Zsam g
<p>like inMaven.</p>
<p>e.g. <code>${server.mode}</code> will be replaced by the property <code>server.mode</code>, which can be either set via XML Entry in general.xml or via program during start-up or via commandLine-Parameter, e.g. <code>-Dserver.mode=...</code></p>
<p>+ changing a single value in a deep located file, doesn't require to duplicate all immediate files<br />+ more flexible during startup</p>
<p>-> if the wrapper of the xml files is everywhere used, this could be transparent to all modules</p>
<p>further extension, is the support of interpolation variable handler, e.g. <code>${server.mode}</code> <==> <code>${get:server.mode}</code>, other possible handler could support simple default values: <code>${isset:server.mode:client}</code>, toascii <code>${toascii:a}</code> for input devices, and so on</p> inVRs - Feature #28 (New): use xml namespaces for improved xml validationhttp://dev.invrs.org/issues/282010-10-19T09:24:13Zsam g
<p>using xml namespaces things like the configuration of the opensgapplicationbase or the simplePhysicsEntity could still be validated, if they have their own xml namespace</p> inVRs - Bug #16 (New): Fix selection action cleanup when client disconnectshttp://dev.invrs.org/issues/162009-08-06T12:35:41ZRoland Landertshamerrlander@invrs.org
<p>Whenever a client disconnects during being in the selection state the highlighted box won't be remove on the other hosts. The correct behavior would be that the highlight object is removed at the other hosts as soon as a client disconnects (of what reson ever).</p>