Hi Adrian and Robert,
The template-argument-list errors look to be due to a lack of spaces in the typeof macro. Here's a new Reflection header which should fix those problems. For consistency I think that's the best solution. I'm not sure how best to address the string length problem. If a workaround is desired it probably would have to be implemented in genwrapper. I could tackle that, but not in the very near future. -Mike ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Egli Sent: Thursday, February 15, 2007 8:50 AM To: osg users Subject: Re: [osg-users] Please test CVS version of OpenSceneGraph 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.c pp > > 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(60 8): > > > 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.c pp(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/
Reflection
Description: Reflection
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
