In OSG 3.4, osgText::Text( ::_quadIndices) uses DrawElementsUInt that will fail on these devices and no text will appear - tested on Samsung Galaxy Trend 2 SM-G313HN.
When DrawElementsUInt is replaced with DrawElementsUShort it works, although I'm not sure if this can cause other problems with some fonts.
Fix:
- In include\osgText\Text, line 316:
replace: "osg::ref_ptr< osg::DrawElementsUInt > _quadIndices;"
with: "osg::ref_ptr< osg::DrawElementsUShort > _quadIndices;"
- In src\osgText\Text.cpp, line 2094:
replace: "_quadIndices = new DrawElementsUInt(PrimitiveSet::TRIANGLES);"
with: "_quadIndices = new DrawElementsUShort(PrimitiveSet::TRIANGLES);"
"
Font::getKerning(...), Font::getGlyph3D(...) doesn't ask for a font resolution so it uses the last font resolution requested by Font:: getGlyph(...).
This can leads to different results depending of the precedent call to Font::getGlyph(...).
See http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2016-January/271952.html for more infos.
This fix adds a font resolution parameter to Font::getKerning(...), Font::getGlyph3D(...) and to the font implementations.
This was made under the base revision r15182."
forcing users to use osgDB::readRef*File() methods. The later is preferable as it closes a potential threading bug when using paging databases in conjunction
with the osgDB::Registry Object Cache. This threading bug occurs when one thread gets an object from the Cache via an osgDB::read*File() call where only
a pointer to the object is passed back, so taking a reference to the object is delayed till it gets reassigned to a ref_ptr<>, but at the same time another
thread calls a flush of the Object Cache deleting this object as it's referenceCount is now zero. Using osgDB::readREf*File() makes sure the a ref_ptr<> is
passed back and the referenceCount never goes to zero.
To ensure the OSG builds when OSG_PROVIDE_READFILE is to OFF the many cases of osgDB::read*File() usage had to be replaced with a ref_ptr<> osgDB::readRef*File()
usage. The avoid this change causing lots of other client code to be rewritten to handle the use of ref_ptr<> in place of C pointer I introduced a serious of
templte methods in various class to adapt ref_ptr<> to the underly C pointer to be passed to old OSG API's, example of this is found in include/osg/Group:
bool addChild(Node* child); // old method which can only be used with a Node*
tempalte<class T> bool addChild(const osg::ref_ptr<T>& child) { return addChild(child.get()); } // adapter template method
These changes together cover 149 modified files, so it's a large submission. This extent of changes are warrent to make use of the Object Cache
and multi-threaded loaded more robust.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15164 16af8721-9629-0410-8352-f15c8da7e697
I have left the Texture::generateTextureObject functions intact as I'm not sure if/how it's used outside the core OSG. If you feel that compatibility isn't important in that area feel free to drop it.
While testing the build with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION=OFF I found a compile error in GlyphGeometry.cpp that was entirely unrelated to the changes I've made. The fix is included in the patch.
There is one thing left to fix and that is Texture2D::SubloadCallback:
class OSG_EXPORT SubloadCallback : public Referenced
{
public:
....
virtual TextureObject* generateTextureObject(const Texture2D& texture, State& state) const
{
return osg::Texture::generateTextureObject(&texture, state.getContextID(), GL_TEXTURE_2D);
}
...
}"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14879 16af8721-9629-0410-8352-f15c8da7e697
Added osgText::Bevel::s/getRoundedConcaveJunctions(bool) to control how the bevel should be tessellated around concave junctions on the glyph boundary.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14871 16af8721-9629-0410-8352-f15c8da7e697
the scene tree contains (large) 2D textures from images with STRIDE.
============================================================================
#0 0x00007fffe8ea4350 in __memmove_ssse3 () from /lib64/libc.so.6
#1 0x00007fffe52ced76 in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#2 0x00007fffe52d8e86 in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#3 0x00007fffe53dd8be in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#4 0x00007fffe53c2643 in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#5 0x00007fffe53c7fdd in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#6 0x00007fffe53cbabf in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#7 0x00007fffe53cc1fa in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#8 0x00007ffff30092fd in osgText::GlyphTexture::apply (this=0x1bb8cf0, state=
...)
at /d43/jaap/dev/jaapOSG/build/OpenSceneGraph3.3.1/src/osgText/Glyph.cpp:234
#9 0x00007ffff56c30b6 in osg::State::applyAttributeOnTexUnit (this=0x125f180,
unit=0, attribute=0x1bb8cf0, as=...)
at /d43/jaap/dev/jaapOSG/build/OpenSceneGraph3.3.1/include/osg/State:1713
#10 0x00007ffff56c2f3f in osg::State::applyTextureAttribute (this=0x125f180,
unit=0, attribute=0x1bb8cf0)
at /d43/jaap/dev/jaapOSG/build/OpenSceneGraph3.3.1/include/osg/State:411
#11 0x00007ffff30204da in osgText::Text::drawTextWithBackdrop (this=0x1baed70,
state=..., colorMultiplier=...)
==============================================================================
The crash disappears if I either (1) disable the use of images with stride
in the (public) osgGeo-library, or (2) add the following bugfix to Glyph.cpp.
This combination gives me the confidence that I understand where this problem
originates from, without trying to understand the full OpenGL details.
===============================================================================
@@ -221,7 +223,12 @@
imageData[i] = 0;
}
+ glPixelStorei(GL_UNPACK_ALIGNMENT,1);
+ #if !defined(OSG_GLES1_AVAILABLE) && !defined(OSG_GLES2_AVAILABLE)
+ glPixelStorei(GL_UNPACK_ROW_LENGTH,getTextureWidth());
+ #endif
+
// allocate the texture memory.
glTexImage2D( GL_TEXTURE_2D, 0, GL_ALPHA,
getTextureWidth(), getTextureHeight(), 0,
================================================================================
I have copied (and adapted) the added lines above from the same source file,
where they were used in front of a similar call to glTexSubImage2D(.) around
line 515.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14372 16af8721-9629-0410-8352-f15c8da7e697
"I noticed that Text3D objects would change there z alignment depending on the alignment mode. I'm not sure if this was intentional or just a simple mistake. My expectation was that the front of the object would always stay aligned to the 0 z-plane, regardless of the alignment mode. I've attached an updated version that retains a consistent z-alignment."
"I just now noticed another issue with Text3D objects. It was not properly computing the bounding box when non-axis aligned rotations were being applied. In this case all corners of the bounding box need to be transformed in order to get the correct containing box. I've attached the updated file."
"The incorrect bounding box problem also applies to regular Text objects. I've attached the fix for that as well as the original Text3D fix."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14296 16af8721-9629-0410-8352-f15c8da7e697
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
auto-rotated (e.g. HUD text) is not always correct, because it
doesn't take account of the base line offsets added by the
various alignment options such as CENTER_TOP, CENTER_BOTTOM etc.
The attached src/osgText/TextBase.cpp fixes the problem."
and makes the glyphs aspect ratio match their 12x8 bitmaps.
I am not exactly sure about osgTexts current internals but it matches the
changes that happened lately to the txf font.
"
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.