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
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
disable pragmas that turn off specific warnings for MSVC.
Unfortunately it's presence is only checked in osg/Export header,
making other Export headers disable warnings no matter what, which is
kind of incoherent.
My fix adds #include <osg/Config> to every Export header. I've also
unified checking whether to disable warnings to current osg/Export
way:
#if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS).
Attachment contains all changed Export files in their original locations."
hpux. I have skipped irix this time as irix is too dead to keep osg building
there.
As usual, solaris does not like member templates in stl containers.
Some headers missing and link problems due to missing libraries."
performance option, I added a flag to control whether the depth writing
pass is performed.
Since text is alpha-blended when rendering, it is placed in the
transparent bin and rendered back to front. Writing to the depth buffer
should therefore be unnecessary. Indeed, rendering something behind text
(or any blended object) after that object is drawn will give incorrect
results whether the depth buffer is written or not. I therefore think it
is safe to keep this option off by default. Users can turn it on for any
special needs they have.
I did not fix the existing backdrop implementations to work with the new
code since this new method of rendering intrinsically handles backdrops
correctly. Its results are more accurate than all of the existing
backdrop implementations. Its only downside is that it requires two
passes if depth buffer updates are desired, whereas DEPTH_RANGE and
POLYGON_OFFSET achieve their (less accurate) results in one pass. The
NO_DEPTH_BUFFER method also only uses one pass, but it disables depth
tests and not depth writes so will have serious problems if anything is
drawn in front of the text before OR after the text is drawn.
Given the better all-around behavior of the new method, I believe the
other backdrop implementations can be safely removed. Code that adjusts
the backdrop implementation will of course be broken if the member
functions are removed. For this reason I left them in, but set the new
rendering method as the default backdrop implementation. At the very
least I think the old backdrop implementations should be deprecated and
removed at a later date.
"
Note from Robert Osfield, testing this submission with osgtext I found that the
text would not render correctly when different text labels were overlapping
in deth and screen space. I change _enableDepthWrites to default to true and
found the that which artifacts still occurred around the alpha blended edges
the artifacts where better than issue with occlusion of nearer pixels that was
happening with _enableDepthWrites set to false.I therefore set the
_enableDepthWrites to true as I feel it's the lesser of the two artefacts.
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg33967.html
, interpolating through HSV space gives a rainbow color effect which
does not mimic the simple RGB color interpolation that OpenGL does.
It's overkill and causes unexpected visual artifacts. In the attached
files I've removed the conversion to HSV so that interpolation happens
in RGB space."
behind osgText::Text. I made it so the box would get drawn using
whichever BackdropImplementation was selected. However, I did not
implement STENCIL_BUFFER. In that case it defaults to drawing the
bounding box using POLYGON_OFFSET instead.
Also made it so the BOUNDINGBOX and FILLEDBOUNDINGBOX are drawn with a
settable color and margin size.
While I was at it I tightened up the values applied with DEPTH_RANGE
and POLYGON_OFFSET, not just for drawing the bounding box but also for
drawing backdrop text (these values must be coupled since the bounding
box has to be drawn deeper in Z than the backdrop text). The values
in use before seemed like overkill and I was seeing some z-clipping
with my background scenery in the case of DEPTH_RANGE. If there was a
good reason for the large values please let me know...."
osgText::Text and osgText::Text3D use the same font file.
The first really load the file and obtain an osgText::Font object,
the second use the cache created during the first load of the
font file, and so obtain an osgText::Font object instead of
osgText::Font3D object. To obtain an osgText::Font3D object,
osgText::Text3D call osgDB::readObjectFile(...) with an option
to specify the plugin we want an osgText::Font3D instead of
osgText::Font.
Generalised Problem:
In osgDB::Registry, loaded file cache is referenced by the name
of this file, so if I load a file with some options, and the cache
already contain object for this filename, I obtain an object
potentially not loaded with my options.
Behaviours:
Cache management is delegate to osgDB::Registry, but cache
coherence (load a file with option then reuse it, deactivate the
cache when load a specific file or don't cached the loaded file)
is user's responsibility.
Text3D solution:
Postfix the font file name by .text3d or something similar and then have the freetype plugin return
osgText::Font3D when it detects this.
This operation is done by osgText::readFont3DFile() which unsure the filename have .text3d as extension.
This is totaly transparent for user, and backward compatible.
BTW, I fix the bug about the Normal of 3D text. Currently, the front and wall face have
the same normal (0,0,1) in the Text3D object coordinate. Now the wall face have its own
normal array computed by the plugin.
BTW 2, I implement
- void Text3D::accept(osg::Drawable::ConstAttributeFunctor& af) const
- void Text3D::accept(osg::PrimitiveFunctor& pf) const
so now statistics are well reported.
"
