Re: [osg-users] Why Compiled OSG is slower than pre-compiled version?
GeeKer Wang writes: > Unfortunately, after I have add the CXXFLAG, still the compiled version runs > "bin/osgviewer cow.osg" with fps<10, > while the RPM version fps>40. > > It seems even worse than before. > Did you make sure that cmake is using those flags during the build by adding VERBOSE=1 to the make call? I say because it's CXXFLAGS, not CXXFLAG. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Porting GraphicsWindowWin32 and PixelBufferWin32 from WGL to EGL
I'm moving along with this port. osgViewer is partially running on top of
imgtek's PVRVFrame ES 2.0 emulator on Windows 7. At this point, osgViewer
starts ups, OGLES initialization is working, windows are created, and the
emulator's control panel opens up. When I run osgViewer with cow.osg, a problem
occurs compiling a shader.
The problem is most likely a compatibility issue so hopefully someone with more
experience might see the problem.
When I look at the call stack, a runtime access violation occurs in
libGLES2v2.dll. The last function in osg before calling into the emulator is
osg::Shader::compileShader and the program ends.
The following is output by the PVRVFrame libraries and/or osg. Though I'm only
trying to use the GLESv2 library, the results are the same if the v1 library is
in the path or not.
Code:
PVRVFrameSetGlesLibraryPath: C:\Windows\system\libGLES_CM.dll
PVRVFrameSetGlesv2LibraryPath: C:\Windows\system\libGLESv2.dll
vendor/shl: Imagination Technologies (Host GL: `ATI Technologies Inc.`)
vendor/shl: OpenGL ES 1.1 ( SDK build: 2.07.27.0297)3.3.10061 Compatibility
Profile Context`)
bufek withs es1 exts: OGLES1 EXTENSIONS: GL_OES_byte_coordinates
GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get
GL_OES_read_format GL_OES_compressed_paletted_texture
GL_OES_point_sprite GL_OES_point_size_array GL_OES_matrix_palette
GL_OES_dra w_texture GL_OES_query_matrix GL_IMG_read_format
GL_IMG_texture_compression_pvrtc GL_IMG_texture_format_BGRA
GL_OES_texture_ env_crossbar GL_OES_texture_mirrored_repeat
GL_OES_blend_subtract GL_OES_blend_func_separate
GL_OES_blend_equation_separate GL_O ES_stencil_wrap
GL_OES_extended_matrix_palette GL_OES_stencil8 GL_OES_rgb8_rgba8
GL_OES_depth24 GL_OES_texture_cube_map
GL_OES_compressed_ETC1_RGB8_texture GL_OES_mapbuffer
GL_EXT_multi_draw_arrays GL_OES_framebuffer_object
vendor/shl: Imagination Technologies (Host GL: `ATI Technologies Inc.`)
vendor/shl: OpenGL ES 2.0 ( SDK build: 2.07.27.0297) 3.3.10061 Compatibility
Profile Context`)
vendor/shl: OpenGL ES GLSL ES 1.00 ( Host GL: `3.30`)
Warning: detected OpenGL error 'invalid enumerant' at Before Renderer::compile
The first shader being compiled breaks. It appears to be generated by
osg::ShaderGenCache::createStateSet(). Here it is:
Code:
varying vec3 normalDir;
varying vec3 lightDir;
varying vec3 viewDir;
void main()
{
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
gl_TexCoord[0] = osg_MultiTexCoord0;
normalDir = osg_NormalMatrix * osg_Normal;
vec3 dir = -vec3(osg_ModelViewMatrix * osg_Vertex);
viewDir = dir;
vec4 lpos = gl_LightSource[0].position;
if (lpos.w == 0.0)
lightDir = lpos.xyz;
else
lightDir = lpos.xyz + dir;
}
Any ideas about what the problem might be?
Thanks,
- Eric
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36866#36866
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why Compiled OSG is slower than pre-compiled version?
Unfortunately, after I have add the CXXFLAG, still the compiled version runs "bin/osgviewer cow.osg" with fps<10, while the RPM version fps>40. It seems even worse than before. On Sat, Feb 19, 2011 at 9:39 PM, Alberto Luaces wrote: > GeeKer Wang writes: > > > My system is i686, and I found there is no -march=i686 by default. > > > > I found this in CMakeCache.txt > >CMakeCache.txt://Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS > >CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS:INTERNAL=1 > > > > > CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS_COMPILED:INTERNAL=TRUE > > > CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS_EXITCODE:INTERNAL=0 > > Is there a problem? > > > > I think it's fine, since it's using the same as Fedora (the GCC atomic > builtins which have good performance). > > > > > I'll add CXXFLAGS as you mentioned and compile again. > > > > If you want to be sure to be using them, compile with > > make VERBOSE=1 > > -- > Alberto > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
Hi Ralf and Glen, It's good to know something has been done on this. Maybe osgearth_viewer will have the same capability before long. Usually when an app does not have scope the CPU drops. Even when an example is minimized to the task bar the CPU is the same but switches which core uses the most. Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36864#36864 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hiding and Showing a Node with Key Press
Thanks that did the trick. Just for other's reference this is what worked
well for me using setNodeMask():
// Keyboard Event Handler to Show/Hide Node
class HideQuadKeyboardEventHandler : public osgGA::GUIEventHandler
{
public:
HideQuadKeyboardEventHandler(osg::Node* node) { _node = node;
visible = true; }
virtual bool handle(const osgGA::GUIEventAdapter&
ea,osgGA::GUIActionAdapter&);
virtual void accept(osgGA::GUIEventHandlerVisitor& v) {
v.visit(*this); };
private:
bool visible;
osg::Node* _node;
};
bool HideQuadKeyboardEventHandler::handle(const osgGA::GUIEventAdapter&
ea,osgGA::GUIActionAdapter& aa)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::KEYDOWN):
{
switch(ea.getKey())
{
// Toggle Node on and Off
case 'x':
{
if(_node)
{
visible = !visible;
_node->setNodeMask(visible ? 0x : 0x0);
}
return false;
}
break;
default:
return false;
}
}
default:
return false;
}
}
On Fri, Feb 18, 2011 at 11:31 PM, Judson Weissert wrote:
> If you associate a node mask to each type of node that may need to be
> hidden using setNodeMask(), you can then modify the cull mask of the camera
> to show/hide the nodes accordingly.
>
> osg::Camera::setCullMask (mask) - would be called when the keyboard button
> is pressed.
> osg::Node::setNodeMask (mask) - would be called when creating the original
> scene graph.
>
> If you use osg::SwitchNode, it would be a slightly different process, but
> similar.
>
> - Judson
>
> ___
> 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] CPU usage
Neil, osgviewer --run-on-demand (probably doesn't work with osgEarth at the moment though.) Glenn On Sat, Feb 19, 2011 at 1:15 PM, Neil Neilson wrote: > Hi, > > What can be done to reduce CPU usage when the image is not being > changed/updated? > > After trying the examples using a pre-built 2.9.9 and the latest from the > SVN built with VS10 the CPU usage is high. > On a dual core one is nearly max and the other core is minimal. > > With an app that much of the time may only call for an update or redraw > once a second then it seems a double buffer > could display the stationary image with minimal CPU. > > This is something I have not had to tinker with since what I have used > before this was build into the SDKs. > > I am new to OSG (and osgEarth) so this issue may have been brought up > before but could not find it. > > Thank you! > > Cheers, > Neil > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=36859#36859 > > > > > > ___ > 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] CPU usage
Hi Niel I have not tried this myself, but I remember that support was added for manually handling the render loop. OSG will default to a render loop that follows your screen refresh, and if this is forced off it will redraw as fast as possible. But i think there is support for handling when to initiate the redraw from within your application. If you do this CPU usage should go down drastically if you don't have to redraw often. There should be some discussion of this on the mailing list, but I don't have a link so you will have to do the digging yourself. Brgs. Ralf Stokholm http://www.arenalogic.com On 19 February 2011 19:15, Neil Neilson wrote: > Hi, > > What can be done to reduce CPU usage when the image is not being > changed/updated? > > After trying the examples using a pre-built 2.9.9 and the latest from the > SVN built with VS10 the CPU usage is high. > On a dual core one is nearly max and the other core is minimal. > > With an app that much of the time may only call for an update or redraw > once a second then it seems a double buffer > could display the stationary image with minimal CPU. > > This is something I have not had to tinker with since what I have used > before this was build into the SDKs. > > I am new to OSG (and osgEarth) so this issue may have been brought up > before but could not find it. > > Thank you! > > Cheers, > Neil > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=36859#36859 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Ralf Stokholm Director R&D Email: a...@arenalogic.com Phone: +45 28 30 83 52 Web: www.arenalogic.com This transmission and any accompanying documents are intended only for confidential use of the designated recipient(s) identified above. This message contains proprietary information belonging to Arenalogic Aps. If you have received this message by error, please notify the sender. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osg.js
Very awesome!
I'm especially interested in the JS side - I've just been looking for a
javascript linear algebra library to use with my own project
(http://www.sourceforge.net/apps/mediawiki/delta3d-extras/index.php?title=DtEntity)
Mind if I lift your vector, matrix and quat classes? I've already tried them
out and they seem to work perfect!
The only thing I missed was a function to rotate a vec around a quaternion, so
I wrote one:
(in osg.Quat:)
Code:
rotate: function(q, v, result) {
var uv = [0, 0, 0];
var uuv = [0, 0, 0];
osg.Vec3.cross(q, v, uv);
osg.Vec3.cross(q, uv, uuv);
osg.Vec3.mult(uv, 2.0 * q[3], uv);
osg.Vec3.mult(uuv, 2.0, uuv);
osg.Vec3.add(v, uv, result);
osg.Vec3.add(result, uuv, result);
},
Thank you!
Cheers,
Martin
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36860#36860
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CPU usage
Hi, What can be done to reduce CPU usage when the image is not being changed/updated? After trying the examples using a pre-built 2.9.9 and the latest from the SVN built with VS10 the CPU usage is high. On a dual core one is nearly max and the other core is minimal. With an app that much of the time may only call for an update or redraw once a second then it seems a double buffer could display the stationary image with minimal CPU. This is something I have not had to tinker with since what I have used before this was build into the SDKs. I am new to OSG (and osgEarth) so this issue may have been brought up before but could not find it. Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36859#36859 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why Compiled OSG is slower than pre-compiled version?
GeeKer Wang writes: > My system is i686, and I found there is no -march=i686 by default. > > I found this in CMakeCache.txt >CMakeCache.txt://Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS >CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS:INTERNAL=1 > > CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS_COMPILED:INTERNAL=TRUE >CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS_EXITCODE:INTERNAL=0 > Is there a problem? > I think it's fine, since it's using the same as Fedora (the GCC atomic builtins which have good performance). > > I'll add CXXFLAGS as you mentioned and compile again. > If you want to be sure to be using them, compile with make VERBOSE=1 -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android Development Plans
> > What i've not compiled is plugins (This weekend work was to make them >> compilable with searches for a 3rd party directory of android ports of >> some of them) >> > > I assume you mean plugins that require 3rd party dependencies... Did you > build the .osg reader plugin? Or the new serializer plugins? I'll explain better: Src Directory Compiled: OpenThreads, osg osgAnimation osgDB osgFX osgGA osgManipulator osgParticle osgPresentation osgShadow osgSim osgTerrain osgText osgUtil osgViewer osgWidget Not Compiled: osgQt (although I've heard something about a port of Qt to Android) Src/osgWrappers/deprecated-dotosg None of those has been compiled. Src/osgWrappers/serializers Compiled: Everything Src/osgPlugins None of those has been compiled (this is my work for today) I was doing all this work to merge it in a project so I'm in the need of half the 3rd party dependency. pnj,jpg,gif,zlib,curl So expect at least that to be integrated in the Cmake script by the end of the day. The rest of dependencies will be a matter of test and try if someone is willing to look at them. > We are using TrackballManipulator (but there is nothing wrong to change >> it, just lack of time to test) >> > > This begs the question, what does Android use for multi-touch? Would the > support Stephan Maximilian Huber added for multi-touch be usable on Android? Android makes events that are captured (or not) by the Activity listeners. I didn't use the multitouch capabilities of Stephan because i didn't know how it was working. In The Android side all i can tell you is that you can't have more than two fingers at the same time prior to 2.0. Above 2.0 the limit is 256 but there are only a few devices that let you use more than two fingers (i.e. my archos 70 tablet) > Here are some pictures to show the state (basically the first and >> second, the third and fourth ore for those that will say it's fake xD) >> Btw it's an Archos 70 Internet Tablet what we are using. >> > > Great work guys! Keep it up, but don't wait too long before getting your > changes integrated, that way others can help too. > > We are still finishing the work and we like to clean the code it's a little bit messy because while changing scripts i've been suffering a lot of silly errors that make you change everything to see that it was just how ndk-build is supposed to work etc... By next week i'll have a full example written on Android 2.1 /Ndk r5b (I'm not planning a full native version, it needs 2.3 and i don't have a device. I really don't like Android Emulator) and the patches. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why Compiled OSG is slower than pre-compiled version?
My system is i686, and I found there is no -march=i686 by default. I found this in CMakeCache.txt CMakeCache.txt://Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS:INTERNAL=1 CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS_COMPILED:INTERNAL=TRUE CMakeCache.txt:_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS_EXITCODE:INTERNAL=0 Is there a problem? I'll add CXXFLAGS as you mentioned and compile again. On Sat, Feb 19, 2011 at 4:53 PM, Alberto Luaces wrote: > GeeKer Wang writes: > > > I tried without optimzation: let CMAKE_BUILD_TYPE be empty. > > > > It works even worse. And I don't know why the RPM version doesn't > > comflict with compiz on my computer while the compiled version does. > > Ok, I couldn't find the build logs for 2.8.3-3.fc14 but found instead > the ones belonging to 2.8.3-6.fc14. I don't know if you are in i686 or > x86_64, I'll let you choose the correct build log: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=209310 > > Reading the i686 log, for example, shows that I was misleaded with > respect to the compilation flags. They don't specify any in the spec file > because they set them as environment variables that CMake takes at > runtime. An they are very specific, indeed :) > > CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom > -fasynchronous-unwind-tables' > > The other thing I'd check is if you are obtaining the same atomic > operation kind as them. Check if the following paragraph extracted from > the log matches yours: > > -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS > -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS - Success > > I'm beginning to think that -march=i686 is the key if you are on i686. > > -- > Alberto > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why Compiled OSG is slower than pre-compiled version?
GeeKer Wang writes: > I tried without optimzation: let CMAKE_BUILD_TYPE be empty. > > It works even worse. And I don't know why the RPM version doesn't > comflict with compiz on my computer while the compiled version does. Ok, I couldn't find the build logs for 2.8.3-3.fc14 but found instead the ones belonging to 2.8.3-6.fc14. I don't know if you are in i686 or x86_64, I'll let you choose the correct build log: http://koji.fedoraproject.org/koji/buildinfo?buildID=209310 Reading the i686 log, for example, shows that I was misleaded with respect to the compilation flags. They don't specify any in the spec file because they set them as environment variables that CMake takes at runtime. An they are very specific, indeed :) CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' The other thing I'd check is if you are obtaining the same atomic operation kind as them. Check if the following paragraph extracted from the log matches yours: -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS - Success I'm beginning to think that -march=i686 is the key if you are on i686. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
