Re: [osg-users] 'loosing' textures?
Hi, I know, it sounds that I'm doing strange things. But the opposite is true. Well, I am stripping everything and see where it is. Eventually it will be something small stupid, as always ;-) Thanks for your time! Raymond Zach Deedler wrote: Well it does sound like you are doing some pretty crazy things, but I don't know why they'd cause textures to disappear. Are there any other odd things that you are doing? I had similar texture problems when using ReplicantBody models in my scenes. Are you loading any crazy file formats? Has anything else changed since you have upgraded to OSG 2.0? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raymond de Vries Sent: Wednesday, September 19, 2007 10:09 AM To: OpenSceneGraph Users Subject: Re: [osg-users] 'loosing' textures? Hi Zach, It sounds like your state sets are not being managed properly. Are you doing any opengl state changes outside of OSG? If so, try removing them and see what happens. You mean that I do direct OpenGL calls, mixed with OSG, right? Nope, I am not doing that. Yes, I can imagine that that's tricky to do. Everything is single threaded, single rendering context. thnx Raymond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raymond de Vries Sent: Wednesday, September 19, 2007 9:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] 'loosing' textures? Hi, Glut is effectively only used for creating the rendering context at the moment. From there on I use this rendering context in the .net controls. Apart from that the usage is for historical reasons. I understand it sounds strange but the glut functionality that I use right now is very limited. And when I do use it, it is used as a kind of debugging window instead of het .net control. Rewriting the whole thing is not an option right now, and I don't need the full osgviewer functionality. I will try to use osg::GraphicsContext so that I can take a step in the right direction. Ok, I guess this GraphicsContext is only to be used as part of the osgviewer, so this is not an option for me right now. More info, maybe this rings a bell: the textures only disappear after a few frames, when I use multiple windows (.net controls). Conceptually, I don't have a clue what's going on, all the windows have a view on the same scenegraph, using their own sceneview. thanks a lot for your time! Raymond best regards Raymond Robert Osfield wrote: Hi Raymond, I am perplexed why you'd want to use GLUT for any multiple window work. Why not just try the native windowing support. Robert. On 9/19/07, Raymond de Vries [EMAIL PROTECTED] wrote: Hi Robert, Sure, I did not provide information for the complete solution. At this moment I was hoping that someone else was triggered by this and he or she did some extensive research on this. Appearantly I did trigger ;-) I will describe my situation here in detail: * osg 2.0.0 on Windows XP SP2, 1 monitor * 1 main freeglut window = 1 rendering context. Shared contexts is enabled in freeglut since I intend to use only 1 rendering context in order to preserve resources. This window exists during the existence of the program and I hide it just after creation. I don't draw this window. * Multiple other windows, mixed glut and .net controls. In the .net control I create a so-called NativeWindow and get the current context. This way I get the context from my main window. These other windows and .net controls are created and deleted at runtime * Each 'other' window (ie not the main window) has its own sceneview * 1 scenegraph, assigned to each sceneview (setSceneData(node)) * Each 'other' window has its own camera transformation Models are then loaded from file and added to the scenegraph. The effect that I see right now is that it seems that I am using multiple rendering contexts and that the texture of some parts of the models don't get uploaded to a particular rendering context. This is not the case however, I checked the contexts being made active and they are all the same. It looks like the models are only smooth shaded. Any clue? Is it possible that I need to set a specific rendering context to a sceneview? Thanks a lot (again) Raymond Robert Osfield wrote: Hi Raymond, If its not clear to you then with this small amount of information is going to be absolutely beyond comprehension for others... First up what type of application/viewer code do you have? Single window, multiple cameras? What platform? Does it just happen with certain types of hardware?
[osg-users] BUG?: mouse coordinate changes after window move
Hi, Im using a recent svn version (a few weeks old) of osg under windows (both VISTA and XP). I have noticed that if I: 1. Start osgviewer cow.osg 2. press 'f' to get into windowed mode 3. if I now move the whole window and release it, I can see that the view/projection changes slightly. Another illustration: A small app that output the coordinates of a mouse click in the window 1. start that application and make it windowed 'f' 2. click on a specific point in the scene, ea.getX(), ea.getY() reports: (132, 171) 3. move the window a little bit, click in the same point in the scene ea.getX(), ea.getY() reports: (139 ,121) 4. move the window again to any position on the screen, and now ea.getX(), ea.getY() reports consistent results. So to me it seems that the first move-window messes (or corrects) the view/projection. Now I tried this on a ubuntu machine, but on that one the windowed mode did not work at all. Pressing 'f' results in a brief flicker of the window, and I can for a fraction of a second see a smaller cow, no window decoration in the lower left corner of the display. Anyone else noticed these two problems? -- 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
[osg-users] fatal error LNK1120: 3 unresolved externals
get 3 linker errros after a migration from osg.1 to osg.2, any clue of where the problem can be ? visual error LNK2001: unresolved external symbol public: virtual void __thiscall osgText::Text::drawImplementation(class osg::State )const ([EMAIL PROTECTED]@osgText@@[EMAIL PROTECTED]@@@Z) visual error LNK2001: unresolved external symbol public: virtual void __thiscall osg::Drawable::compileGLObjects(class osg::State )const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) visual error LNK2001: unresolved external symbol public: virtual void __thiscall osg::Geometry::drawImplementation(class osg::State )const ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FLT(CTS)
Hi : That OSG support , DB builded with CTS??? Thanks Ariel This message (including any attachments) issued by RAFAEL-ARMAMENT DEVELOPMENT AUTHORITY LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:[EMAIL PROTECTED] and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::Simplifier explained
Hi Matt, It uses a edge collapse technique with an error metric to determine which edges are collapsed. You can tune the error metric to make it more conservative/less conservative. Robert. On 9/19/07, Matt Franklin [EMAIL PROTECTED] wrote: Could someone please explain what conditions are needed for the Simplifier to do its job? When I use it on a range of models I can see that some simplification happens on the curved surfaces but there always seems to be a limit to how much simplification takes place. For example I have a model of a bridge with a nice curved arch on the underside. When I simplify the model some of the curved surface is simplified away. However, I can never simplify it further, no matter what settings I use. I would niavely expect that the arch could be simplified to a simple triangular shape but this never happens. Thanks in advance Matt ___ 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::CameraNode doesn't render the scene behind the osgProducer::Camera
Hi, On 9/19/07, zarrandreas [EMAIL PROTECTED] wrote: Thanks for the tip, but I can't use osgViewer, because I use custom framework and this framework use osgProducer::Viewer. osgProducer::Viewer apps can typically be ported to osgViewer::Viewer in minutes, they have lots of similarities. The Prerender Example in osg framework use also osgProducer::Camera and osg::CameraNode to render the scene to the texture. Maybe the problem is in the using of the screen aligned quad (= I align the quad to the screen in the vertex shader). When you say osg framework what do you mean? There is no osg framework unless its on your side. Do you mean the osg examples that came with 1.2? As a general note render to texture setup can normally be done totally independently from the viewer, code can be ported across different viewers and should still work. The viewer also shouldn't make any difference. If you have problem with RTT then its likely that its a pure scene graph set up issue. As for the problem with your set up one really can't say what might be up with so few details of how you've set up the scene graph. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Install Location for osgwrappers_*.dll
Hi Jason, On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: Currently, the osgwrappers_*.dll files are installed in the bin\osgPlugins-2.1.11 folder instead of in just bin. Is this correct behavior? It seems to me like they should have the same versioning scheme the rest of OSG has now and be placed in the bin folder. Wrappers are plugins, they are dynamically loaded on demand rather than linked to explictly like a conventional library. So yes there should go in the plugins folder as since the plugin folder is version there should be no need to version the wrappers. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 'loosing' textures?
On 9/20/07, Raymond de Vries [EMAIL PROTECTED] wrote: I know, it sounds that I'm doing strange things. But the opposite is true. Well, I am stripping everything and see where it is. Eventually it will be something small stupid, as always ;-) I'm afraid your set up is novel enough that others will only be clutch at straws at what the issue. One of the reasons for the new osgViewer library is to pull a whole range of disparate usage models together under one family of classes to avoid the issues of users rolling a lot of functionality on their own as its almost impossible to remotely support such bespoke configurations. The OSG does support multiple graphics context just fine, but your have to be careful about management of threads, contextIDs. In the case of 2.x it is more robust than ever in multi-threaded multi-context role, and with osgViewer the vast majority of the complexity of supporting these configurations is wrapped for you. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG?: mouse coordinate changes after window move
Hi Anders, On 9/20/07, Anders Backman [EMAIL PROTECTED] wrote: Im using a recent svn version (a few weeks old) of osg under windows (both VISTA and XP). I have noticed that if I: 1. Start osgviewer cow.osg 2. press 'f' to get into windowed mode 3. if I now move the whole window and release it, I can see that the view/projection changes slightly. Another illustration: A small app that output the coordinates of a mouse click in the window 1. start that application and make it windowed 'f' 2. click on a specific point in the scene, ea.getX (), ea.getY() reports: (132, 171) 3. move the window a little bit, click in the same point in the scene ea.getX(), ea.getY() reports: (139 ,121) 4. move the window again to any position on the screen, and now ea.getX (), ea.getY() reports consistent results. So to me it seems that the first move-window messes (or corrects) the view/projection. This sounds like a GraphicsWindowWin32 bug in some form. Now I tried this on a ubuntu machine, but on that one the windowed mode did not work at all. Pressing 'f' results in a brief flicker of the window, and I can for a fraction of a second see a smaller cow, no window decoration in the lower left corner of the display. I use Kubuntu and Suse here and both work fine for me. Both are KDE though. From the sound of it it sounds like the window manager is screwing up when no decoration is appearing when it goes into windowing mode. Could you try : osgviewer --window 100 100 500 500 cow.osg Does the mouse and window decoration work OK? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to get the data of DEPTH BUFFER
Hi, I want to get the data of depth buffer from osg::Camera,how to do. Thanks very much.Hope your quickly reply.hehe___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLT(CTS)
HI Ariel, That's three acronyms in a sentence of seven words. My guess is that the vast majority of the OSG community haven't got a clue what you asking. Try rephrasing you email with a few more real words and provide more context. Robert. On 9/20/07, HUTTERER ARIEL [EMAIL PROTECTED] wrote: Hi : That OSG support , DB builded with CTS??? Thanks Ariel This message (including any attachments) issued by RAFAEL-ARMAMENT DEVELOPMENT AUTHORITY LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:[EMAIL PROTECTED] and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ 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] Collision detection
That depends what you mean by Collision Detection. The only functionality in this area is, checking for overlapping bounding volumes and ray/scene intersection. If you need to extract intersectionpoints, normals, penetration depth between any two given geometries/meshes, then osg is not what you need. Look at Bullet, ODE, OPCODE, GIMPACT which are examples of libraries doing just that (and more). /Anders On 9/19/07, Zach Deedler [EMAIL PROTECTED] wrote: Hello, Has anybody used OSG to do collision detection? Is it efficient for doing it? I'm not looking for details; just if it works well or not. Thanks. ___ 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] How to get the data of DEPTH BUFFER
On 9/20/07, 许丹阳 [EMAIL PROTECTED] wrote: I want to get the data of depth buffer from osg::Camera,how to do. Thanks very much.Hope your quickly reply.hehe It all depends on what you want to do with it... please provide a bit more context. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph with Qt multiple windowing problem
Hi David and Robert, Thanks for the looking about my problem. I use Windows XP with AMD Athlon (tm) 64 Processor 2008+ 1.80 Ghz, OSG_THREADING = SingleThreaded OSG_OPTIMIZER = DEFAULT.. About the multiple windowing problem, the Viewer/Composite It's a good idea but in this way I must display the differents sceneGrpah in the same window. But I want to have differents sceneGraph in differents windows. According you Robert, It seems that for the moment It is not possible to have what I want. Do you think that It can be possible in a next version of osg. It is a real need for the Osg comunity? I don't really know If my request it's interesting for the others people. About your approach to inherit the native windowing into a GraphicsWindowWin32/Carbon/X11 in a way that adapts a Qt window via its native windowing implementatio can you give me more precision and direction to help me If I want to develop myself to try to correct this probelm. Others are welcome too, to find a solution :-) Many thanks and Best regards Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph with Qt multiple windowing problem
Hi Arnaud, Viewer and CompositeViewer can both share scenes between them. What you are trying to do is supported, and already works well see the osgcompsiteviewer. The complication in your case is that QT is quite up to scratch for this type of work makes it more awkward - its OpenGL support isn't quite sophisticated enough to do things the most straight forward way. There are ways around this as I said in my previous email. Robert. On 9/20/07, arnaud houegbelo [EMAIL PROTECTED] wrote: Hi David and Robert, Thanks for the looking about my problem. I use Windows XP with AMD Athlon (tm) 64 Processor 2008+ 1.80 Ghz, OSG_THREADING = SingleThreaded OSG_OPTIMIZER = DEFAULT.. About the multiple windowing problem, the Viewer/Composite It's a good idea but in this way I must display the differents sceneGrpah in the same window. But I want to have differents sceneGraph in differents windows. According you Robert, It seems that for the moment It is not possible to have what I want. Do you think that It can be possible in a next version of osg. It is a real need for the Osg comunity? I don't really know If my request it's interesting for the others people. About your approach to inherit the native windowing into a GraphicsWindowWin32/Carbon/X11 in a way that adapts a Qt window via its native windowing implementatio can you give me more precision and direction to help me If I want to develop myself to try to correct this probelm. Others are welcome too, to find a solution :-) Many thanks and Best regards Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 ___ 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] Accessing the Depth Buffer for Stereo Output.
Hi all, I'm trying to use OSG with the Phillips 3D WOW auto-stereo display which uses an unconventional stereo format. Basically you have to split the image vertically into two, on the left is the contents of the frame buffer and on the right you send a greyscale image of the Z buffer. What I would like to know is, what is the fastest way to get access to the Z buffer within OSG so that it can be used in such a way? Thanks in advance, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
Hi, Robert,
The following is sufficient (basically what you said):
#include OpenThreads/Thread
class MyThread : public OpenThreads::Thread {
public:
void run(void) { }
};
int main(int argc, char* argv[]) {
{
MyThread thread;
thread.startThread();
}
while(1) ;
return 0;
}
You need the while(1) ; to prevent the process from dying and cleaning
up the thread before it wrecks. This alone wouldn't reproduce the bug
because the interleaving doesn't happen (it's a very short window in
which it can happen). To force the bug, I added ::usleep(100) at
the beginning of ThreadPrivateActions::StartThread().
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
So, I just realized that the OSG folks are not synonymous with the
OpenThreads folks. ^_^ Sorry for dropping this on the wrong list
then.
Well OpenThreads list is a flat line, almost all (99.9%) OpenThreads
activity and development is done by members of the OpenSceneGraph
community. So this is probably the best place to raise issues like
this. Responsibility for maintaining OpenThreads has also fallen on
my shoulders as it effectively became an orphaned project when the
original project lead got sucked into non coding management.
In that light, it may not even be considered a bug in OT,
since, theoretically, it might be unfair to call the Thread destructor
while the thread is running (even though I'm pretty sure they intended
isRunning() to work as we'd expect).
Well this type of usage is kinda abusing the Thread class, but I'd
still say this way a bug.
It should be possible to add a workaround in the following way:
1. Before starting the thread, set a flag to indicate that the thread
is starting up.
2. Have the thread's run() routine unset this flag.
Before deleting the Thread, make sure that both the starting up flag
and the isRunning flag are false. One of these will have to be true
if the thread has not reached the run() method yet, or has not
completely exited from run() -- thus avoiding the problem.
I'll have ponder in this issue, I'm more inclined to use a mutex in
some way that just a straight flag.
My question: does somebody want me to implement this workaround and
submit it to you? Alternatively, I can just point out the break to
the OpenThreads people and we can wait for a patch...
It's best to just roll your sleeves up and get stuck in. First up we
need a test that can reliably reproduce the error. Would the
following code block do the trick?
{
OpenThreads::Thread thread;
thread.startThread();
}
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] OpenThreads threading bug on creation/deletion (leads to crashes)
Ah - just double-checked. It'll crash just fine without adding the
usleep() to OpenThreads; I had my builds mixed up.
AC
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Hi, Robert,
The following is sufficient (basically what you said):
#include OpenThreads/Thread
class MyThread : public OpenThreads::Thread {
public:
void run(void) { }
};
int main(int argc, char* argv[]) {
{
MyThread thread;
thread.startThread();
}
while(1) ;
return 0;
}
You need the while(1) ; to prevent the process from dying and cleaning
up the thread before it wrecks. This alone wouldn't reproduce the bug
because the interleaving doesn't happen (it's a very short window in
which it can happen). To force the bug, I added ::usleep(100) at
the beginning of ThreadPrivateActions::StartThread().
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
So, I just realized that the OSG folks are not synonymous with the
OpenThreads folks. ^_^ Sorry for dropping this on the wrong list
then.
Well OpenThreads list is a flat line, almost all (99.9%) OpenThreads
activity and development is done by members of the OpenSceneGraph
community. So this is probably the best place to raise issues like
this. Responsibility for maintaining OpenThreads has also fallen on
my shoulders as it effectively became an orphaned project when the
original project lead got sucked into non coding management.
In that light, it may not even be considered a bug in OT,
since, theoretically, it might be unfair to call the Thread destructor
while the thread is running (even though I'm pretty sure they intended
isRunning() to work as we'd expect).
Well this type of usage is kinda abusing the Thread class, but I'd
still say this way a bug.
It should be possible to add a workaround in the following way:
1. Before starting the thread, set a flag to indicate that the thread
is starting up.
2. Have the thread's run() routine unset this flag.
Before deleting the Thread, make sure that both the starting up flag
and the isRunning flag are false. One of these will have to be true
if the thread has not reached the run() method yet, or has not
completely exited from run() -- thus avoiding the problem.
I'll have ponder in this issue, I'm more inclined to use a mutex in
some way that just a straight flag.
My question: does somebody want me to implement this workaround and
submit it to you? Alternatively, I can just point out the break to
the OpenThreads people and we can wait for a patch...
It's best to just roll your sleeves up and get stuck in. First up we
need a test that can reliably reproduce the error. Would the
following code block do the trick?
{
OpenThreads::Thread thread;
thread.startThread();
}
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] OpenThreads threading bug on creation/deletion (leads to crashes)
Hi Adam,
Could you send the exact code that you can recreate the issue with.
Robert.
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Ah - just double-checked. It'll crash just fine without adding the
usleep() to OpenThreads; I had my builds mixed up.
AC
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Hi, Robert,
The following is sufficient (basically what you said):
#include OpenThreads/Thread
class MyThread : public OpenThreads::Thread {
public:
void run(void) { }
};
int main(int argc, char* argv[]) {
{
MyThread thread;
thread.startThread();
}
while(1) ;
return 0;
}
You need the while(1) ; to prevent the process from dying and cleaning
up the thread before it wrecks. This alone wouldn't reproduce the bug
because the interleaving doesn't happen (it's a very short window in
which it can happen). To force the bug, I added ::usleep(100) at
the beginning of ThreadPrivateActions::StartThread().
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
So, I just realized that the OSG folks are not synonymous with the
OpenThreads folks. ^_^ Sorry for dropping this on the wrong list
then.
Well OpenThreads list is a flat line, almost all (99.9%) OpenThreads
activity and development is done by members of the OpenSceneGraph
community. So this is probably the best place to raise issues like
this. Responsibility for maintaining OpenThreads has also fallen on
my shoulders as it effectively became an orphaned project when the
original project lead got sucked into non coding management.
In that light, it may not even be considered a bug in OT,
since, theoretically, it might be unfair to call the Thread destructor
while the thread is running (even though I'm pretty sure they intended
isRunning() to work as we'd expect).
Well this type of usage is kinda abusing the Thread class, but I'd
still say this way a bug.
It should be possible to add a workaround in the following way:
1. Before starting the thread, set a flag to indicate that the thread
is starting up.
2. Have the thread's run() routine unset this flag.
Before deleting the Thread, make sure that both the starting up flag
and the isRunning flag are false. One of these will have to be true
if the thread has not reached the run() method yet, or has not
completely exited from run() -- thus avoiding the problem.
I'll have ponder in this issue, I'm more inclined to use a mutex in
some way that just a straight flag.
My question: does somebody want me to implement this workaround and
submit it to you? Alternatively, I can just point out the break to
the OpenThreads people and we can wait for a patch...
It's best to just roll your sleeves up and get stuck in. First up we
need a test that can reliably reproduce the error. Would the
following code block do the trick?
{
OpenThreads::Thread thread;
thread.startThread();
}
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
Re: [osg-users] Accessing the Depth Buffer for Stereo Output.
Hi Kim, Probably the easiest way would be to render the scene using a render to texture Camera and use a texture for the colour buffer and the depth buffer. Then in a second pass as HUD Camera and render the colour texture directly as a quad on the left hand side, then render the depth texture as a grey scale on a left hand quad. The osgdistortion example probably comes closest to doing this type of thing w.r.t RTT Camera and HUD Camera setup. Robert. On 9/20/07, Kim C Bale [EMAIL PROTECTED] wrote: Hi all, I'm trying to use OSG with the Phillips 3D WOW auto-stereo display which uses an unconventional stereo format. Basically you have to split the image vertically into two, on the left is the contents of the frame buffer and on the right you send a greyscale image of the Z buffer. What I would like to know is, what is the fastest way to get access to the Z buffer within OSG so that it can be used in such a way? Thanks in advance, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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] Displaying stats
Hello, just a simple question. How can I use the stats? I have added viewer.addEventHandler( new osgGA::StateSetManipulator( viewer.getCamera()-getOrCreateStateSet() ) ); to my program, but I think this is not enough. I am using the new OSG 2.0. Thx --marcus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying stats
Okay, i have found something what I was looking for. For those who do not know how to add it... #include osgViewer/ViewerEventHandlers ... viewer.addEventHandler( new osgViewer::StatsHandler() ); That is all, but another question. Is there also a possibility to count the triangles in the scene? --marcus Marcus Fritzen wrote: Hello, just a simple question. How can I use the stats? I have added viewer.addEventHandler( new osgGA::StateSetManipulator( viewer.getCamera()-getOrCreateStateSet() ) ); to my program, but I think this is not enough. I am using the new OSG 2.0. Thx --marcus ___ 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] Displaying stats
On 9/20/07, Marcus Fritzen [EMAIL PROTECTED] wrote: Okay, i have found something what I was looking for. For those who do not know how to add it... #include osgViewer/ViewerEventHandlers ... viewer.addEventHandler( new osgViewer::StatsHandler() ); That is all, but another question. Is there also a possibility to count the triangles in the scene? StatsHandler doesn't compute the vertex/polygon counts right now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Install Location for osgwrappers_*.dll
Robert, That makes sense to me, just wanted some clarification! I'm not that familiar with osgIntrospection, I just noticed that the osgwrapper* files were being built in the bin folder, but then copied to the plugins directory. Also, the osgDotNet wrapper generator couldn't find the osgwrappers dlls unless I stuck them in the bin directory instead of the bin\osgPlugins directory. I'll try to investigate further this evening and try to get Mike some help. I need to get more familiar with osgIntrospection anyway:) Thanks! Jason On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Jason, On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: Currently, the osgwrappers_*.dll files are installed in the bin\osgPlugins-2.1.11 folder instead of in just bin. Is this correct behavior? It seems to me like they should have the same versioning scheme the rest of OSG has now and be placed in the bin folder. Wrappers are plugins, they are dynamically loaded on demand rather than linked to explictly like a conventional library. So yes there should go in the plugins folder as since the plugin folder is version there should be no need to version the wrappers. 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] Displaying stats
Hi Marcus just a simple question. How can I use the stats? Do you want use the state os stats ? state if toggleUseTexture (key t), ToggleWireFrame (key w), ToggleLight (key l), ... stats is a grap draw on the top of the scene and displaying performance of the application (key s) I have added viewer.addEventHandler( new osgGA::StateSetManipulator( viewer.getCamera()-getOrCreateStateSet() ) ); to my program, but I think this is not enough. I am using the new OSG 2.0. osg-users correct me if I am wrong but just add Handler to the view is require. look the osgviewer example David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Install Location for osgwrappers_*.dll
On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: That makes sense to me, just wanted some clarification! I'm not that familiar with osgIntrospection, I just noticed that the osgwrapper* files were being built in the bin folder, but then copied to the plugins directory. Also, the osgDotNet wrapper generator couldn't find the osgwrappers dlls unless I stuck them in the bin directory instead of the bin\osgPlugins directory. Ideally they would be built directly into the plugins directory. I'll have to defer to Luigi Calori on how the Windows build works though - I'm only familiar with it from 10,000 feet. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] loosing some textures when moving window to 2nd screen
Hi,
We are using wxwidgets with multiple windows on a WindowsXP machine. A
problem that we have come across is that (when running with 1 graphics
card but two screens) the textures sometimes disappears on some of the
windows when moved from one screen to the next (see attached images). If
the window is moved on the same screen everything is fine. I have
attached (without the 3D models) sample code (a modified version of the
osgviewerWX example) that will reproduce the problem on my machine. Any
thoughts?
/Christer
inline: Moved to 2nd screen.jpginline: Before moved.jpg// For compilers that support precompilation, includes wx.h.
#include wx/wxprec.h
#ifdef __BORLANDC__
#pragma hdrstop
#endif
#ifndef WX_PRECOMP
#include wx/wx.h
#endif
#include osgviewerWX.h
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include osg/MatrixTransform
#include wx/image.h
#include wx/menu.h
#include wx/statline.h
#include wx/listctrl.h
// `Main program' equivalent, creating windows and returning main app frame
bool wxOsgApp::OnInit()
{
// Create the main frame window
MainFrame *frame1 = new MainFrame(NULL, wxT(wxWidgets OSG Sample),
wxDefaultPosition, wxDefaultSize);
wxFrame* frame2 = new wxFrame(frame1, wxID_ANY, Extra window 2,
wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE);
// create osg canvas
//- initialize
int width = 800;
int height = 600;
GraphicsWindowWX* gw1 = new GraphicsWindowWX(frame1, wxID_ANY,
wxDefaultPosition,
wxSize(width, height),
wxSUNKEN_BORDER);
GraphicsWindowWX* gw2 = new GraphicsWindowWX(frame2, wxID_ANY,
wxDefaultPosition,
wxSize(width, height),
wxSUNKEN_BORDER);
osgViewer::CompositeViewer *viewer = new osgViewer::CompositeViewer;
viewer-setThreadingModel(osgViewer::CompositeViewer::ThreadingModel::ThreadPerCamera);
osgViewer::View* view1 = new osgViewer::View;
osgViewer::View* view2 = new osgViewer::View;
// load the scene.
osg::Node* loadedModel1 =
osgDB::readNodeFile(D:/MySVN/EWSim/data/FoiLoggo/loggo.osg);
if (!loadedModel1)
{
return false;
}
osgDB::Registry::instance()-getDataFilePathList().push_back(D:/MySVN/EWSim/data/EngelHolmMap);
osg::Node* loadedModel2 = osgDB::readNodeFile(aaaLOD_TOP.osg);
if (!loadedModel2)
{
return false;
}
osgDB::Registry::instance()-getDataFilePathList().pop_back();
view1-getCamera()-setGraphicsContext(gw1);
view1-getCamera()-setViewport(0,0,width,height);
view1-addEventHandler(new osgViewer::StatsHandler);
view1-setSceneData(loadedModel1);
view1-setCameraManipulator(new osgGA::TrackballManipulator);
viewer-addView(view1);
osg::Camera* pCamera = new osg::Camera;
view2-setCamera(pCamera);
view2-getCamera()-setGraphicsContext(gw2);
view2-getCamera()-setViewport(0,0,width,height);
view2-addEventHandler(new osgViewer::StatsHandler);
view2-setSceneData(loadedModel2);
osg::Viewport* pViewport2 = view2-getCamera()-getViewport();
double dAspectRatio = pViewport2-aspectRatio();
double clippingNearDistance = 2.0;
double clippingFarDistance = 30.0;
view2-getCamera()-setProjectionMatrixAsOrtho(
-5,
5,
-37500,
37500,
2,
30
);
//osg::Vec3 vecCameraPos = loadedModel2-getBound().center();
osg::Vec3 vecCameraPos = osg::Vec3(18748, -12503, 34512);
osg::Vec3 vecLookAtPos = vecCameraPos;
vecCameraPos.z() += 35000.0;
view2-getCamera()-setViewMatrixAsLookAt(
vecCameraPos,
vecLookAtPos,
osg::Vec3(
0,
1,
0
)
);
viewer-addView(view2);
frame1-SetViewer(viewer);
/* Show the frame */
frame1-Show(true);
frame2-Show(true);
return true;
}
IMPLEMENT_APP(wxOsgApp)
BEGIN_EVENT_TABLE(MainFrame, wxFrame)
EVT_IDLE(MainFrame::OnIdle)
END_EVENT_TABLE()
/* My frame constructor */
MainFrame::MainFrame(wxFrame *frame, const wxString title, const wxPoint pos,
const wxSize size, long style)
: wxFrame(frame, wxID_ANY, title, pos, size, style)
{
}
void MainFrame::SetViewer(osgViewer::CompositeViewer *viewer)
{
_viewer = viewer;
}
void MainFrame::OnIdle(wxIdleEvent event)
{
_viewer-frame();
event.RequestMore();
}
BEGIN_EVENT_TABLE(GraphicsWindowWX, wxGLCanvas)
EVT_SIZE(GraphicsWindowWX::OnSize)
EVT_PAINT(GraphicsWindowWX::OnPaint)
EVT_ERASE_BACKGROUND(GraphicsWindowWX::OnEraseBackground)
EVT_KEY_DOWN
Re: [osg-users] Displaying stats
Thank you both. Like Robert said, atm there is no automatically count of the triangles in the StatsHandler. I am not sure what you mean with the display in the stats graph, David? I have taken a look at the osgViewer examples, but they all use the StatsHandler, which I am using right now, too. David Callu wrote: lol synchronized That is all, but another question. Is there also a possibility to count the triangles in the scene? this is display in the Stats graph David ___ 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] loosing some textures when moving window to 2nd screen
HI Christer,
Are you working under Windows? NVidia hardware?
There has been various threads on osg-users over the last few months
about moving windows across screens and then problems ensuing. Please
read through these to get an understanding of the problem and
solutions w.r.t driver settings.
Robert.
On 9/20/07, Christer Wigren [EMAIL PROTECTED] wrote:
Hi,
We are using wxwidgets with multiple windows on a WindowsXP machine. A
problem that we have come across is that (when running with 1 graphics
card but two screens) the textures sometimes disappears on some of the
windows when moved from one screen to the next (see attached images). If
the window is moved on the same screen everything is fine. I have
attached (without the 3D models) sample code (a modified version of the
osgviewerWX example) that will reproduce the problem on my machine. Any
thoughts?
/Christer
// For compilers that support precompilation, includes wx.h.
#include wx/wxprec.h
#ifdef __BORLANDC__
#pragma hdrstop
#endif
#ifndef WX_PRECOMP
#include wx/wx.h
#endif
#include osgviewerWX.h
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include osg/MatrixTransform
#include wx/image.h
#include wx/menu.h
#include wx/statline.h
#include wx/listctrl.h
// `Main program' equivalent, creating windows and returning main app frame
bool wxOsgApp::OnInit()
{
// Create the main frame window
MainFrame *frame1 = new MainFrame(NULL, wxT(wxWidgets OSG Sample),
wxDefaultPosition, wxDefaultSize);
wxFrame* frame2 = new wxFrame(frame1, wxID_ANY, Extra window 2,
wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE);
// create osg canvas
//- initialize
int width = 800;
int height = 600;
GraphicsWindowWX* gw1 = new GraphicsWindowWX(frame1, wxID_ANY,
wxDefaultPosition,
wxSize(width, height),
wxSUNKEN_BORDER);
GraphicsWindowWX* gw2 = new GraphicsWindowWX(frame2, wxID_ANY,
wxDefaultPosition,
wxSize(width, height),
wxSUNKEN_BORDER);
osgViewer::CompositeViewer *viewer = new osgViewer::CompositeViewer;
viewer-setThreadingModel(osgViewer::CompositeViewer::ThreadingModel::ThreadPerCamera);
osgViewer::View* view1 = new osgViewer::View;
osgViewer::View* view2 = new osgViewer::View;
// load the scene.
osg::Node* loadedModel1 =
osgDB::readNodeFile(D:/MySVN/EWSim/data/FoiLoggo/loggo.osg);
if (!loadedModel1)
{
return false;
}
osgDB::Registry::instance()-getDataFilePathList().push_back(D:/MySVN/EWSim/data/EngelHolmMap);
osg::Node* loadedModel2 = osgDB::readNodeFile(aaaLOD_TOP.osg);
if (!loadedModel2)
{
return false;
}
osgDB::Registry::instance()-getDataFilePathList().pop_back();
view1-getCamera()-setGraphicsContext(gw1);
view1-getCamera()-setViewport(0,0,width,height);
view1-addEventHandler(new osgViewer::StatsHandler);
view1-setSceneData(loadedModel1);
view1-setCameraManipulator(new osgGA::TrackballManipulator);
viewer-addView(view1);
osg::Camera* pCamera = new osg::Camera;
view2-setCamera(pCamera);
view2-getCamera()-setGraphicsContext(gw2);
view2-getCamera()-setViewport(0,0,width,height);
view2-addEventHandler(new osgViewer::StatsHandler);
view2-setSceneData(loadedModel2);
osg::Viewport* pViewport2 = view2-getCamera()-getViewport();
double dAspectRatio = pViewport2-aspectRatio();
double clippingNearDistance = 2.0;
double clippingFarDistance = 30.0;
view2-getCamera()-setProjectionMatrixAsOrtho(
-5,
5,
-37500,
37500,
2,
30
);
//osg::Vec3 vecCameraPos = loadedModel2-getBound().center();
osg::Vec3 vecCameraPos = osg::Vec3(18748, -12503, 34512);
osg::Vec3 vecLookAtPos = vecCameraPos;
vecCameraPos.z() += 35000.0;
view2-getCamera()-setViewMatrixAsLookAt(
vecCameraPos,
vecLookAtPos,
osg::Vec3(
0,
1,
0
)
);
viewer-addView(view2);
frame1-SetViewer(viewer);
/* Show the frame */
frame1-Show(true);
frame2-Show(true);
return true;
}
IMPLEMENT_APP(wxOsgApp)
BEGIN_EVENT_TABLE(MainFrame, wxFrame)
EVT_IDLE(MainFrame::OnIdle)
END_EVENT_TABLE()
/* My frame constructor */
MainFrame::MainFrame(wxFrame *frame, const wxString title, const wxPoint
pos,
const wxSize size, long style)
: wxFrame(frame, wxID_ANY, title, pos, size, style)
{
}
void MainFrame::SetViewer(osgViewer::CompositeViewer
Re: [osg-users] Displaying stats
sorry, this is in the old one Provide by Producer. 2007/9/20, Marcus Fritzen [EMAIL PROTECTED]: Thank you both. Like Robert said, atm there is no automatically count of the triangles in the StatsHandler. I am not sure what you mean with the display in the stats graph, David? I have taken a look at the osgViewer examples, but they all use the StatsHandler, which I am using right now, too. David Callu wrote: lol synchronized That is all, but another question. Is there also a possibility to count the triangles in the scene? this is display in the Stats graph David ___ 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] Displaying stats
Hi all, just one question, there is possible using osgViewer::StatsHandler with a compositeViewer in the osg-2.1.11? Thanks bnua 2007/9/20, Marcus Fritzen [EMAIL PROTECTED]: Thank you both. Like Robert said, atm there is no automatically count of the triangles in the StatsHandler. I am not sure what you mean with the display in the stats graph, David? I have taken a look at the osgViewer examples, but they all use the StatsHandler, which I am using right now, too. David Callu wrote: lol synchronized That is all, but another question. Is there also a possibility to count the triangles in the scene? this is display in the Stats graph David ___ 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] Error with current osgDotNet wrapper generators
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: The error was because OSG is apparently installing the osgwrapper_*.dll files in the osgplugins directory instead of in the bin directory like normal. Copying them to bin generates the wrappers. Haven't tried building them yet though. I think this might be already fixed... There's logic in the generator to handle the bin vs. plugins directory change, and it's been working fine for me with 2.1.9. It's gated in the preprocessor based on OSG version, so it could be that you're picking up old OSG headers when building the generator. The logic in question is in AugmentedTypesFactory::loadIntrospectionLibraries; I'd try dumping preprocessed source and/or stepping through in the debugger to see what's happening. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying stats
On 9/20/07, Benoit bossavit [EMAIL PROTECTED] wrote: just one question, there is possible using osgViewer::StatsHandler with a compositeViewer in the osg-2.1.11? StatsHandler does not support CompositeViewer yet. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] loosing some textures when moving window to 2nd screen
It turned out that an updated driver fixed the problem for my machine
with Windows and NVIDIA Quadro FX 4500. Sorry about the question.
/Christer
Robert Osfield wrote:
HI Christer,
Are you working under Windows? NVidia hardware?
There has been various threads on osg-users over the last few months
about moving windows across screens and then problems ensuing. Please
read through these to get an understanding of the problem and
solutions w.r.t driver settings.
Robert.
On 9/20/07, Christer Wigren [EMAIL PROTECTED] wrote:
Hi,
We are using wxwidgets with multiple windows on a WindowsXP machine. A
problem that we have come across is that (when running with 1 graphics
card but two screens) the textures sometimes disappears on some of the
windows when moved from one screen to the next (see attached images). If
the window is moved on the same screen everything is fine. I have
attached (without the 3D models) sample code (a modified version of the
osgviewerWX example) that will reproduce the problem on my machine. Any
thoughts?
/Christer
// For compilers that support precompilation, includes wx.h.
#include wx/wxprec.h
#ifdef __BORLANDC__
#pragma hdrstop
#endif
#ifndef WX_PRECOMP
#include wx/wx.h
#endif
#include osgviewerWX.h
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include osg/MatrixTransform
#include wx/image.h
#include wx/menu.h
#include wx/statline.h
#include wx/listctrl.h
// `Main program' equivalent, creating windows and returning main app frame
bool wxOsgApp::OnInit()
{
// Create the main frame window
MainFrame *frame1 = new MainFrame(NULL, wxT(wxWidgets OSG Sample),
wxDefaultPosition, wxDefaultSize);
wxFrame* frame2 = new wxFrame(frame1, wxID_ANY, Extra window 2,
wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE);
// create osg canvas
//- initialize
int width = 800;
int height = 600;
GraphicsWindowWX* gw1 = new GraphicsWindowWX(frame1, wxID_ANY,
wxDefaultPosition,
wxSize(width, height),
wxSUNKEN_BORDER);
GraphicsWindowWX* gw2 = new GraphicsWindowWX(frame2, wxID_ANY,
wxDefaultPosition,
wxSize(width, height),
wxSUNKEN_BORDER);
osgViewer::CompositeViewer *viewer = new osgViewer::CompositeViewer;
viewer-setThreadingModel(osgViewer::CompositeViewer::ThreadingModel::ThreadPerCamera);
osgViewer::View* view1 = new osgViewer::View;
osgViewer::View* view2 = new osgViewer::View;
// load the scene.
osg::Node* loadedModel1 =
osgDB::readNodeFile(D:/MySVN/EWSim/data/FoiLoggo/loggo.osg);
if (!loadedModel1)
{
return false;
}
osgDB::Registry::instance()-getDataFilePathList().push_back(D:/MySVN/EWSim/data/EngelHolmMap);
osg::Node* loadedModel2 = osgDB::readNodeFile(aaaLOD_TOP.osg);
if (!loadedModel2)
{
return false;
}
osgDB::Registry::instance()-getDataFilePathList().pop_back();
view1-getCamera()-setGraphicsContext(gw1);
view1-getCamera()-setViewport(0,0,width,height);
view1-addEventHandler(new osgViewer::StatsHandler);
view1-setSceneData(loadedModel1);
view1-setCameraManipulator(new osgGA::TrackballManipulator);
viewer-addView(view1);
osg::Camera* pCamera = new osg::Camera;
view2-setCamera(pCamera);
view2-getCamera()-setGraphicsContext(gw2);
view2-getCamera()-setViewport(0,0,width,height);
view2-addEventHandler(new osgViewer::StatsHandler);
view2-setSceneData(loadedModel2);
osg::Viewport* pViewport2 = view2-getCamera()-getViewport();
double dAspectRatio = pViewport2-aspectRatio();
double clippingNearDistance = 2.0;
double clippingFarDistance = 30.0;
view2-getCamera()-setProjectionMatrixAsOrtho(
-5,
5,
-37500,
37500,
2,
30
);
//osg::Vec3 vecCameraPos = loadedModel2-getBound().center();
osg::Vec3 vecCameraPos = osg::Vec3(18748, -12503, 34512);
osg::Vec3 vecLookAtPos = vecCameraPos;
vecCameraPos.z() += 35000.0;
view2-getCamera()-setViewMatrixAsLookAt(
vecCameraPos,
vecLookAtPos,
osg::Vec3(
0,
1,
0
)
);
viewer-addView(view2);
frame1-SetViewer(viewer);
/* Show the frame */
frame1-Show(true);
frame2-Show(true);
return true;
}
IMPLEMENT_APP(wxOsgApp)
BEGIN_EVENT_TABLE(MainFrame, wxFrame)
EVT_IDLE(MainFrame::OnIdle)
END_EVENT_TABLE()
/* My frame constructor */
MainFrame::MainFrame(wxFrame *frame, const wxString title, const wxPoint
pos,
const wxSize size, long style)
: wxFrame(frame, wxID_ANY, title, pos, size,
Re: [osg-users] Error with current osgDotNet wrapper generators
Hi Mike, I'll try to take a look at it this evening if I get a chance. The only issue I had with building the wrappers after I copied the dlls to the bin folder was the fact that it didn't like the allocatemipmap was pure virtual b/c osgDotNet was trying to create an instance of the Texture class and it was abstract. Jason On 9/20/07, Mike Wittman [EMAIL PROTECTED] wrote: On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: The error was because OSG is apparently installing the osgwrapper_*.dll files in the osgplugins directory instead of in the bin directory like normal. Copying them to bin generates the wrappers. Haven't tried building them yet though. I think this might be already fixed... There's logic in the generator to handle the bin vs. plugins directory change, and it's been working fine for me with 2.1.9. It's gated in the preprocessor based on OSG version, so it could be that you're picking up old OSG headers when building the generator. The logic in question is in AugmentedTypesFactory::loadIntrospectionLibraries; I'd try dumping preprocessed source and/or stepping through in the debugger to see what's happening. -Mike ___ 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] OpenSceneGraph with Qt multiple windowing problem
El Wednesday 19 September 2007 20:58:00 Robert Osfield escribió: For apps that have multiple windows and mulitple views on to one or more scenes that CompositeViewer is the most apporpriate tool. There is but though, running with multiple graphics context is not possible when one use GraphicsWindowEmbedded - only single threaded, single context per Viewer/CompositeViewer is possible. If you have multiple Windows then you need a separate Viewer/CompositeViewer for each one. I'm a bit confused about the naming. What do you mean by graphics context? An OpenGL one or an osg::GraphicsContext? I ask because currently I have a wxWidgets application with two views of the same scene. Each view is attached to an osgViewer::GraphicsWindow which in turn controls its wxGLcanvas. The two wxGLcanvas were created with a common OpenGL context, so all the GL objects as display lists, textures... are shared. Each osgViewer::GraphicsWindow has one osg::State. In summary I have 2 wxGLCanvas ( sharing GL objects, one only common wxGLContext) 2 osgViewer::GraphicsWindow ( which are in fact 2 osg::GraphicContext) 2 osgViewer::View (I'm using osgViewer::CompositeViewer) 2 osg::State (not sure if only one would do) If, in addition, I wanted to show two more views of a new different scene, should I do the same as before (creating 2 GraphicsWindows, 2 Views, 2 States and connect them to the 2 wxGLCanvas with a new shared OpenGL context) and attaching the Views to the existing CompositeViewer or should I create a new CompositeViewer and attach the 2 new Views there? Thanks for the tips, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG?: mouse coordinate changes after window move
Problem 2 (windowed): We are using gnome on Ubuntu, and osgviewer --window 100 100 500 500 cow.osg works fine, but after 'f' is pressed two times (first into fullscreen, and then back to windows), we dont get a window. So it seems that it is not possible to go back from fullscreen windowed mode. Problem1: Yes, It seems to be a bug for windows only, so the problem is probably as you say in GraphicsWindowWin32. /Anders On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Anders, On 9/20/07, Anders Backman [EMAIL PROTECTED] wrote: Im using a recent svn version (a few weeks old) of osg under windows (both VISTA and XP). I have noticed that if I: 1. Start osgviewer cow.osg 2. press 'f' to get into windowed mode 3. if I now move the whole window and release it, I can see that the view/projection changes slightly. Another illustration: A small app that output the coordinates of a mouse click in the window 1. start that application and make it windowed 'f' 2. click on a specific point in the scene, ea.getX (), ea.getY() reports: (132, 171) 3. move the window a little bit, click in the same point in the scene ea.getX(), ea.getY() reports: (139 ,121) 4. move the window again to any position on the screen, and now ea.getX(), ea.getY() reports consistent results. So to me it seems that the first move-window messes (or corrects) the view/projection. This sounds like a GraphicsWindowWin32 bug in some form. Now I tried this on a ubuntu machine, but on that one the windowed mode did not work at all. Pressing 'f' results in a brief flicker of the window, and I can for a fraction of a second see a smaller cow, no window decoration in the lower left corner of the display. I use Kubuntu and Suse here and both work fine for me. Both are KDE though. From the sound of it it sounds like the window manager is screwing up when no decoration is appearing when it goes into windowing mode. Could you try : osgviewer --window 100 100 500 500 cow.osg Does the mouse and window decoration work OK? 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] OpenSceneGraph with Qt multiple windowing problem
Hi Alberto, On 9/20/07, Alberto Luaces [EMAIL PROTECTED] wrote: I'm a bit confused about the naming. What do you mean by graphics context? An OpenGL one or an osg::GraphicsContext? osg::GraphicsContext maps directly to an OpenGL context so there should not be any confusion. I ask because currently I have a wxWidgets application with two views of the same scene. Each view is attached to an osgViewer::GraphicsWindow which in turn controls its wxGLcanvas. The two wxGLcanvas were created with a common OpenGL context, so all the GL objects as display lists, textures... are shared. Each osgViewer::GraphicsWindow has one osg::State. A sharing OpenGL contexts doesn't mean actually sharing of the context, its just sharing some data between contexts, so you don't have a common OpenGL context, you have two separate OpenGL contexts that are sharing display lits/texture objects etc. Each GraphicsWindow is a GraphicsContext which maps directly to a single OpenGL graphics context. Each OpenGL graphics context has its own state machine which is mapped by a single osg::State object - which you'll find on the GraphicsContext. Sharing of display lists/texture objects between contexts on the OSG just requires you to set the State::ContextID to same value. If the GraphicsWindow implementation is set up correctly then it'll automatically assign the same ContextID for each of the seperate osg::State objects. In summary I have 2 wxGLCanvas ( sharing GL objects, one only common wxGLContext) 2 osgViewer::GraphicsWindow ( which are in fact 2 osg::GraphicContext) 2 osgViewer::View (I'm using osgViewer::CompositeViewer) 2 osg::State (not sure if only one would do) If, in addition, I wanted to show two more views of a new different scene, should I do the same as before (creating 2 GraphicsWindows, 2 Views, 2 States and connect them to the 2 wxGLCanvas with a new shared OpenGL context) and attaching the Views to the existing CompositeViewer or should I create a new CompositeViewer and attach the 2 new Views there? Ideally a single CompositeViewer should be used per app, and the various Views and associate GraphicsWindow managed according to your needs. The osg::State objects should all be managed as an implementation detail, you shouldn't need to concern yourself with it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG?: mouse coordinate changes after window move
On 9/20/07, Anders Backman [EMAIL PROTECTED] wrote: Problem 2 (windowed): We are using gnome on Ubuntu, and osgviewer --window 100 100 500 500 cow.osg works fine, but after 'f' is pressed two times (first into fullscreen, and then back to windows), we dont get a window. So it seems that it is not possible to go back from fullscreen windowed mode. This is a bug in the window manager ignoring request to add decoration back in. It might be possible to code a workaround for working with such windowing managers but alas I can't divine what the problem might be as everything works just fine on all my linux boxes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::CameraNode doesn't render the scene behind the osgProducer::Camera
Thanks, you are right the problem was setup config: The one corner of screen aligned quad is in the world center, I used vertex shader from rendermonkey to assign the quad to the screen. After I placed the quad corners to another coordinates, the problem was away. Thanks to all for support! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, September 20, 2007 10:32 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osg::CameraNode doesn't render the scene behind the osgProducer::Camera Hi, On 9/19/07, zarrandreas [EMAIL PROTECTED] wrote: Thanks for the tip, but I can't use osgViewer, because I use custom framework and this framework use osgProducer::Viewer. osgProducer::Viewer apps can typically be ported to osgViewer::Viewer in minutes, they have lots of similarities. The Prerender Example in osg framework use also osgProducer::Camera and osg::CameraNode to render the scene to the texture. Maybe the problem is in the using of the screen aligned quad (= I align the quad to the screen in the vertex shader). When you say osg framework what do you mean? There is no osg framework unless its on your side. Do you mean the osg examples that came with 1.2? As a general note render to texture setup can normally be done totally independently from the viewer, code can be ported across different viewers and should still work. The viewer also shouldn't make any difference. If you have problem with RTT then its likely that its a pure scene graph set up issue. As for the problem with your set up one really can't say what might be up with so few details of how you've set up the scene graph. 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] osgDotNet and Windows Forms
Hi Christoffer, I'm not sure what would be going on. I can try to take a look at your code if you can send it to me, but I'm a little pressed for time right now so I don't know when I'd get to it. Jason On 9/19/07, Christoffer Markusson [EMAIL PROTECTED] wrote: Unfortunately nothing happens. Christoffer 2007/9/19, Jason Beverage [EMAIL PROTECTED]: Just guessing, but what happens if you hit the space bar with the app running? That should tell the camera manipulator to go to the home position. Jason 2007/9/19, Christoffer Markusson [EMAIL PROTECTED]: Jason, Thanks for your reply. My program is a simple form with your control and a timer in it. The only thing it does is to get an reference to the viewer in the control and then use setSceneData on it. (to construct the scene data I've used the example from http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappers ). After this, the application is launched using Application.Run. From your suggestion I invalidate the controller each timer click. What I get when I run the application is just the form, nothing is displayed in the control. Christoffer 2007/9/19, Jason Beverage [EMAIL PROTECTED]: Hi Christoffer, I'd need a little more information about what is going on. I assume you passed a Node to the viewer using the setSceneData function. Also, to get a continuous update, I just dropped a timer on the form and set it to call Invalidate on the OSG control on tick. Jason 2007/9/19, Christoffer Markusson [EMAIL PROTECTED]: Hi Jason, Thanks for your help! I've used your code to create a controller in Visual Studio. But when I try to use the controller in a project it dosen't render anything. Could you please give me an example of how you use your controller? Christoffer 2007/9/19, Jason Beverage [EMAIL PROTECTED]: Hi Christoffer, Here is a simple control that uses TAO to display an OSG window that I've used for testing. Thanks! Jason 2007/9/18, Christoffer Markusson [EMAIL PROTECTED]: I'm using OSG together with C# in Visual Studio 2005 using the osgDotNet wrappers. Is there an easy way to integrate and display an OSG window in a Windows Form? Does anyone have example code? Christoffer ___ 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] BUG?: mouse coordinate changes after window move
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Anders Backman [EMAIL PROTECTED] wrote: Problem 2 (windowed): We are using gnome on Ubuntu, and osgviewer --window 100 100 500 500 cow.osg works fine, but after 'f' is pressed two times (first into fullscreen, and then back to windows), we dont get a window. So it seems that it is not possible to go back from fullscreen windowed mode. This is a bug in the window manager ignoring request to add decoration back in. It might be possible to code a workaround for working with such windowing managers but alas I can't divine what the problem might be as everything works just fine on all my linux boxes. Robert. Hi Robert, I have been experimenting with window manager hints regarding a different but related issue. I'm running GNOME under Fedora 5, and the fullscreen mode in osgviewer creates a window that stays under the top and bottom toolbar panels. For me, switching to windowed mode properly adds the window decorations. But what I discovered is that to get true fullscreen windows in GNOME, I need to use the Extended Window Manager Hints (EWMH): http://standards.freedesktop.org/wm-spec/wm-spec-latest.html Sending a ClientMessage event (or using XChangeProperty before mapping the window) to toggle the _NET_WM_STATE_FULLSCREEN Atom for the _NET_WM_STATE property works as expected -- the window is undecorated and appears on top of the toolbars in fullscreen state. I was looking into the OSG implementation and it seems that fullscreen is implemented using a window resize to screen dimensions + the Motif window manager hints to remove decorations. The EWMH spec is intended to replace Motif hints, and it has a slightly different philosophy. You specify the usage/type of window rather than directly controlling the use of decorations. I think what would be needed is a virtual fullscreen() method in GraphicsWindow that can be overriden in GraphicsWindowX11 using this implementation if the window manager supports it, and then the toggleFullscreen() method in ViewerEventHandler could call this function rather than setting the window rectangle and decoration (in the EWMH spec, the window manager is responsible for restoring the original window geometry and decoration when leaving fullscreen state). -- Leif Delgass [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tree Creation Workflow
Hi Nick, Definitely OpenFlight, I think you'll find the best billboard support there. You can use Remo 3D to create trees and export them directly to IVE. You can even use the demo version for this (www.remograph.com). /Andreas Nick Prudent wrote: For those who deal with terrain in OSG, what tool do you use to create trees as textured transparent billboard to be loaded by OSG? I'm just wondering what's the best native format for creating the trees. Examples: FLT -- OSG -- IVE or 3DS -- OSG -- IVE or VRML -- OSG -- IVE ... Thanks, - Nick - _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- __ Andreas Ekstrand Remograph Norrbergavägen 58 SE-590 54 Sturefors SWEDEN Website: http://www.remograph.com/ E-mail: [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenThreads threading bug on creation/deletion (leads to crashes)
I've attached the version I'm using that demonstrates the unusability
of the isRunning() flag.
The code pasted into the last e-mail is all that's necessary to
illustrate the crash, though it doesn't try to avoid it using the
'isRunning' flag. You shouldn't need to modify the OpenThreads
library.
I get the following error after running the attached code:
pure virtual method called
terminate called without an active exception
Aborted
presumably because thread-run() is being called on an object that has
been trashed.
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
Could you send the exact code that you can recreate the issue with.
Robert.
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Ah - just double-checked. It'll crash just fine without adding the
usleep() to OpenThreads; I had my builds mixed up.
AC
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
Hi, Robert,
The following is sufficient (basically what you said):
#include OpenThreads/Thread
class MyThread : public OpenThreads::Thread {
public:
void run(void) { }
};
int main(int argc, char* argv[]) {
{
MyThread thread;
thread.startThread();
}
while(1) ;
return 0;
}
You need the while(1) ; to prevent the process from dying and cleaning
up the thread before it wrecks. This alone wouldn't reproduce the bug
because the interleaving doesn't happen (it's a very short window in
which it can happen). To force the bug, I added ::usleep(100) at
the beginning of ThreadPrivateActions::StartThread().
AC
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Adam,
On 9/20/07, Adam Coates [EMAIL PROTECTED] wrote:
So, I just realized that the OSG folks are not synonymous with the
OpenThreads folks. ^_^ Sorry for dropping this on the wrong list
then.
Well OpenThreads list is a flat line, almost all (99.9%) OpenThreads
activity and development is done by members of the OpenSceneGraph
community. So this is probably the best place to raise issues like
this. Responsibility for maintaining OpenThreads has also fallen on
my shoulders as it effectively became an orphaned project when the
original project lead got sucked into non coding management.
In that light, it may not even be considered a bug in OT,
since, theoretically, it might be unfair to call the Thread destructor
while the thread is running (even though I'm pretty sure they intended
isRunning() to work as we'd expect).
Well this type of usage is kinda abusing the Thread class, but I'd
still say this way a bug.
It should be possible to add a workaround in the following way:
1. Before starting the thread, set a flag to indicate that the thread
is starting up.
2. Have the thread's run() routine unset this flag.
Before deleting the Thread, make sure that both the starting up flag
and the isRunning flag are false. One of these will have to be true
if the thread has not reached the run() method yet, or has not
completely exited from run() -- thus avoiding the problem.
I'll have ponder in this issue, I'm more inclined to use a mutex in
some way that just a straight flag.
My question: does somebody want me to implement this workaround and
submit it to you? Alternatively, I can just point out the break to
the OpenThreads people and we can wait for a patch...
It's best to just roll your sleeves up and get stuck in. First up we
need a test that can reliably reproduce the error. Would the
following code block do the trick?
{
OpenThreads::Thread thread;
thread.startThread();
}
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
ottest.cpp
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet and Windows Forms
Hi Jason,
Once again, thanks for taking the time and trying to help.
I've attached all the .cs files in my project.
Christoffer
2007/9/19, Jason Beverage [EMAIL PROTECTED]:
Hi Christoffer,
I'm not sure what would be going on. I can try to take a look at your code
if you can send it to me, but I'm a little pressed for time right now so I
don't know when I'd get to it.
Jason
2007/9/19, Christoffer Markusson [EMAIL PROTECTED]:
Unfortunately nothing happens.
Christoffer
2007/9/19, Jason Beverage [EMAIL PROTECTED]:
Just guessing, but what happens if you hit the space bar with the app
running? That should tell the camera manipulator to go to the home
position.
Jason
2007/9/19, Christoffer Markusson [EMAIL PROTECTED]:
Jason,
Thanks for your reply.
My program is a simple form with your control and a timer in it. The
only thing it does is to get an reference to the viewer in the control
and then use setSceneData on it. (to construct the scene data I've
used the example from
http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappers).
After this, the application is launched using Application.Run.
From your suggestion I invalidate the controller each timer click.
What I get when I run the application is just the form, nothing is
displayed in the control.
Christoffer
2007/9/19, Jason Beverage [EMAIL PROTECTED]:
Hi Christoffer,
I'd need a little more information about what is going on. I assume you
passed a Node to the viewer using the setSceneData function. Also, to get
a
continuous update, I just dropped a timer on the form and set it to call
Invalidate on the OSG control on tick.
Jason
2007/9/19, Christoffer Markusson [EMAIL PROTECTED]:
Hi Jason,
Thanks for your help!
I've used your code to create a controller in Visual Studio. But when
I try to use the controller in a project it dosen't render anything.
Could you please give me an example of how you use your controller?
Christoffer
2007/9/19, Jason Beverage [EMAIL PROTECTED]:
Hi Christoffer,
Here is a simple control that uses TAO to display an OSG window that I've
used for testing.
Thanks!
Jason
2007/9/18, Christoffer Markusson [EMAIL PROTECTED]:
I'm using OSG together with C# in Visual Studio 2005 using the
osgDotNet wrappers.
Is there an easy way to integrate and display an OSG window in a
Windows Form? Does anyone have example code?
Christoffer
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
namespace OSGtest3
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
public ControlTest.OSGControl getControl() { return osgControl1; }
public Timer getTimer() { return timer1; }
private void timer1_Tick(object sender, EventArgs e)
{
osgControl1.Invalidate();
}
}
}namespace OSGtest3
{
partial class Form1
{
/// summary
/// Required designer variable.
/// /summary
private System.ComponentModel.IContainer components = null;
/// summary
/// Clean up any resources being used.
/// /summary
/// param name=disposingtrue if managed resources should be
disposed; otherwise, false./param
protected override void Dispose(bool disposing)
{
if (disposing (components != null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#region Windows Form Designer generated code
/// summary
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// /summary
private void InitializeComponent()
{
this.components = new System.ComponentModel.Container();
this.timer1 = new System.Windows.Forms.Timer(this.components);
this.osgControl1 = new ControlTest.OSGControl();
this.SuspendLayout();
//
// timer1
//
this.timer1.Tick += new System.EventHandler(this.timer1_Tick);
//
// osgControl1
//
this.osgControl1.AccumBits = ((byte)(0));
this.osgControl1.AutoCheckErrors = false;
this.osgControl1.AutoFinish = false;
this.osgControl1.AutoMakeCurrent = true;
this.osgControl1.AutoSwapBuffers = true;
this.osgControl1.BackColor = System.Drawing.Color.DarkRed;
this.osgControl1.ColorBits = ((byte)(32));
this.osgControl1.DepthBits = ((byte)(16));
this.osgControl1.Location = new System.Drawing.Point(133, 158);
Re: [osg-users] Error with current osgDotNet wrapper generators
Hi Jason, I don't see anything special about the osg::Texture::allocateMipmap function interface that should cause that problem, and it sounds like other pure virtual Texture functions are handled appropriately. Possibly it could be due to a mismatch in OSG versions between headers and wrapper DLLs. I'll look into it when I have the chance. -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Thursday, September 20, 2007 10:22 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Error with current osgDotNet wrapper generators Hi Mike, I'll try to take a look at it this evening if I get a chance. The only issue I had with building the wrappers after I copied the dlls to the bin folder was the fact that it didn't like the allocatemipmap was pure virtual b/c osgDotNet was trying to create an instance of the Texture class and it was abstract. Jason On 9/20/07, Mike Wittman [EMAIL PROTECTED] wrote: On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: The error was because OSG is apparently installing the osgwrapper_*.dll files in the osgplugins directory instead of in the bin directory like normal. Copying them to bin generates the wrappers. Haven't tried building them yet though. I think this might be already fixed... There's logic in the generator to handle the bin vs. plugins directory change, and it's been working fine for me with 2.1.9. It's gated in the preprocessor based on OSG version, so it could be that you're picking up old OSG headers when building the generator. The logic in question is in AugmentedTypesFactory::loadIntrospectionLibraries; I'd try dumping preprocessed source and/or stepping through in the debugger to see what's happening. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLT(CTS)
On 9/20/07, HUTTERER ARIEL [EMAIL PROTECTED] wrote: Hi : That OSG support , DB builded with CTS??? Ariel, There was talk a while back about a CTS Metaflight loader ... try a Google for osg metaflight -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error with current osgDotNet wrapper generators
Hi Mike,
I'm not sure why it is causing an issue either. It seems like adding
virtual void allocateMipmap(osg::State ) const {}
in the same way that
virtual void computeInternalFormat() const { } is added in
GeneratorConfiguration.cpp allows it to get past the issue.
I still don't have a total handle on the generated code just yet, but I'm
getting there:)
Jason
On 9/20/07, Mike Wittman [EMAIL PROTECTED] wrote:
Hi Jason,
I don't see anything special about the osg::Texture::allocateMipmap
function interface that should cause that problem, and it sounds like other
pure virtual Texture functions are handled appropriately. Possibly it could
be due to a mismatch in OSG versions between headers and wrapper DLLs. I'll
look into it when I have the chance.
-Mike
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Jason Beverage
*Sent:* Thursday, September 20, 2007 10:22 AM
*To:* OpenSceneGraph Users
*Subject:* Re: [osg-users] Error with current osgDotNet wrapper generators
Hi Mike,
I'll try to take a look at it this evening if I get a chance. The only
issue I had with building the wrappers after I copied the dlls to the bin
folder was the fact that it didn't like the allocatemipmap was pure virtual
b/c osgDotNet was trying to create an instance of the Texture class and it
was abstract.
Jason
On 9/20/07, *Mike Wittman* [EMAIL PROTECTED] wrote:
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote:
On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote:
The error was because OSG is apparently installing the
osgwrapper_*.dll
files in the osgplugins directory instead of in the bin directory
like
normal. Copying them to bin generates the wrappers. Haven't tried
building
them yet though.
I think this might be already fixed...
There's logic in the generator to handle the bin vs. plugins directory
change, and it's been working fine for me with 2.1.9. It's gated in the
preprocessor based on OSG version, so it could be that you're picking up
old OSG headers when building the generator. The logic in question is
in AugmentedTypesFactory::loadIntrospectionLibraries; I'd try dumping
preprocessed source and/or stepping through in the debugger to see
what's happening.
-Mike
___
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
