The reason is that the .osgt text files do not provide size information about the contained binary shader hence leading to a bad allocation when reading the shader data, probably size 0 ? The reader method in the responsible serializer class (serializers/osg/BinaryShader) is correct and does not need to be changed as it queries the size as expected. The writer method supports two paths(binary output .osgb and text output .osgt/.osgx). Only the text path is affected as the binary path writes the size.
I extended the writer in the text path by the size information. The results before and after the fix are shown below:
Erroneous code for binary shader in osgt file before fix:
Data {
0a
0d
0
...
}
Corrected code for binary shader in osgt file after fix:
Data 524 {
0a
0d
0
...
}
After my fix the the thrown error disappeared."
I included binary shaders into an osgt model file. These shaders only consists of the binary shader code, I did not supply the text version additionally. When loading the model the osg::Optimizer threw away all shaders except the first one. In the current trunk version of the file two shader objects are identical despite differing _shaderBinary members as the compare method of the Shader class does not include the comparison of that member.
The fix in this submission adds the check for identity of the referenced binary shaders to the shader class.
When comparing two shader objects with text source shaders the new lines of comparison are not even executed as the comparison returns false in the previous lines when the text shaders differ.
With this fix I get expected behavior, the Optimizer handles the different shaders correctly."
and the modified key as requested. Can other OS X developers please test
the attached file, to make sure it works for everybody?
I fixed the problem with the caps-lock-key, too."
The current setAnchorHorizontal() command doesn't center the center of the object, it just center's the object's origin. The following change to osgWidget::Window::update() will correct that behavior so that it is consistent with setAnchorVertical() behavior.
"
1. DAE submission:
DAE plugin now correctly writes images URI in Collada file, when images are used twice.
I also greatly improved readability and maintenability of geometry reading (mainly daeRGeometry.cpp), by factorizing code, templatizing it (for double/single precision), and removing ugly macros.
2. osgDB submission:
I updated osgDB::getPathRelative(): it is now far more readable, it handles more cases (especially when you want to relativise "a/c" from "a/b", which results in "../c"), and I added comments to make it clearer to maintain."
and another problem is:
example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
I try to explain my changes
we need something that is identify key without modifier keys and layout -> this is UnmodifedKey
I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
to read fonts: only the first character of a whole text is correctly
shown and others are disappeared. I haven't got into the font
implementation so can't explain why this happened and how it should
work under other platforms, but it seems to be fixed by specifying
width and height of the glyph object. The source file is attached for
future developments. At present it just works for my own project. :-)
"
DAE plugin was linking ORIGINAL images in the Collada file, using image->getName() as a path (even if images were modified in memory!). As the behaviour was not the one of other plugins (3DS, FBX, and such), I made the plugin relativise images filenames (as those plugins) and write the image which is in memory. However, in order to avoid removing features, I kept the previous behaviour but moved it in an option. Here are the options of the plugin I changed:
- daeForceTexture was unclear in this new context and removed in favor of two new options
- daeLinkOriginalTexturesNoForce: Writes reference to the original image if found, instead of writing the image in memory
- daeLinkOriginalTexturesForce: Writes reference to the original image even if not found, instead of writing the image in memory
Of course, if you specify no option, images are written as for other plugins.
Other thing I changed is the UTF8 support as I told you in a previous conversation. Now there is a simple option, "daeNamesUseCodepage", which makes all names except filenames (materials, animation, geometries...) be considered as encoded using current codepage. If so, they'll be converted to UTF8 when writing; else they are written directly. Of course, filenames follow OSG_USE_UTF8_FILENAME as usual.
I did "
to protect against accessing while writing which was segfaulting in VPB
specifically in void ThreadPool::run(osg::Operation* op)
in the waiting loop
while (_operationQueue->getNumOperationsInQueue() >= _maxNumberOfOperationsInQueue)
"
1. It did not support normals applied to individual vertices.
2. It would only support red / green / blue colour triples, but the pmvs models are generated with diffuse colours. (The PLY format, http://local.wasp.uwa.edu.au/~pbourke/dataformats/ply/, lists specular and ambient colour forms as well.)
To partially overcome these limitations, please find attached modified versions of
src/osgPlugins/ply/vertexData.cpp
src/osgPlugins/ply/vertexData.h
The changes I've made are:
1. I have changed the boolean hasColor flag to a vertexField (which is a boolean operation on an enum) to indicate what fields are present in the ply file. (This is required because Turk's ply reader spits out warnings for every line where you try to read fields which do not exist.)
2. I have modified the code to apply valid normals to either triangles or vertices.
3. I have kludged in "support" for the various colour variants. Specifically, all the colour specified can be read from the file. However, they are all applied in the same way (namely as a colour array, bound to each vertex)."
I have attached a patch, against the trunk from 13:30 today, which consists of the following:
1. CMakeModules/FindOpenEXR.cmake: Look for libIlmThread and libIex as well. 2. src/osgPlugins/CMakeList.txt: Only include the exr subdirectory if both the OpenEXR and zip libraries were found. 3. src/osgPlugins/exr/CMakeLists.txt: Add ZIP_LIBRARY to TARGET_EXTERNAL_LIBRARIES."
The DatabasePager now passes the Terrain pointer into the ReaderWriter's via osgDB::Options object,
rather than pushing a NodePath containing the Terrain onto NodeVisitor. This
change means that the DatabasePager nolonger needs to observer the whole NodePath and
will be lighter and quicker for it.
The change also means that ReadFileCallback can now run custom NodeVisitor's on the scene graph without
having to worry about TerrainTile's constructing scene graphs prior to the Terrain being assigned.
Also changed is the NodeVisitor::DatabaseRequestHandler which now requires a NodePath to the node that you wish
to add to rather than just the pointer to the node you wish to add to. This is more robust when handling scenes
with multiple parental paths, whereas previously errors could have occurred due to the default of picking the first
available parental path. This change means that subclasses of DatabasePager will need to be updated to use this new
function entry point.
Attached is the modified State.cpp file.
I have also attached a sample transcript, showing the new code working properly. I ran it against osgEarth's shaders and it works as expected.
"
are big enough to handle the primitives used in the geometry.
Added usage of verifyArray into osgfilecache so that it reports any problems on reading files in paged database.
We should have:
UV for vertex 0, layer 1
UV for vertex 0, layer 2
UV for vertex 1, layer 1
UV for vertex 1, layer 2
...etc...
Instead, we have this:
UV for vertex 0, layer 1
UV for vertex 1, layer 1
...etc...
UV for vertex 0, layer 2
UV for vertex 1, layer 2
...etc..."
· points (just look at points in frustum)
· lines (simple line clip—replace the external point)
· quadrilaterals (call operator() for triangles twice)"
Attached is src/osgWrappers/deprecated-dotosg/osg/Geometry.cpp. It gets the data pointer out and casts it to a pointer to the element type, rather than casting the array object itself. This seems to work."
