I have also made changes to the RotateCylinderDragger to provide a cylinder ring with a thickness. It is totally optional, but IMHO makes the default behavior work better than a solid cylinder (which typically obscures the geometry you are trying to drag). Gives it a bit more to grab, especially in the case where eyepoint and cylinder axis are near parallel.
"
Now examples/osgmultitouch really works ;-)
Based on yesterdays trunk.
* It should now work with all Visual Studio Versions.
* WIN_VER is left as-is
* I added the missing declarations from a recent SDK, if not supplied by the SDK
* If someone chooses to update WIN_VER, the declarations should not break.
* All API Calls are runtime detected.
* No CMake Variable, Support is enabled automatically ."
If an object is comming with texture and NULL image, the texture atlas builder crash when sorting textures according to texture height.
The fix is to skip textures with NULL image when inserting textures in the builder texture list.
"
osgshaders.cpp and demonstrates the use of GLSL vertex and fragment
shaders with a simple animation callback. I found the osgshaders.cpp
too complex to serve as a starting point for GLSL programming"
* If the eyepoint and cylinder axis are close to parallel (given some tolerance), then it uses a plane perpendicular to the cylinder axis.
* Otherwise it uses a plane parallel to the cylinder axis oriented towards the eyepoint (previous behavior). This gives decent behavior and is the only path that was taken in the previous code. I kept with previous behavior and that allowed a good bit of code to be removed, simplifying things. There is now no need for the _onCylinder flag, but since there is a public accessor, I wasn't sure how to handle it for backwards compatibility, so I left it in. NOTE - there is no default initialized value, so if it is kept in, it should be set to 'false' to keep same behavior as before. I am not quite sure how the _onCylinder case was supposed to behave as even forcing that path gave undesirable behavior, even with carefully controlled dragging.
"
- correction to writeFace : the fourth point was defined with an incorrect code (http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm)
- if no layer name was found, an empty string was used, with is incorrect according to dxf specifications and was rejected by Autodesk DWG TrueView
- the plugin was writting polygons and triangles as LINE, as if PolygonMode GL_LINE was active, and didn't use 3DFACE primitive.
I changed this behaviour to write 3DFACE as default, and LINE when PolygonMode GL_LINE is active.
when reading back the file with osg, the result is now consistent with the source
Tested with osg plugin, FME (Safe software), Autodesk DWG TrueView
"
in osg::Program::PerContextProgram :
typedef std::vector<UniformModifiedCountPair> LastAppliedUniformList;
should be
typedef std::map<unsigned int, UniformModifiedCountPair> LastAppliedUniformList;
Intel driver can use index uniform value > 200000.
With a std::vector, this index uniform value generate an out of memory error
Nothing in OpenGL or GLSL specification define index uniform value rules.
And all other implementation that deal with uniform index in osg::Program
use a std::map.
This fix could have a little performance impact but this is the cost
to pay to work with
all driver."
Here's a summary:
* Uses a separate ZIP file handle per thread
* Maintains a single shared (read-only) index, created the first time through
* Stress-tested with the DatabasePager using 24 threads under osgEarth
I also updated the member variables to use OSG's leading-underscore convention."
CLAMP all textures using only texcoord between [-0.001 1.001] to give a
chance to create an Atlas.
If the atlas creation failed for other reason (texture size, only one
compatible texture, ...) the texture remain modified in CLAMP mode.
But if you use texcoords between [0.0 1.0] using CLAMP mode instead
REPEAT it is not safe because you will have a blend to the border color
at extremities.
If we want to have exactly the same rendering after changing mode from
REPEAT to CLAMP we should use the CLAMP_TO_EDGE mode instead of CLAMP to
avoid blending to border color at extremities.
Please find as attachment the proposed patch against latest svn version.
"
state.applyTextureMode(0,GL_TEXTURE_2D,osg::StateAttribute::ON);
into the #if defined(OSG_GL_FIXED_FUNCTION_AVAILABLE) block to solve problems under GLES and GL3.x/GL4.x
Bug description:
Let's say we have class A
namespace Bug
{
class A : public osg::Object
{
public:
//...
typedef std::vector<osg::ref_ptr<A> > AList;
protected:
AList _alist;
//...
}
}
REGISTER_OBJECT_WRAPPER( A,
new Bug::A,
Bug::A,
"osg::Object Bug::A" )
{
ADD_LIST_SERIALIZER(A,Bug::A::AList);
}
Bug:
We create say 3 instances of class A: A1,A2,A3 and then we add A2 and A3 and A1 as child instances of A1 so we get next structure:
A1
|- A2,A3,A1
we call osgDB::writeObjectFile(A1,"/data/a.osgt") -> saved correctly( third element in list is saved as unique id that references parentClass
now we call
A1 = osgDB::readObjectFile("/data/a.osgt");
Everything is deserialized correctely except last element in list which should be same instance as parent A1.
The attached code resolves this issue by passing UniqueID in readObjectFields method and saving object in _identifierMap as soon as we have valid object instance so we can make reference to parent object from any child instance.
"
I added AFAIK proper defaults for several Macos X Version API targets.
* In order to determine which defaults to apply, consult the CMAKE_OSX_SYSROOT variable pointing to the used SDK, not the pure existence of an SDK.
* Defaults are now:
10.7: Support Intel 32 and 64 Bit Cocoa with imageio picture reader
10.6 + 10.5: Support Cocoa with imageio on Intel and PowerPC
10.4: Carbon, Quicktime and PowerPC
Now OSG compiles out of the box for MacOSX 10.7. , tested with gcc and clang with FlightGear."
I think the best way to achieve this is to overwrite the DatabasePager::addDatabaseThread() method within the customized database pager. However this method is not 'virtual' yet, so I propose to make the method 'virtual'."
which simply set by default the internal pixel format to GL_RGB32F_ARB where appropriate.
In the current version there's a comment saying that the plugin set it to GL_RGB8 (even when reading from float) to support old graphics cards,
but the comment dates back to 2004...
What's more I believe that it's correct to expect a floating texture format if you're loading an hdr image.
It was quite troublesome for us to discover why our background image wasn't showing hdr data...
In case you accept the submission, I've removed the comment as it would be misleading to leave it there."
Without the change the application does not work properly. First I get the notification that an OpenGL error occured. After some more of this error messages I see broken textures on the screen. With the changes attached to this message my application works as intended."
Note from Robert Osfield, changed the Image::supportsTextureSubloading() to be const and to be implemented in the .cpp rather than inline.
(http://gta.nongnu.org). This allows to read and write floating point
image data. Unlike other formats, GTA also allows very good compression
ratios for floating point data. The compression method can be selected
with the COMPRESSION option of the plugin.
"
Here's another small submission for IOS, which adds unique ids to the
touchpoints, so the ids stay the same during a touch-sequence.
(and some minor code enhancements)"
working on some junk low-end graphics cards which I still have to
support. They worked ok with osg 2.8 and earlier.
The problem turned out to be with gl proxy textures, which are
unreliable on those devices. Proxy textures are used by the glu
mipmap build routines to determine if a texture size is
supported. The external glu library had a nice fallback
behaviour, so that if proxy textures didn't work then the mipmap
texture was still created. But in the work on the new embedded
glu routines that fallback behaviour has been inadvertently
lost. I have restored the fallback in
src/osg/glu/libutil/mipmap.cpp. It doesn't add any extra
complexity."
