Hi Tim,
On Sunday 22 February 2009 12:37:55 Tim Moore wrote:
> Good to hear from you again. You should check out my recent changes to the
> groundcache code that changes it to use the OSG PolytopeIntersector. My
> thinking was that someone (perhaps you or I) could teach the polytope
> intersector to use the kd tree support that is already in OSG to create a
> truly fast ground cache.
Well, I have something better than that.
My original groundcache idea was to use only few huge geometry triangles from
the area around the aircraft to do collision test with. This list of triangles
is flat. Ok, so far.
What works well with this approach:
* Rolling on ground tiles with few huge triangles.
* Rolling/interacting with the carriers deck with few huge triangles and few
cats/wires.
What is bad with the current implementation:
* When we have many triangles in the cache.
This provides bad run time behavior because of lookups in the flat list
and the huge amount of work to build that list. To work around
that problem in the current implementation almost all fine details in
the carrier and the whole set of ai traffic is invisible to the
collision code.
* Movements of objects is very messy to compute. Nested movements are
not implemented and much more messy to compute if we would
implement those in the current code base.
So what have I done to solve that issues:
I have a collision tree implementation that provides:
* A very fast collision implementation.
* Hybrid approach for kd-trees (sort of) for the leaf geometry and
higher level grouping nodes for a scenegraph like high level structure.
* The good part of the idea groundcache: Use only a local part of the tree
to do frequent lookups, build that local tree once per time frame.
But the subtree build time is almost not noticable in contrast to the
old groundcache (with or without kd-tree of osg).
* Provides motion nodes in the collision tree to provide the groundwork for
realistic collisions with the carriers tower for example. Have
usable information for nested movement like an elevator on a carrier.
Have a simple way to provide such nested movement information.
Solve some subtle problems we have with the current 'pivot point'
approach for the collisions.
* Have now a good way for the FDM part to do faster and more
realistic collisions with geometry not to roll on (TBD physics wise).
* Have the ability to provide 'collision geometries' for models in the
model configuration.
* ... (stop here) :)
So the fast paths are already very well done.
There are still rough edges that I plan to work out before switching to that
new implementation. That is currently the angular movement of the carrier is
missing - but that is a matter of some cross products with the correct signs
in some methods - well in theory :).
So all in all, I have up to 10% frame rate improvements on my notebook.
Also this adds a code base that opens some doors.
Greetings
Mathias
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
