Hi robert,
:-( too bad, ok but if you autogenerate the files, means that i have to do a
work around in the marco.
you can replace the current macro by following macro:
#define I_BaseType(x) \
{ \
typedef x BASE_TYPE_X;\
addBaseType(typeof( BASE_TYPE_X )); \
BaseTypeConverters< BASE_TYPE_X , reflected_type,
osgIntrospection::is_polymorphic <BASE_TYPE_X >::value > btc; \
}
And for this string we have to limit the string length, may we can simple
pass a string array (static) or something else, in fact i don't know exactly
how we can solve
this.
I_Method1(void, setBackdropImplementation, IN,
osgText::Text::BackdropImplementation, implementation,
Properties::NON_VIRTUAL,
__void__setBackdropImplementation__BackdropImplementation,
"This specifies the underlying backdrop rendering
implementation. ",
"Unfortunately, at this time, there is no \"perfect\"
rendering solution so this function is provided to let you 'pick your
poison'. Each implementation has trade-offs.POLYGON_OFFSET: "\
"This uses glPolygonOffset to draw the text multiple times to
create the drop-shadow and outline effects. glPolygonOffset is used to
prevent z-fighting of the overlapping text. This probably "\
"should have been the best option, but all the ATI cards we
have encountered so far have serious problems with this. We see little white
holes/artifacts in the rendered glyph textures which move "\
"around depending on the viewing angle. For moving text, the
moving holes give an extremely unpleasant flickering effect. Pumping up the
\"units\" parameter in glPolygonOffset can minimize this problem, "\
"but two other bad side-effects occur if you do this. First,
high values will cause problems with clipping, particularly when there are
objects behind the text. The drop-shadows or outline may be culled because
"\
"their computed offset is behind the object or z-far plane.
Second, there is an additional problem associated with the Z-slope. High
values can make large chunks of the backdrop suddenly disappear. This can be
reduced "\
"by the \"factor\" parameter. Making the \"factor\" value
small, can help, but experimentally, we've found that it creates a new,
different kind of z-fighting problem. So there is no perfect solution. With
units, you trade "\
"off the 'holes' for the large-section clipping.
Experimentally, we have found units values from 150-512 to be tolerable to
acceptable with respect to the 'holes'. A factor of .1 seems to bring down
the large clipping problem "\
"without creating a new z-fighting problem. (You can
experiment with these numbers by playing with the osg:PolygonOffset
multipliers which this backend tries to respect.)If ATI ever fixes their
cards/drivers, then this might become "\
"the best option.NO_DEPTH_BUFFER Instead of using
glPolygonOffset to prevent z-fighting, this mode just disables the depth
buffer when rendering the text. This allows the text to be rendered without
any z-fighting. The downside to this "\
"mode is that render order begins to matter and the text will
not necessarily correctly appear above or behind other objects in the scene
based on depth values. This mode is best for text that only needs to be
ontop and not obscured by "\
"any objects.DEPTH_RANGE This mode is inspired by Paul Martz's
OpenGL FAQ, item 13.050. This uses glDepthRange as a substitute for
glPolygonOffset. Strangely, experiments on ATI cards seem to produce cleaner
results than when using "\
"glPolygonOffset. The trade-off for this is that the backdrop
still may be placed too far back and might be culled by objects directly
behind the object or by the far z-plane. If ATI ever fixes the
glPolygonOffset problem, polygon "\
"offset is probably a slightly better solution because you can
use smaller offsets. But with the current ATI problem, this option may be
preferable.STENCIL_BUFFER (Assuming the backend is written correctly,) the
Stencil Buffer is "\
"the most \"correct\" and reliable way of producing backdrop
text. The stencil buffer is a multipass system that allows writing to the
same z-values without needing to resort to offsets. This implementation
should not have any of the "\
"problems associated with the 3 previous implementations. But
the trade-off for this mode is that without hardware acceleration for the
stencil buffer, rendering will be extremely slow. (There is also potentially
more overhead for "\
"this algorithm so it could be slower than the other
implementations. Benchmarking would be required to determine if the speed
differences are significant on your particular hardware.) This mode is best
for when quality is important "\
2007/2/15, Robert Osfield <[EMAIL PROTECTED]>:
Hi Adrian,
Thanks for the changed files, the problem is that these files are
autogenerated so the next time I update the wrappers these changes
will be lost. In this instances its the I_BaseType macro defined in
include/osgIntrospection/ReflectionMacros that will where the mods
need to happen. Earlier I checked in some additional spaces to see if
it solved the problem, do you check out these mods?
The modification to Text.cpp again is something that will be lost on
next rebuild of the wrappers so we'll need to solve the problem at
source. The easist solution will probably be to change the comment so
its shorter. I presume the must be a brain dead string length limit
in VS2003 such as max length of 256 or similar.
Robert.
On 2/15/07, Adrian Egli <[EMAIL PROTECTED]> wrote:
> Hi robert,
>
> so after hard testing (rebuild takes long time) and i should also do
some
> daily business work i found next results:
>
> i was happy that the things seems to be runing as expected, but in fact
we
> have still an issue when the application close and clean up. some
> examples work well other crash, but never the same, so it is of sure a
> threading issue. i haven't yet tested them with different threading
modes,
> but
> i will do it as soon as i have some minutes left doing such test. i
would
> only mention that there will be still some bug fixes left.
>
> the some compiling error, please test them under linux, i am using
VC2003 as
> you know (attachment) and review at least them
> C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osgText\text.cpp
>
C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osgText\String.cpp
>
>
C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osg\PrimitiveSet.cpp
> C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osg\Array.cpp
>
>
> under VC2003 no more compiler errors .
>
> /adegli
>
> 2007/2/15, Robert Osfield <[EMAIL PROTECTED]>:
> >
> > HI Adrain,
> >
> > On 2/15/07, Adrian Egli <[EMAIL PROTECTED]> wrote:
> > > at the end, yes no access violation, but didn't terminate them
self
> >
> >
> > Sounds like a dead lock on exit. Could you run these apps in a
> > debugger and try to exit, then ctrl-c it to find out where the
> > deadlock is occurring. Note there may well be several threads
> > running.
> >
> > Another thing you could try is disabling threading via setting the env
> > OSG_THREADING=SingleThreaded.
> >
> > As general notes osgvertexprogram and osgscalarbar are all pretty
> > standard examples and don't do anything special. So if these deadlock
> > then its likely just down to timing, and that the same could happen to
> > other examples if and when the timing changes. This type of
> > inconsistent behavior is rather common issue with debugging
> > multi-threaded apps.
> >
> > > So if you can fix these 4 error, than we will get a nice version
for
> VC2003
> > > :-) Wrappers:
> > >
>
--------------------------------------------------------------------------------------------------------------------------------
> > >
>
C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osg\PrimitiveSet.cpp(875):
> > > error C2947: expecting '>' to terminate template-argument-list,
found
> '>>'
> > >
>
C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osg\Array.cpp(608):
> > > error C2947: expecting '>' to terminate template-argument-list,
found
> '>>'
> > >
>
C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osgText\Text.cpp(383):
> > > error C2026: string too big, trailing characters truncated
> > >
>
C:\dev\OpenSceneGraphCVS\OpenSceneGraph\src\osgWrappers\osgText\String.cpp(85):
> > > error C2947: expecting '>' to terminate template-argument-list,
found
> >
> > I have just checked in a few extra spaces into I_BaseType and
> > I_VirtualBaseType entries in
> osgIntrospection/ReflectionMacros,
> > fingers crossed this will solve the three of the above. This change
> > in now checked in.
> >
> > The string too big problem sound a bit more problematic though, sounds
> > like a compiler limitation.
> >
> > Robert.
> > _______________________________________________
> > osg-users mailing list
> > [email protected]
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
