"I've made a few changes to osgUtil::PolytopeIntersector so that it
actually uses double precision floating point numbers everywhere (as
long as OSG_USE_FLOAT_PLANE is not defined).
I needed double precision intersections in a project I am working on.
These changes fixed the problems I was having -- this is all testing I
have done.
Notice that I have changed
osgUtil::PolytopeIntersector::Intersection's members to use doubles
(osg::Vec3d, instead of osg::Vec3). I could have added #ifdef's there
too, but I think it is better to not change the types of stuff in the
public interface depending on some preprocessor definition.
The modified files are attached. A diff also follows, for those who like it."
With the following changes from Robert Osfield:
"I've just reviewed your changes and have just tweaked them a little to
streamline them. What I have done in the PolytopeIntersector header
is add:
typedef osg::Plane::Vec3_type Vec3_type;
And then use this typedef in the definition of the vertices rather
then Vec3d as you did. Next changes were to PolytopeInteresector.cpp
where to the PolytopeIntersectorUtils defintions of the Vec3_type, and
value_type which now simply read:
typedef osg::Plane::Vec3_type Vec3_type;
typedef Vec3_type::value_type value_type;
This way I was able to complete avoid any if def's and have essential
the same implementation as you achieved. Changes now checked into
svn/trunk."
retessellatePolygons was applying the winding and boundary option.
Moved the gluTessProperty calls into beginTessellation().
There's a comment typo fix, removing an unused VertexPointList
typedef, and allocates one _tobj instead of one per tesellation.
Protections were added to check that _tobj was allocated in the few
remaining places it wasn't being checked.
---
On a side note, I would like to avoid the 'new Vec3d' in
Tessellator::addVertex for each call to
gluTessVertex(tess, location, data).
The RedBook leaves it ambiguous if the location pointer must
remain valid after gluTessVertex or not.
http://www.opengl.org/sdk/docs/man/xhtml/gluTessVertex.xml
says that changing location is not safe, so being conservative, I'll
leave it as is, even though the Mesa GLU library copies the data not
the pointer, so it is currently safe."
- apply() and reset() methods made virtual to allow overriding
- added apply(StateSet&) to make more easier to gather StateAttribute
statistics in user-derived classes
"
I found that some of the items that had been paged in were being expired on the first frame that they were not visible (as the cache was full). This resulted in excessive paging every time the view was moved. With the following changes I could only allow children to be expired if they had not been used for e.g. 30 seconds or 60 frames."
10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
to ensure the correct methods on constraints and callbaks are called for each Command. Also fixed the handling of
Constraints when applied to composite Draggers.
parameter in osg::Image. To support this Image::setData(..) now has a new optional rowLength parameter which
defaults to 0, which provides the original behaviour, Image::setRowLength(int) and int Image::getRowLength() are also provided.
With the introduction of RowLength support in osg::Image it is now possible to create a sub image where
the t size of the image are smaller than the row length, useful for when you have a large image on the CPU
and which to use a small portion of it on the GPU. However, when these sub images are created the data
within the image is no longer contiguous so data access can no longer assume that all the data is in
one block. The new method Image::isDataContiguous() enables the user to check whether the data is contiguous,
and if not one can either access the data row by row using Image::data(column,row,image) accessor, or use the
new Image::DataIterator for stepping through each block on memory assocatied with the image.
To support the possibility of non contiguous osg::Image usage of image objects has had to be updated to
check DataContiguous and handle the case or use access via the DataIerator or by row by row. To achieve
this a relatively large number of files has had to be modified, in particular the texture classes and
image plugins that doing writing.
functionality when using Terrain::setVerticalScale. This was caused by
the following call sequence resulting in a lockup:
void Terrain::setVerticalScale(float scale)
CALLS dirtyRegisteredTiles();
void Terrain::dirtyRegisteredTiles(int dirtyMask)
SETS LOCK OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
and CALLS (on every tile) setDirtyMask(dirtyMask);
void TerrainTile::setDirtyMask(int dirtyMask)
CALLS _terrain->updateTerrainTileOnNextFrame(this);
void Terrain::updateTerrainTileOnNextFrame(TerrainTile* terrainTile)
SETS LOCK OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
******* PROBLEM - since lock has already been set! ********
The suggested fix submitted changes from using Mutex to ReentrantMutex.
"
You can now set a "intersection mask" and it will be used when looking for intersections.
So you can now easily "hide" some objects from manipulators."
I don’t have access to an OSX or Linux dev machine to make the changes required to the quick time plugin. This plugin will just default to returning 0."
Added support into .vnc plugin for passing in the keywords "swap", "RGB", "RGBA", "BGR", "BGRA" as OptionString values to allow .p3d presentations to control
whether the pixelformat should be swapped or set to a specific format.
Motivation ;
When using PagedLODs, you don't always know the real size of loaded children,
If it occurs that they are out of predefined bounds, picking on the parts that are out of bound will fail
They also can be culled out too soon.
The problem often occurs with long object (roads).
I've modified LOD and ProxyNode to include this option."
and later email:
"Attached the UNION_OF_BOUNDING_SPHERE_AND_USER_DEFINED version
There are impacts on some serializers (dae, osgWrapper).
I haven't modified deprecated osg, since it's deprecated"
So with the 3.0 api change we propose the following change:
- put OSG_EXPORT on the QueryGeometry class so that we get access to the getNumPixels method.
- Create a function called getQueryGeometry that returns a casted _queryGeode->getDrawable(). Or a function called getQueryGeode that returns _queryGeode."
Line 251:
int getKeyEventWindowedResolutionDown() const { return _keyEventWindowedResolutionUp; }
Should be replaced with:
int getKeyEventWindowedResolutionDown() const { return _keyEventWindowedResolutionDown; }"
