Re: [osg-users] unknown Quicktime SDK error...
Well, on the other pc there was an old version, but I upgraded it because of another error code. Currently I have the last version becuase quicktime player upgraded itself by internet, so I think it downloaded latest version available...I guess. I also tried to play movies with the player and it works, anyway, I can play them also within my osg application, so the plugin is working fine, despite of that unknown error... I just wonder what that error means. Regards. Alessandro On 8/2/07, Stephan Huber [EMAIL PROTECTED] wrote: alessandro terenzi schrieb: I wanted to test my osg application on another pc... so I moved every required dll on the other machine... in my application I use to play movies using quicktime plugin but at the beginning of the application I get the following error code from Quicktime SDK: -2002 I found out that -2002 corrensponds to badPublicMovieAtom ... actually the application seems to run without problems, but I wonder what that error means, does anybody know it? Did you install quicktime on the other pc? What version did you install? Did you try to play one of your movies with the regular quicktime-player? Stephan ___ 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] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
HI Michael, On 8/2/07, Michael Ebner [EMAIL PROTECTED] wrote: 1.) How do i get access to a RenderStage object, to set the sorting (i.e. osgUtil::RenderBin::SORT_FRONT_TO_BACK) so that my transparent object are rendered correctly? This is bit of backward solution to your transparent object problem - you aren't setting up your scene graph correctly, you should be setting the transparent subgraphs to fall into the transparent rendering bin via: stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); This is how the OSG has managed transparent state since the turn of this century. There is more fine grained control of render bins available via StateSet as well, but this is whole big topic, but on another occassion. First just fix your scene graphs. 2.) How can i get access to osgUtil::Statistics which i formerly accessed through RenderStage? In 2.0 osgViewer there isn't a convenient way to get access to the SceneView used for rendering. In the latest in SVN the Camera's now have a osgViewer::Renderer objects that you can use to get access to the SceneView and from their the RenderStage and the Statistics. 3.) Is there any way to use the new Multi-Threading Model, although the viewer is used as osgViewer::GraphicsWindowEmbedded gw = viewer_-setUpViewerAsEmbeddedInWindow(...) ? GraphicsWindowEmbedded does not support multi-threading. To use the new threading models you'll need to use a full blown GraphicsWindow implementation. 4.) What exactly is the advantage of putting sutff that is rendered outside of osg into the Camera's Pre/PostDrawCallback? (as mentioned in a previous posting) Previous posting? Lost me there, there are lots of postings on lots of topics, some mention Camera pre/post draw callbacks. As general note, integrating other OpenGL code with app can be done via custom Drawable (as per osgteapot example), via pre/post draw callbacks, via custom GraphicsOperations that you attach to the GraphicsWindow/GraphicsThread, or just in the main loop if you are running single theaded. The advantage of using subclassing OSG centric methods for adding your OpenGL code is that it can help manage the threading for you and ordering. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
Hello Robert, Robert Osfield wrote: stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); This is how the OSG has managed transparent state since the turn of this century. There is more fine grained control of render bins available via StateSet as well, but this is whole big topic, but on another occassion. First just fix your scene graphs. I was already setting the TRANSPARENT_BIN, but had z write disabled and the RenderBin::SORT_FRONT_TO_BACK did the sorting. But it is working now, thanks. GraphicsWindowEmbedded does not support multi-threading. To use the new threading models you'll need to use a full blown GraphicsWindow implementation. Could you explain that to me in more detail? I took a quick look at the GraphicsWindowEmbedded and GraphicsWindowWin32 implementation and this seems all to be about setting up a window and providing a context to the Viewer. The Viewer is handling the threads based on the context(s) provided, so it should not make a difference if he gets them from embedded or full blown GraphicsWindow? Or am i missing something here? I'm using SDL for window and input handling and read in: http://www.mail-archive.com/[EMAIL PROTECTED]/msg12744.html about a GraphicsWindowSDL class, is it going to be submitted to SVN? Thanks for help and keep up the good work! greetings, Michael. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compiling examples
Hi Peter, On 8/3/07, Peter Gebauer [EMAIL PROTECTED] wrote: The mouse is working, the keyboard does not. To make the keyboard work again I have to click on the border of a window. This is just a focus issue, its not that keyboard isn't working. Might be the WM, although, only OSG apps hit this problem. Have you tried examples like osgviewerFLTK, osgviewerQT to see if they have the same problem. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
Hi Doug, There are number of hoops one has to jump through to do safe multi-threading with the OSG, osgViewer does these all for you, while SceneView knows nothing of it and requires higher level classes to handle it. osgViewer itself does use SceneView so does illustrate that it is possible using SceneView so you could possible use this as guide. Personally I'd recommend that VRJuggler just use osgViewer for creating the windows and cameras as per the configuration required by VRJuggler, this way you can take advantage of all the threading models that osgViewer provides in a way that is known to be thread safe. Another key advantage of adopting osgViewer is that problems you see will be much more reproducible by others who don't use VRJuggler. For instance you could create a scene that uses a ClearNode and run in standard OSG examples, and if the problems exists then I and others can look into it. With the current state of play, trying to help diagnose what might be up would require a massive time investment in getting VR Juggler installed, learning about it, setting up the case that reproduces the problem, then stepping through to see where the problem lies. The alterntaive of trying to debug this stuff remotely with even knowing all the VRJuggler code is no mean feat either - there are many things that VR Juggler could be doing wrong w.r.t multi-threaded set up of the OSG, or it could a problem on the OSG side. Trying to sort it out this way would again require a huge investment of time all round. I'm afraid I'm certainly too over stretched to undertake such a process. One of osgViewer core goals is making multi-thread, multi-channel usage of the OSG straight forward, hiding all the subtle details and thread synchronization that is required. I'm not familiar with VR Juggler, but I would have though it should possible to replace the existing SceneView framework with a osgViewer::Viewer object and have the Viewer's windows and cameras all set up according to VR Juggler configuration. Robert. On 8/2/07, Doug McCorkle [EMAIL PROTECTED] wrote: Hello, We are using SceneView from OSG 1.2 and VR Juggler in a multiple render thread environment. We are using the osgUtil::UpdateVisitor to update the graph in a serial portion of our code. SceneView::cull and SceneView::draw are called from each rendering thread. In this configuration we often see the displays flash the clear color on a random basis. We are setting the clear color through the use of a ClearNode and we clear the depth buffer at the beginning of the draw function. The flashing of the clear color is not seen when only one render thread is utilized. Is there a reason we are be seeing this behavior? Are we mismanaging something in our draw loop? Thanks for the help. Doug PS. Initial testing has shown this to occur under the OSG 1.9.x series as well. ___ 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, VR Juggler, and multiple render threads...
We are using SceneView from OSG 1.2 and VR Juggler in a multiple render thread environment. We are using the osgUtil::UpdateVisitor to update the graph in a serial portion of our code. SceneView::cull and SceneView::draw are called from each rendering thread. In this configuration we often see the displays flash the clear color on a random basis. We are setting the clear color through the use of a ClearNode and we clear the depth buffer at the beginning of the draw function. Hi Doug -- Just thinking of this in OpenGL terms, the dreaded blank screen can have many many causes. One possible explanation: The cull traversal on one of the displays randomly thinks that everything is culled. This could be due to a configuration issue for the camera controlling that display, the modelview/projection matrices are bogus and/or the view volume used during the cull traversal isn't set correctly. You might consider hacking the code to dump such information out per frame. Yes, it will generate gobs of output, but if you do a short run and see a flash, then examine the debug output, any one-frame irregularities should jump out at you. If nothing shows up, then the problem is somewhere else. The other thought I had relates to the ClearNode. Does the problem go away if you eliminate the ClearNode and just let SceneView do its own clearing? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 答复: ??: A simple question from an learner.
Dear Mike,
Thanks for you help. Follow you then it worked. Thanks again.
Bingli
_
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Mike Wittman
发送时间: 2007年8月3日 22:17
收件人: osg-users@lists.openscenegraph.org
主题: Re: [osg-users] ??: A simple question from an learner.
Hi Bingli,
I suspect you've got pure CLR support (/clr:pure) selected in your project
configuration, which tells the compiler you're only using managed code. You
need to have standard CLR support (/clr) selected to compile against the
native code of OSG. The setting is in the General section of your project's
Configuration Properties.
-Mike
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ijustfu
Sent: Thursday, August 02, 2007 8:57 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] ??: A simple question from an learner.
Dear Mike,
Thanks for you help. There are so many warnings and errors. Following
are some statements:
1-- Build started: Project: VGEForPRDAirPollution, Configuration: Debug
Win32 --
1Compiling...
1VGEForPRDAirPollution.cpp
1C:\OpenSceneGraph2.0\OpenSceneGraph\include\OpenThreads/Mutex(40) :
warning C4272: 'OpenThreads::Mutex::Mutex' : is marked
__declspec(dllimport); must specify native calling convention when importing
a function.
OpenThreads::Mutex::`vftable'' : per-appdomain symbol should not be marked
with __declspec(dllimport)
1C:\OpenSceneGraph2.0\OpenSceneGraph\include\osg/Referenced(64) : warning
C4272: 'osg::Referenced::ref' : is marked
..
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A0C)
public: void __clrcall osg::Referenced::ref(void)const
([EMAIL PROTECTED]@osg@@$$FQBMXXZ) referenced in function public: __clrcall
osg::ref_ptrclass osg::Referenced::ref_ptrclass osg::Referenced(class
osg::ref_ptrclass osg::Referenced const )
([EMAIL PROTECTED]@osg@@@osg@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A0D)
public: void __clrcall osg::Referenced::unref(void)const
([EMAIL PROTECTED]@osg@@$$FQBMXXZ) referenced in function public: __clrcall
osg::ref_ptrclass osg::Referenced::~ref_ptrclass osg::Referenced(void)
([EMAIL PROTECTED]@osg@@@osg@@[EMAIL PROTECTED])
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A11)
public: __clrcall osg::CopyOp::CopyOp(unsigned int)
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z) referenced in function public:
__clrcall
osg::RefMatrixd::RefMatrixd(class osg::RefMatrixd const )
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A12)
public: virtual __clrcall osg::CopyOp::~CopyOp(void)
([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(class osg::RefMatrixd const )
([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A13)
public: __clrcall osg::Object::Object(void) ([EMAIL PROTECTED]@@[EMAIL
PROTECTED])
referenced in function public: __clrcall
osg::StateAttribute::Callback::Callback(void)
([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED])
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A14)
public: __clrcall osg::Object::Object(bool) ([EMAIL PROTECTED]@@[EMAIL
PROTECTED]@Z)
referenced in function public: __clrcall osg::RefMatrixd::RefMatrixd(void)
([EMAIL PROTECTED]@@[EMAIL PROTECTED])
..
1Build log was saved at
file://d:\VGEForPRDAirPollution\TestNet\VGEForPRDAirPollution\VGEForPRDAirP
ollution\Debug\BuildLog.htm
1VGEForPRDAirPollution - 1227 error(s), 4507 warning(s)
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
Thanks and regards
Bingli
The Institute of Space and Earth Information Science,
The Chinese university of Hong Kong, Shatin, N.T., Hong Kong, P.R.China
-邮件原件-
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Mike Wittman
发送时间: 2007年8月2日 22:23
收件人: osg-users@lists.openscenegraph.org
主题: Re: [osg-users] A simple question from an learner.
OSG can definitely be used with WinForms. It sounds like you're running
into some project configuration issue though. If you can post your
error messages we might be able to provide better help.
-Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of ijustfu
Sent: Thursday, August 02, 2007 4:25 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] A simple question from an learner.
Dear Robert.
I build a simple OSG program with visual studio2005.net. I use c++
language , and select window forms application, then get the
following
codes:
#include stdafx.h
#include Form1.h
#include osgViewer/Viewer
#include osgDB/ReadFile
using namespace VGEForPRDAirPollution;
[STAThreadAttribute]
int main(arraySystem::String ^ ^args)
{
// Enabling Windows XP visual effects before any
[osg-users] Preliminary DISPLAY support checked into SVN
Hi All, I have now added preliminary support into osgViewer::View::setUpView*() methods for reading the DISPLAY variable in order to initialize the hostName, displayNum and screenNum. As helper functions there are now a ScreenIdentifier::readDISPLAY() and ScreenIdentifier::setScreenIdentifier(std::string) methods. Have a browse throught src/osgViewer/View.cpp to how they are used. Could those requesting this support check out the latest in SVN and test it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac Pro multiple display problems..
Hi Martin, On 8/3/07, martin.lavery [EMAIL PROTECTED] wrote: I have just been doing some testing on a 2.66 Ghz quad Mac Pro and i'm finding that it loads the first frame on only one display and then hangs.. This however this does not happen when only one display is connected. Has anyone else come across this issue? Could you try running the app with different threading models: osgviewer cow.osg --SingleThreaded osgviewer cow.osg --CullDrawThreadPerContext osgviewer cow.osg --DrawThreadPerContext osgviewer cow.osg --CullThreadPerCameraDrawThreadPerContext ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On Aug 3, 2007, at 10:47 AM, Paul Martz wrote: We are using SceneView from OSG 1.2 and VR Juggler in a multiple render thread environment. We are using the osgUtil::UpdateVisitor to update the graph in a serial portion of our code. SceneView::cull and SceneView::draw are called from each rendering thread. In this configuration we often see the displays flash the clear color on a random basis. We are setting the clear color through the use of a ClearNode and we clear the depth buffer at the beginning of the draw function. Hi Doug -- Just thinking of this in OpenGL terms, the dreaded blank screen can have many many causes. One possible explanation: The cull traversal on one of the displays randomly thinks that everything is culled. This could be due to a configuration issue for the camera controlling that display, the modelview/projection matrices are bogus and/or the view volume used during the cull traversal isn't set correctly. You might consider hacking the code to dump such information out per frame. Yes, it will generate gobs of output, but if you do a short run and see a flash, then examine the debug output, any one-frame irregularities should jump out at you. If nothing shows up, then the problem is somewhere else. I will give this a shot. The other thought I had relates to the ClearNode. Does the problem go away if you eliminate the ClearNode and just let SceneView do its own clearing? As far as we can tell SceneView does not do clearing or not that we can find. Am I incorrect here? I have never really been able to figure out how to get reliable clearing with SceneView. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgProducer::Viewer screen resolution
Hello Andreas, there's a camera associated with your viewer. This camera has a render surface that provides all the functions you are looking for. 1) How can I get actual screen resolution RenderSurface::getScreenSize(screenwidth, screenheight) 2) set osgProducer::Viewer to custom resolution RenderSurface::setWindowRectangle( x, y, windowwidth, windowheight ); 3) set osgProducer::Viewer to full screen. RenderSurface::fullscreen(bool ) \Tommes. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Emulate Fog with TexGen
Hey Everyone, I've been trying to emulate a fade to transparent effect (think of a linear fog that works on alpha, not color) using a 1D texture with 2 texels, 0 = opaque, 1 = transparent. My problem is with generating the texture coordinates I thought I could use a texgen with EYE_LINEAR and an s plane of (0, 0, 1/far_dist, 0) but that doesn't produce the correct result. The texture's wrap mode is GL_CLAMP. I've also tried negating 1/far_dist. Am I doing anything obviously wrong? Thanks for any info, Chase ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Paged Terrain and ground-tied entities
My application used paged terrain, and I require some entities to be tied to the ground. I am currently using an update callback in order to poll the current terrain height (osgUtil::IntersectVisitor) to ensure that the ground-tied entities are at the correct altitude. Unfortunately, this is a waste of processor resources (and framerate). I would like a way to determine that new terrain nodes have been loaded in order to minimize extraneous terrain polling. Is there a on new terrain callback? Can someone point me to an efficient strategy? Thanks, Justin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] invalid conversion from `int*' to `socklen_t*'
Hi, just wanted to let you know that I'm getting a compile error with current SVN on FreeBSD: [ 53%] Building CXX object src/osgPlugins/net/CMakeFiles/osgdb_net.dir/sockinet.o /usr/bin/g++ -O3 -march=pentiumpro -Dosgdb_net_EXPORTS -fPIC -I/usr/local/src/OpenSceneGraph/include -I/usr/local/include -o src/osgPlugins/net/CMakeFiles/osgdb_net.dir/sockinet.o -c /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp: In member function `sockinetaddr sockinetbuf::localaddr() const': /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:169: error: invalid conversion from `int*' to `socklen_t*' /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:169: error: initializing argument 3 of `int getsockname(int, sockaddr*, socklen_t*)' /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp: In member function `sockinetaddr sockinetbuf::peeraddr() const': /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:192: error: invalid conversion from `int*' to `socklen_t*' /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:192: error: initializing argument 3 of `int getpeername(int, sockaddr*, socklen_t*)' gmake[2]: *** [src/osgPlugins/net/CMakeFiles/osgdb_net.dir/sockinet.o] Fehler 1 gmake[2]: Leaving directory `/usr/local/src/OpenSceneGraph' Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ??: A simple question from an learner.
Hi Bingli,
I suspect you've got pure CLR support (/clr:pure) selected in your project
configuration, which tells the compiler you're only using managed code. You
need to have standard CLR support (/clr) selected to compile against the native
code of OSG. The setting is in the General section of your project's
Configuration Properties.
-Mike
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ijustfu
Sent: Thursday, August 02, 2007 8:57 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] ??: A simple question from an learner.
Dear Mike,
Thanks for you help. There are so many warnings and errors. Following are
some statements:
1-- Build started: Project: VGEForPRDAirPollution, Configuration: Debug
Win32 --
1Compiling...
1VGEForPRDAirPollution.cpp
1C:\OpenSceneGraph2.0\OpenSceneGraph\include\OpenThreads/Mutex(40) : warning
C4272: 'OpenThreads::Mutex::Mutex' : is marked __declspec(dllimport); must
specify native calling convention when importing a function.
OpenThreads::Mutex::`vftable'' : per-appdomain symbol should not be marked with
__declspec(dllimport)
1C:\OpenSceneGraph2.0\OpenSceneGraph\include\osg/Referenced(64) : warning
C4272: 'osg::Referenced::ref' : is marked
..
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A0C)
public: void __clrcall osg::Referenced::ref(void)const ([EMAIL
PROTECTED]@osg@@$$FQBMXXZ) referenced in function public: __clrcall
osg::ref_ptrclass osg::Referenced::ref_ptrclass osg::Referenced(class
osg::ref_ptrclass osg::Referenced const ) ([EMAIL
PROTECTED]@osg@@@osg@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A0D)
public: void __clrcall osg::Referenced::unref(void)const ([EMAIL
PROTECTED]@osg@@$$FQBMXXZ) referenced in function public: __clrcall
osg::ref_ptrclass osg::Referenced::~ref_ptrclass osg::Referenced(void)
([EMAIL PROTECTED]@osg@@@osg@@[EMAIL PROTECTED])
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A11)
public: __clrcall osg::CopyOp::CopyOp(unsigned int) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]@Z) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(class osg::RefMatrixd const ) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A12)
public: virtual __clrcall osg::CopyOp::~CopyOp(void) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(class osg::RefMatrixd const ) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A13)
public: __clrcall osg::Object::Object(void) ([EMAIL PROTECTED]@@[EMAIL
PROTECTED]) referenced in function public: __clrcall
osg::StateAttribute::Callback::Callback(void) ([EMAIL PROTECTED]@osg@@[EMAIL
PROTECTED])
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A14)
public: __clrcall osg::Object::Object(bool) ([EMAIL PROTECTED]@@[EMAIL
PROTECTED]@Z) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(void) ([EMAIL PROTECTED]@@[EMAIL PROTECTED])
..
1Build log was saved at
file://d:\VGEForPRDAirPollution\TestNet\VGEForPRDAirPollution\VGEForPRDAirPollution\Debug\BuildLog.htm
1VGEForPRDAirPollution - 1227 error(s), 4507 warning(s)
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
Thanks and regards
Bingli
The Institute of Space and Earth Information Science,
The Chinese university of Hong Kong, Shatin, N.T., Hong Kong, P.R.China
-邮件原件-
发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 代表 Mike Wittman
发送时间: 2007年8月2日 22:23
收件人: osg-users@lists.openscenegraph.org
主题: Re: [osg-users] A simple question from an learner.
OSG can definitely be used with WinForms. It sounds like you're running
into some project configuration issue though. If you can post your
error messages we might be able to provide better help.
-Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of ijustfu
Sent: Thursday, August 02, 2007 4:25 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] A simple question from an learner.
Dear Robert.
I build a simple OSG program with visual studio2005.net. I use c++
language , and select window forms application, then get the
following
codes:
#include stdafx.h
#include Form1.h
#include osgViewer/Viewer
#include osgDB/ReadFile
using namespace VGEForPRDAirPollution;
[STAThreadAttribute]
int main(arraySystem::String ^ ^args)
{
// Enabling Windows XP visual effects before any controls are
created
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
// Create the main window and run it
Application::Run(gcnew Form1());
osgViewer::Viewer viewer;
Re: [osg-users] compiling examples
Hi again, Robert! Yes, I know it's a focus problem, just can't figure out what. There's no problem when using FLTK, GLUT or SDL. /Peter On 2007-08-03 (Fri) 13:59, Robert Osfield wrote: Hi Peter, On 8/3/07, Peter Gebauer [EMAIL PROTECTED] wrote: The mouse is working, the keyboard does not. To make the keyboard work again I have to click on the border of a window. This is just a focus issue, its not that keyboard isn't working. Might be the WM, although, only OSG apps hit this problem. Have you tried examples like osgviewerFLTK, osgviewerQT to see if they have the same problem. 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
[osg-users] Shader Problems.
Hi, I have a GLSL code using the Shader model 3.0 which works fine when Iam linking and running with a simple OpenGL program. But when i try to link the vertex and the pixel shader in a OSG program, the code does not work . Iam just changing the osgparametric example with my shader codes and running it. It does not seem to work fine . What could be the problems ? I have installed a new NVIDIA driver after configuring and compiling the OSG codebase. WIll that affect ? regards. Amal. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
HI Zullizum, Could you break the various problems you've seen out into separate emails send to osg-users so we can work through them one at a time, and if there are bugs resolve them before 2.2. Robert. On 8/3/07, Zulizman Berdu [EMAIL PROTECTED] wrote: Hi, Mine also might have the same problem. I'm using terrapage for terrain in my application and it works fine in OSG 1.2. When I switch to OSG 2.0 and OSG 2.1.3 the terrain start flickering. The code to avoid the auto calculate for near/far plane clipping seems not function anymore. The following are my code snippet, The code for OSG 1.2 : m_Viewer.getCullSettings().setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); The code for OSG 2.0 : m_Camera = m_Viewer.getCamera(); m_Camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); Is there anything that i miss here ? Hope this can be resolved before ver 2.2 coming out :) Thanks, -Zulizman- ___ 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] View/Projection/ModelView matrix not applied?
Hi again... Two things of which the first is of higher priority... 1. To make the ModelView matrix match the osg definition (z-up) how would you recommend that I calculate the modelview assuming that only the Camera is known in a preDrawCallback, just so that I don't make any assumptions that can later be changed in some other part of the system? I can get the ViewMatrix, I can also get the MatrixList (of all matrices above the camera in the scenegraph), but to match osg and to make it as flexible as the rest of osg, how would do this? 2. Regarding GraphicsContext, assume that I do need access to a graphicsContext in a PreRender, how can I take control of that Context avoiding any race condition? Now, Im not sure where I get the hang, but it does have something to do with the fact that Im accessing OpenGL when I should not... Eventhough, when I get into the PreRender callback the Context is active. so a simple makeCurrent() would not work. On 8/2/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Anders, On 8/2/07, Anders Backman [EMAIL PROTECTED] wrote: Now I stumbled on a few things. 1. I use to have a Producer::CameraCallback attached to the camera that I hooked up as a preDrawCallback. In that callback, the OpenGL Projection, ModelView and View matrix were all available through OpenGL calls. Now with osg::Camera using the same mechanism, the call: glGetDoublev(GL_MODELVIEW_MATRIX, m_modelview_matrix.ptr()); Returns an identity matrix. That is the OpenGL state is not yet available in the callback. Im guessing this is applied later on, perhaps in the renderbin? The OSG doesn't apply any matrices till it needs to, and leaves the setting of the modelview matrix till is starts rendering the leaves on the render graph - so this is after the pre draw callback of a camera. In the case of Camera pre DrawCallback the actual camera itself is passed into the callback functor so you should be able to use this directly. Also as a general guide try to avoid doing glGet's in an OpenGL application as this can stall the graphics pipineline. As the callback is not a Visitor (!) I cant really use computeLocalToWorldMatrix() to get the modelmatrix to concatenate this into the ModelView either... So I can easily get the Projection and the View Matrix, but not the ModelMatrix in the preDrawCallback(). Any suggestions? Im guessing the reason for this redesign is the new threading models, which is my next question... Noting setting the modelview matrix until needed is something that OSG has done since its earliest days. The fact that you glGet code worked is merely down to Producer setting the matrices, and the way the OSG works these settings were ignored anyway. 2. Im doing Haptic rendering (force rendering using a Phantom) and for this I'm using OpenHaptics which is sort of tapping into OpenGL for accessing rendered primitives for extracting what to render haptically (force rendering). This makes it sensitive to having OpenGL Contexts generated in different threads than the Context for the haptic devices... With the new threading models only two works as I designed OpenHaptics right now: OK: --CullDrawThreadPerContext OK: --SingleThreaded Hangs: --CullThreadPerCameraDrawThreadPerContext Hangs: --DrawThreadPerContext The questions is really, in what thread are the OpenGL Contexts created for the various threading models? It looks like its done in the main thread for the first two? The contexts are generated by the main application thread normally, its the makeCurrent when brings the context into the control of a particular GraphicsThread. The real difference with CullThreadPerCameraDrawTheadPerContext and DrawThreadPerContext is not related to the GraphicsThread, rather its that the cull is done in the main or separate threads, and extra syncronization barriers exists to marshal these threads to make sure no data gets overwritten when its not safe. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid conversion from `int*' to `socklen_t*'
Martin On Friday 03 August 2007 14:26, Martin Spott wrote: Hi, just wanted to let you know that I'm getting a compile error with current SVN on FreeBSD: [ 53%] Building CXX object src/osgPlugins/net/CMakeFiles/osgdb_net.dir/sockinet.o /usr/bin/g++ -O3 -march=pentiumpro -Dosgdb_net_EXPORTS -fPIC -I/usr/local/src/OpenSceneGraph/include -I/usr/local/include -o src/osgPlugins/net/CMakeFiles/osgdb_net.dir/sockinet.o -c /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp: In member function `sockinetaddr sockinetbuf::localaddr() const': /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:169: error: invalid conversion from `int*' to `socklen_t*' /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:169: error: initializing argument 3 of `int getsockname(int, sockaddr*, socklen_t*)' /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp: In member function `sockinetaddr sockinetbuf::peeraddr() const': /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:192: error: invalid conversion from `int*' to `socklen_t*' /usr/local/src/OpenSceneGraph/src/osgPlugins/net/sockinet.cpp:192: error: initializing argument 3 of `int getpeername(int, sockaddr*, socklen_t*)' gmake[2]: *** [src/osgPlugins/net/CMakeFiles/osgdb_net.dir/sockinet.o] Fehler 1 gmake[2]: Leaving directory `/usr/local/src/OpenSceneGraph' Cheers, Martin. I will care for that not before monday ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
We'll its RenderStage that SceneView uses to clear, and its ClearNode that just adjusts the default settings of the clear that RenderStage does and done from with the cull traversal. In effect it'll be exactly the same code doing the clear, the only difference is that how the values are set - one from the defaults provided by SceneView, and one from the scene graph. Ah! Thanks. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac Pro multiple display problems..
Hi Guys, I have just been doing some testing on a 2.66 Ghz quad Mac Pro and i'm finding that it loads the first frame on only one display and then hangs.. This however this does not happen when only one display is connected. Has anyone else come across this issue? Kind Regards, Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] compiling examples
Ok, it's odd. Must be IceWM that is not behaving correctly. Thanks for testing! /Peter On 2007-08-03 (Fri) 17:24, Robert Osfield wrote: Hi Peter, On 8/3/07, Peter Gebauer [EMAIL PROTECTED] wrote: Yes, I know it's a focus problem, just can't figure out what. There's no problem when using FLTK, GLUT or SDL. I have just tried osgviewer in various ways and focus always returns to the console that I fired up osgviewer from, doesn't matter if I open up full screen, or toggle back to window, or run across two separate screens. 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] Preliminary DISPLAY support checked into SVN
Hiya! Yes, the 2.0 release sources, worked nicely. I'll just install mesa and then reinstall the nvidia drivers, it used to be a good workaround before. /Peter On 2007-08-03 (Fri) 18:49, Robert Osfield wrote: Hi Peter, Nothing changed w.r.t GLU with the latest changes, in fact the OSG has always required GLU. Have you compiled the OSG before? Which versions? Robert. On 8/3/07, Peter Gebauer [EMAIL PROTECTED] wrote: I tried building the latest SVN stuff and the build system complains about a missing GL/glu.h. The only Debian package providing glu.h is the libglu-mesa-dev package which requires mesa to be installed. I've had problems with Mesa before, it overwrites my nvidia libraries and I rather have hardware OpenGL than software OpenGL. Any suggestions on how to get hold of the GLU stuff without having to install Mesa? /Peter On 2007-08-03 (Fri) 16:50, Robert Osfield wrote: Hi All, I have now added preliminary support into osgViewer::View::setUpView*() methods for reading the DISPLAY variable in order to initialize the hostName, displayNum and screenNum. As helper functions there are now a ScreenIdentifier::readDISPLAY() and ScreenIdentifier::setScreenIdentifier(std::string) methods. Have a browse throught src/osgViewer/View.cpp to how they are used. Could those requesting this support check out the latest in SVN and test it. 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 ___ 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
