[osg-users] Graphics context size Screen capture question

Hello. I'm currently implementing a screen capture functionality and I have a few questions regarding the GraphicsContext size and the Image::readPixels function. In the first scenario I want to create a graphics context of size 3840x1080. My Monitor is only 2560x1600 and the graphics context

Re: [osg-users] Graphics context size Screen capture question

Hi Nick, I'll look into the osgPoster. Thanks so much. Update: I was able to fix the problem with 2 cameras rendering to the same position. In the real application I have a lot more than 2 cameras and I had attached the callback to the wrong camera. :) //Christoffer -- Read

Re: [osg-users] osgViewer takes over my standard input

I tried switching to getline stringstream combo and also using the ignore statement to ignore previous content in the buffer. It still gave me the same non blocking result though. I received your code, I will have a look at it, thanks :) Kind Regards Christoffer -- Read this

Re: [osg-users] osgViewer takes over my standard input

Hello, I'm trying to write a program where the renderer is running on a separate thread. On the main thread I want to control the command line inputs but as soon as I add scenedata to the osgViewer which is stored in the renderer then the renderer takes over the standard input. std::cin in the

Re: [osg-users] osgViewer takes over my standard input

Hello, This problem occurs when I run the code on an old machine with intel core 2 duo,Nvidia quadro FX 580, 4gb ram, OS=Slackware. If I run this code on another machine with Intel i7-3770, AMD Radeon 7800 series (2gb), 12gb ram, OS=Red Hat then the code runs just fine. Do you have any ideas

Re: [osg-users] osgViewer takes over my standard input

hmm ok. I tried the code on another computer with specifications between the two computers mentioned before. This one running Slackware as well. And the code ran fine on this one. Theyre using the same terminal and as far as I know they also use the same compiler. As I mentioned before,

Re: [osg-users] osgViewer takes over my standard input

Hi Robert, That is pretty much what I'm doing, just the other way around. The main thread is responsible for handling standard inputs, while the second thread is responsible for handling the renderer. Hi Jorge, That is exactly what I try to mimic using the current design :) I cant add

Re: [osg-users] osgViewer takes over my standard input

The cin in the thread is only there for demonstration purposes. It was used to test the blocking of the cin function. If i write cin in the render thread then the program is halted. If i write it in the main thread it is not halted. The model code is also just for demonstration. That part of

Re: [osg-users] osgViewer takes over my standard input

The cin in the render thread is not supposed to be there. They were just put there to see if they would block or not, which they did. The problem i have is that if i write cin in any other thread than the render thread, then the thread containing the cin command does not block. It jumps over

[osg-users] osgViewer takes over my standard input

Hello, I'm trying to write a program where the renderer is running on a separate thread. On the main thread I want to control the command line inputs but as soon as I add scenedata to the osgViewer which is stored in the renderer then the renderer takes over the standard input. std::cin in the