Re: [osg-users] Android osgPlugins
Hi,
Yes indeed is related to the STL. Recent versions of the NDK should have
better support but I always find problems with that.
In the end I always copy the gnustl_static library from the android ndk to
the OSG_SDK, but the android ndk should support it without that kind of
workarounds.
Could you try add this to the Application.mk?
APP_CFLAGS += -fexceptions
APP_STL := gnustl_static
And remove the -lgnustl_static from the list of static libraries?
If still does not work then I recommend copy the library manually and
continue with the current Android.mk.
Once I have more time I'll try a couple of solutions I found doing a quick
search, but if you find the solution I'll be more than happy to apply the
changes! :).
Regards,
Rafa.
2015-04-26 18:48 GMT+02:00 Christian Kehl christian-k...@web.de:
Hi,
I had a closer look to the errors and the Android.mk file.
osgdb_serializers_osgpresentation doesn't exist in my build (perhaps
missing in general - it wasn't in the 3.0.2 Android.mk file either, so
that's new things that is added and missing in the build).
leaving the following errors:
christian@PROMETHEUS:/media/christian/DATA/osgAndroid/org.openscenegraph.android$
${ANDROID_NDK}/ndk-build
[armeabi] Compile++ thumb: jniosg-gles1 = JNIosgViewer.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = JNIosg.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = JNIosgDB.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = JNIosgUtil.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = JNIosgGA.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = JNIUtils.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = MultiViewNode.cpp
[armeabi] Compile++ thumb: jniosg-gles1 = GLES2ShaderGenVisitor.cpp
[armeabi] SharedLibrary : libjniosg-gles1.so
/home/christian/Downloads/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld:
error: cannot find -lgnustl_static
/home/christian/android-install/lib/osgPlugins-3.3.7/libosgdb_ive.a(DataOutputStream.cpp.o):DataOutputStream.cpp:typeinfo
for osg::Node const*: error: undefined reference to 'vtable for
__cxxabiv1::__pointer_type_info'
/home/christian/Downloads/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld:
the vtable symbol may be undefined because the class is missing its key
function
/home/christian/android-install/lib/osgPlugins-3.3.7/libosgdb_serializers_osgparticle.a(RadialShooter.cpp.o):RadialShooter.cpp:function
osgParticle::rangefloat::get_random() const: error: undefined reference
to 'rand'
/home/christian/android-install/lib/osgPlugins-3.3.7/libosgdb_serializers_osgparticle.a(RadialShooter.cpp.o):RadialShooter.cpp:function
osgParticle::RadialShooter::shoot(osgParticle::Particle*) const: error:
undefined reference to 'rand'
/home/christian/android-install/lib/osgPlugins-3.3.7/libosgdb_serializers_osgparticle.a(RandomRateCounter.cpp.o):RandomRateCounter.cpp:function
osgParticle::RandomRateCounter::numParticlesToCreate(double) const: error:
undefined reference to 'rand'
/home/christian/android-install/lib/osgPlugins-3.3.7/libosgdb_serializers_osgparticle.a(SectorPlacer.cpp.o):SectorPlacer.cpp:function
osgParticle::SectorPlacer::place(osgParticle::Particle*) const: error:
undefined reference to 'rand'
/home/christian/android-install/lib/libosgWidget.a(Input.cpp.o):Input.cpp:function
osgWidget::Input::_calculateCursorOffsets(): error: undefined reference to
'std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/home/christian/android-install/lib/libosgWidget.a(Input.cpp.o):Input.cpp:function
osgWidget::Input::_calculateCursorOffsets(): error: undefined reference to
'std::__detail::_List_node_base::_M_unhook()'
/home/christian/android-install/lib/libosgWidget.a(Widget.cpp.o):Widget.cpp:function
osgWidget::Widget::Widget(osgWidget::Widget const, osg::CopyOp const):
error: undefined reference to
'std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/home/christian/android-install/lib/libosgWidget.a(Window.cpp.o):Window.cpp:function
osgWidget::Window::getParentList(std::listosg::observer_ptrosgWidget::Window,
std::allocatorosg::observer_ptrosgWidget::Window ) const: error:
undefined reference to
'std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/home/christian/android-install/lib/libosgWidget.a(Window.cpp.o):Window.cpp:function
osgWidget::Window::getEmbeddedList(std::listosg::observer_ptrosgWidget::Window,
std::allocatorosg::observer_ptrosgWidget::Window ) const: error:
undefined reference to
'std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/home/christian/android-install/lib/libosgViewer.a(CompositeViewer.cpp.o):CompositeViewer.cpp:function
void std::listosg::ref_ptrosgGA::Event,
std::allocatorosg::ref_ptrosgGA::Event
Re: [osg-users] Absolute_Rf to Relative_Rf coordinates
Hi Joao, Subgraphs under a ABSOLUTE_RF Transform are effectively in their own local world coordinate frame, they don't related to other word coordinate frames. You can relate to them view the eye coordinate frame if you want though, or shift them from one world coordinate frame into eye coordinate and then back out to another world coordinate frame so see the relative position of it. However, doing these transforms is view dependent, as every time the camera moves the relative positions all shift, this means you need to keep track of the view matrix as part of the shifting the coordinate frame from one world coordinate frame to another. Doing this may make sense in very specific cases, but it might be that you are simply trying to do things in an awkward way and there is a better way of doing things without the messy hack of mixing different world coordinate frames. Robert. On 27 April 2015 at 11:27, João joao.henrique.pi...@hotmail.com wrote: I'm displaying some text in a 3D scene using a transform with an absolute reference frame. I now need to find out what the world coordinates of the text are, is that any way to easily obtain that information? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineSegment intersect with Box and Sphere inconsistency
I believe both can be correct but it looks like in Box case r1 is ratio of segment length measured from start and r2 measured backwards from the segment end. For Sphere both r1 and r2 are measured from start. So here is the inconsistency... Cheers, Wojtek 2015-04-27 12:38 GMT+02:00 Robert Osfield robert.osfi...@gmail.com: Hi Wojtek, Thanks for the test code. I've built it on my system with OSG svn/trunk and get the same values reported. The values don't look appropriate in either case, I don't know the cause of the issue yet so am doing a code review now. Robert. On 25 April 2015 at 13:11, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: Hi, Robert, I have just stumbled on small issue in my intersection code which turned out to be related to different interpretation of r2 param returned by LineSegment::intersect( BoundingBox, r1, r2 ) and LineSegment::intersect( BoundingSphere, r1, r2 ). Example Code: osg::BoundingBox box( -1,-1,-1, 1, 1, 1 ); osg::BoundingSphere sphere( box ); osg::ref_ptr osg::LineSegment diagonal = new osg::LineSegment( box._min, box._max ); double box_r1, box_r2; diagonal-intersect( box, box_r1, box_r2 ); double sphere_r1, sphere_r2; diagonal-intersect( sphere, sphere_r1, sphere_r2 ); printf( Box r1=%.0f r2=%.0f Sphere r1=%.0f r2=%.0f \n, box_r1, box_r2, sphere_r1, sphere_r2 ); Output: Box r1=0 r2=0 Sphere r1=0 r2=1 Is that a bug or deliberate design ? Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineSegment intersect with Box and Sphere inconsistency
Hi Wojtek, Thanks for the test code. I've built it on my system with OSG svn/trunk and get the same values reported. The values don't look appropriate in either case, I don't know the cause of the issue yet so am doing a code review now. Robert. On 25 April 2015 at 13:11, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: Hi, Robert, I have just stumbled on small issue in my intersection code which turned out to be related to different interpretation of r2 param returned by LineSegment::intersect( BoundingBox, r1, r2 ) and LineSegment::intersect( BoundingSphere, r1, r2 ). Example Code: osg::BoundingBox box( -1,-1,-1, 1, 1, 1 ); osg::BoundingSphere sphere( box ); osg::ref_ptr osg::LineSegment diagonal = new osg::LineSegment( box._min, box._max ); double box_r1, box_r2; diagonal-intersect( box, box_r1, box_r2 ); double sphere_r1, sphere_r2; diagonal-intersect( sphere, sphere_r1, sphere_r2 ); printf( Box r1=%.0f r2=%.0f Sphere r1=%.0f r2=%.0f \n, box_r1, box_r2, sphere_r1, sphere_r2 ); Output: Box r1=0 r2=0 Sphere r1=0 r2=1 Is that a bug or deliberate design ? Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Absolute_Rf to Relative_Rf coordinates
I'm displaying some text in a 3D scene using a transform with an absolute reference frame. I now need to find out what the world coordinates of the text are, is that any way to easily obtain that information? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Enabling Vsync gives dramatic increase in latency
On Mon, Apr 27, 2015 at 3:20 PM, Björn Blissing bjorn.bliss...@vti.se wrote: Well, this is pretty much exactly my method. But instead of an oscilloscope I sample the signal with a A/D capture card at 10KHz. Here is the promised data about the Oculus Rift DK1 DK2: Oculus Rift DK1 + Vsync Off Min: 16.8 Max: 60.0 Avg: 37.6 Oculus Rift DK1 + Vsync On Min: 34.0 Max: 79.1 Avg: 48.1 Oculus Rift DK2 + Vsync Off Min: 17.0 Max: 65.0 Avg: 39.6 Oculus Rift DK2 + Vsync On Min: 24.0 Max: 70.1 Avg: 43.6 I also tested the latency on a Philips GLine screen, which supports Nvidia G-Sync. But I had to change GPU to do this, since G-Sync requires DisplayPort 1.2. So I had to upgrade to a GTX 770 card. Philips GLine + 60 Hz + Vsync Off Min: 2.8 Max: 23.0 Avg: 12.2 Philips GLine + 60Hz + Vsync On Min: 37.0 Max: 63.1 Avg: 60.7 Philips GLine + 60 Hz + Gsync Min: 58.9 Max: 63.1 Avg: 60.9 Philips GLine + Native 144Hz + Vsync On Min: 22.9 Max: 26.1 Avg: 24.5 Interesting data, thanks for the experiment. I think the deal with the G-sync being worse on average than pure Vsync is due to the fact that G-sync is designed more to provide smooth, jitter-free experience by locking the screen refresh rate to the scanout rate of the card (avoids the missed sync problem) than to actually minimize latency. In your case it seem that there are about 3 frames in flight on the GPU whenever Vsync/Gsync is on, regardless of framerate. I guess that this would need someone familiar with the actual driver code from Nvidia to explain why they are buffering that much - my bet is performance reasons, to keep the GPU pipeline from stalling. J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to switch two state of animation Object smoothly?
Hi Robert, I have two animations of an Object, such as Jog.FBX and Run.FBX. Whel an animation is Jog, i want finish it's duration before moving to Run state ( or vice versa ), but i don't know how to do this. Could you show me the way ( or book, link, knowledge ...) that i can switch smoothly between two state? Thank you! Cheers, Nguyen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63547#63547 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineSegment intersect with Box and Sphere inconsistency
Hi Robert, I am little concerned that some end user code will be using these intersects methods and working around their inconsistency, so if we fix them then we could end up breaking end user code. I am one of those users now ;-). However, I adopt easily. Others may not notice the change, though. Perhaps better solution would be to leave the functionality as is and clearly rename and/or comment the r1,r2 params to (rFromStart rFromEnd ?) so that inconsistency is clear and does not surprise future users ? Cheers, Wojtek 2015-04-27 13:28 GMT+02:00 Robert Osfield robert.osfi...@gmail.com: Hi Wojtek, On 27 April 2015 at 12:15, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: I believe both can be correct but it looks like in Box case r1 is ratio of segment length measured from start and r2 measured backwards from the segment end. For Sphere both r1 and r2 are measured from start. So here is the inconsistency... This is my assessment too. I have #if def'd out the LineSegment::intersect(const BoundingBox bb,float r1,float r2) style methods from LineSegment and have been able to compile the whole OSG, so it looks like these methods have been written but not used and tested by the OSG itself so the errors haven't been picked up. This leaves us with deciding what to do with these erroneous methods. One route is to remove them, another is to change their behaviour so it's consistent and document this change. To make the method consistent I feel that they should return the ratio between the start and end points, measured from the start. I am little concerned that some end user code will be using these intersects methods and working around their inconsistency, so if we fix them then we could end up breaking end user code. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineSegment intersect with Box and Sphere inconsistency
Hi Wojtek, On 27 April 2015 at 12:15, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: I believe both can be correct but it looks like in Box case r1 is ratio of segment length measured from start and r2 measured backwards from the segment end. For Sphere both r1 and r2 are measured from start. So here is the inconsistency... This is my assessment too. I have #if def'd out the LineSegment::intersect(const BoundingBox bb,float r1,float r2) style methods from LineSegment and have been able to compile the whole OSG, so it looks like these methods have been written but not used and tested by the OSG itself so the errors haven't been picked up. This leaves us with deciding what to do with these erroneous methods. One route is to remove them, another is to change their behaviour so it's consistent and document this change. To make the method consistent I feel that they should return the ratio between the start and end points, measured from the start. I am little concerned that some end user code will be using these intersects methods and working around their inconsistency, so if we fix them then we could end up breaking end user code. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Enabling Vsync gives dramatic increase in latency
d_a_heitbrink wrote: What we did for our test was trigger a A/D deviceto I think a go from 0 to 5v, and a we added a line in our fragment shader to over ride the color and set it to white, or black depending on a value of a uniform. We change the Uniform to 1 (to set it to white) and sent out our 5 v signal at the same time. Both were set at the start of a frame. We used a photo diode to pick up the change from black to white, and hooked that and our 5v signal to a oscilloscope. Well, this is pretty much exactly my method. But instead of an oscilloscope I sample the signal with a A/D capture card at 10KHz. Here is the promised data about the Oculus Rift DK1 DK2: Oculus Rift DK1 + Vsync Off Min: 16.8 Max: 60.0 Avg: 37.6 Oculus Rift DK1 + Vsync On Min: 34.0 Max: 79.1 Avg: 48.1 Oculus Rift DK2 + Vsync Off Min: 17.0 Max: 65.0 Avg: 39.6 Oculus Rift DK2 + Vsync On Min: 24.0 Max: 70.1 Avg: 43.6 I also tested the latency on a Philips GLine screen, which supports Nvidia G-Sync. But I had to change GPU to do this, since G-Sync requires DisplayPort 1.2. So I had to upgrade to a GTX 770 card. Philips GLine + 60 Hz + Vsync Off Min: 2.8 Max: 23.0 Avg: 12.2 Philips GLine + 60Hz + Vsync On Min: 37.0 Max: 63.1 Avg: 60.7 Philips GLine + 60 Hz + Gsync Min: 58.9 Max: 63.1 Avg: 60.9 Philips GLine + Native 144Hz + Vsync On Min: 22.9 Max: 26.1 Avg: 24.5 Best regards Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63548#63548 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Enabling Vsync gives dramatic increase in latency
Some minor notes about the latest numbers. First of all, the Oculus units were used as pure screens, i.e. no lens distortion shaders. For DK2 this means running the unit in extended mode. (To be able to run via Direct Mode I would have to modify my test program to use the Oculus SDK.) Secondly, the Oculus screens were set to work at their native rate. i.e. DK1 screen was set at 60Hz and the DK2 at 75Hz. Lastly, all tests were performed with Nvidias default settings, except for VSync/GSync. No other custom driver settings were used. Regards, Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63550#63550 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineSegment intersect with Box and Sphere inconsistency
Hi Wojtek, On 27 April 2015 at 13:16, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: I am one of those users now ;-). However, I adopt easily. Others may not notice the change, though. Perhaps better solution would be to leave the functionality as is and clearly rename and/or comment the r1,r2 params to (rFromStart rFromEnd ?) so that inconsistency is clear and does not surprise future users ? My current feeling is that the intersect methods should be consistent, the sphere one uses ratio between start and end for both the first and second intersections points, while the bounding box version provides the ratio between start and end, and end and start respectively. Other intersect code in the OSG uses the same convention as the sphere intersection. I have fixed the LineSegment::intersect(const BoundingBox bb,float r1,float r2) const and double variant so they are now consistent with other parts of the OSG. I'm undecided what to do about breaking user code that relies upon the old behaviour. One option would be to have CMake option to toggle the behaviour, another would be to rename the problem method to force a build break so users have to investigate and have a better chance of spotting the change in behaviour. A Cmake option would just add complexity to the build system and source code for something that might not affect any end users. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineSegment intersect with Box and Sphere inconsistency
Hi Wojtek,
I have decided I'd rather change the method name and break the build
rather than silently change the behaviour of method in a way that
could break end user code. What I have gone for is:
--- include/osg/LineSegment (revision 14855)
+++ include/osg/LineSegment (working copy)
@@ -44,45 +44,48 @@
inline bool valid() const { return _s.valid() _e.valid()
_s!=_e; }
+
/** return true if segment intersects BoundingBox. */
bool intersect(const BoundingBox bb) const;
-/** return true if segment intersects BoundingBox
- * and return the intersection ratios.
+/** return true if segment intersects BoundingBox and
+ * set float ratios for the first and second intersections,
where the ratio is 0.0 at the segment start point, and 1.0 at the
segment end point.
*/
-bool intersect(const BoundingBox bb,float r1,float r2) const;
+bool intersectAndComputeRatios(const BoundingBox bb, float
ratioFromStartToEnd1, float ratioFromStartToEnd2) const;
-/** return true if segment intersects BoundingBox
- * and return the intersection ratios.
+/** return true if segment intersects BoundingBox and
+ * set double ratios for the first and second intersections,
where the ratio is 0.0 at the segment start point, and 1.0 at the
segment end point.
*/
-bool intersect(const BoundingBox bb,double r1,double r2) const;
+bool intersectAndComputeRatios(const BoundingBox bb, double
ratioFromStartToEnd1, double ratioFromStartToEnd2) const;
+
/** return true if segment intersects BoundingSphere. */
bool intersect(const BoundingSphere bs) const;
-/** return true if segment intersects BoundingSphere and return the
- * intersection ratio.
+/** return true if segment intersects BoundingSphere and
+ * set float ratios for the first and second intersections,
where the ratio is 0.0 at the segment start point, and 1.0 at the
segment end point.
*/
-bool intersect(const BoundingSphere bs,float r1,float r2) const;
+bool intersectAndComputeRatios(const BoundingSphere bs,
float ratioFromStartToEnd1, float ratioFromStartToEnd2) const;
-/** return true if segment intersects BoundingSphere and return the
- * intersection ratio.
+/** return true if segment intersects BoundingSphere and
+ * set double ratios for the first and second intersections,
where the ratio is 0.0 at the segment start point, and 1.0 at the
segment end point.
*/
-bool intersect(const BoundingSphere bs,double r1,double r2) const;
+bool intersectAndComputeRatios(const BoundingSphere
bs,double ratioFromStartToEnd1, double ratioFromStartToEnd2) const;
-/** return true if segment intersects triangle
- * and set ratio long segment.
+/** return true if segment intersects triangle and
+ * set float ratios where the ratio is 0.0 at the segment
start point, and 1.0 at the segment end point.
*/
-bool intersect(const Vec3f v1,const Vec3f v2,const Vec3f
v3,float r);
+bool intersect(const Vec3f v1,const Vec3f v2,const Vec3f
v3,float ratioFromStartToEnd);
-/** return true if segment intersects triangle
- * and set ratio long segment.
+/** return true if segment intersects triangle and
+ * set double ratios where the ratio is 0.0 at the segment
start point, and 1.0 at the segment end point.
*/
-bool intersect(const Vec3d v1,const Vec3d v2,const Vec3d
v3,double r);
+bool intersect(const Vec3d v1,const Vec3d v2,const Vec3d
v3,double ratioFromStartToEnd);
I hope this make sense. This change is now checked into svn/trunk.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
