Re: [osg-users] QT code

2013-01-15 Thread Bhaskar Bhattacharya

Roni Zanolli  writes:

> 
> Hi,
> 
>  Attached a sample code. If you are using QtCreator this will be even easier. 
>  
Create a gui application.
>  In your mainwindow.ui create a widget and promote it to QtOsgLib. Copy the 
files attached to your project
> and that's it.
> 
>   Let me know if it worked for you.
> 
> Cheers,
> Roni
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42069#42069
> 
> Attachments: 
> http://forum.openscenegraph.org//files/main_997.cpp
> http://forum.openscenegraph.org//files/mainwindow_111.h
> http://forum.openscenegraph.org//files/mainwindow_143.cpp
> http://forum.openscenegraph.org//files/qtosglib_923.h
> http://forum.openscenegraph.org//files/qtosglib_106.cpp
> 
> 

Hi,

I know its been like a year but I had the same issues. Just wanted to say 
thanks 
for the code examples, it really helped me out!!

Thanks
Bhaskar



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] osgManipulator serializers not working

2013-01-15 Thread Michael Schanne
Hi,

Thanks Robert!  The .osgt format worked just fine.  I didn't know about the new 
formats.  Guess I should have read the Beginner's Guide more carefully :)

... 

Thank you!

Cheers,
Michael

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51974#51974





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] GL_RENDERER string

2013-01-15 Thread Paul Martz

(Cross-posting to the osgWorks Google Group.)

osgWorks r474 now has a singleton instance that allows apps to access 
GL_RENDERER and other values without a current context. To use this tool, do 
something like the following:


osgwTools::Capabilities* caps = 
osgwTools::CapabilitiesSingleton::instance()->getCaps();


Then you can do anything you would normally do with the Capabilities object, 
such as:

// Dump out all the queried values:
caps->dump( osg::notify( osg::ALWAYS ) );
// or just get a copy of the GL_RENDERER string:
const std::string rendererStr = caps->_glRenderer;

Calling dump() produces output like this:

osgWorks version 2.0.3 (20003).
OSG version: 3.1.4
  Queryable strings 
GL_VERSION: 3.3.0
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 9800M GT/PCIe/SSE2
GL_SHADING_LANGUAGE_VERSION: 3.30 NVIDIA via Cg compiler
  Texture implementation constants -
GL_MAX_TEXTURE_SIZE: 8192
GL_MAX_3D_TEXTURE_SIZE: 2048
GL_MAX_CUBE_MAP_TEXTURE_SIZE: 8192
GL_MAX_TEXTURE_UNITS: 4
  Shader implementation constants --
GL_MAX_TEXTURE_IMAGE_UNITS: 32
GL_MAX_TEXTURE_COORDS: 8
GL_MAX_VERTEX_ATTRIBS: 16
GL_DRAW_BUFFERS: 8

I'm not exactly sure how OSG's pbuffer creation works in the case of 
heterogeneous GPUs. I imagine there is a "primary" GPU that handles the context 
creation. To use osgWorks to get per-GPU capabilities, you would need to create 
a separate instance of an osgwTools::Capabilities object while a context is 
current on each separate GPU. This can probably be done with a Camera draw callback.

   -Paul


On 1/15/2013 10:16 AM, Paul Martz wrote:

Chris, you're right about the heterogeneous case.

Current svn trunk HEAD of the osgWorks project has a couple tools that might 
help.

There is a struct osgwTools::Capabilities that your app can invoke while any
context is current (as in a Camera pre-draw callback). It obtains the
GL_RENDERER string plus other strings and GL implementation dependent constants.
It has a dump(std::ostream&) method, which your app can invoke to display the
queried values.

There is also a standalone application called osgwcaps, which simply creates a
pbuffer context, makes it current, creates a Capabilities struct, and dumps the
values to osg::ALWAYS.

Chris, I agree it would be nice to have this someplace instantly accessible. I
might be able to add a static that would query these values at DLL load time.

I hope this helps.
-Paul


On 1/15/2013 8:17 AM, Chris Hanson wrote:

I've been in this situation before too, and it would be very handy to have the
GL_RENDERER and other identifying strings stored in OSG for the user code to
query. Since many people don't know you have to have the context valid, and
others don't know where/when OS has a valid context bound, it would be useful.

Potentially, this information could be per-window-specific, couldn't it?
Multiple heterogenous display cards on one machine could return different
results for different contexts.


On Tue, Jan 15, 2013 at 4:32 AM, Alistair Baxter mailto:alist...@mve.com>> wrote:

My solution thus far has been to call glGetString in the same function after
my call to osg::GL2Extensions::Get, since the OpenGL context appears to be
valid at that time - indeed the glGetString call is made internally by the
GLExtensions stuff at that time.

__ __

It just seems like the renderer string should be exposed by the extensions
object and it’s not.

__ __

*From:*osg-users-boun...@lists.openscenegraph.org

[mailto:osg-users-boun...@lists.openscenegraph.org
] *On Behalf Of *Gianluca
Natale
*Sent:* 15 January 2013 10:54
*To:* OpenSceneGraph Users
*Subject:* [osg-users] R: GL_RENDERER string

__ __

Out of OSG/Qt, I think you should:

__1)__Create a very simple rendering context (associated to the window
created by your application);

__2)__Make that rendering context as the current one;

__3)__Call glGetString(GL_RENDERER, …);

__ __

Steps 1 and 2 are required, since all gl calls need a current rendering
context to work with.

About steps 1 and 2, you should look at how OSG create the rendering
context.

__ __

*Da:*osg-users-boun...@lists.openscenegraph.org

[mailto:osg-users-boun...@lists.openscenegraph.org] *Per conto di *Alistair
Baxter
*Inviato:* martedì 15 gennaio 2013 10:47
*A:* osg-users@lists.openscenegraph.org

*Oggetto:* [osg-users] GL_RENDERER string

__ __

I’m wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt
application for debug purposes, and pote

Re: [osg-users] Problems running examples -- x86/x64 confusion?

2013-01-15 Thread Jason Fisher
Thanks a lot Chris. Your binaries look exactly the same in dependency walker. 
Yours run, mine don't -- e.g. the osgviewer.exe. 

Weird... has to be something else. Any other ideas, anybody?


ithrak (Jason Fisher)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51971#51971





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] GL_RENDERER string

2013-01-15 Thread Paul Martz

Chris, you're right about the heterogeneous case.

Current svn trunk HEAD of the osgWorks project has a couple tools that might 
help.

There is a struct osgwTools::Capabilities that your app can invoke while any 
context is current (as in a Camera pre-draw callback). It obtains the 
GL_RENDERER string plus other strings and GL implementation dependent constants. 
It has a dump(std::ostream&) method, which your app can invoke to display the 
queried values.


There is also a standalone application called osgwcaps, which simply creates a 
pbuffer context, makes it current, creates a Capabilities struct, and dumps the 
values to osg::ALWAYS.


Chris, I agree it would be nice to have this someplace instantly accessible. I 
might be able to add a static that would query these values at DLL load time.


I hope this helps.
   -Paul


On 1/15/2013 8:17 AM, Chris Hanson wrote:

I've been in this situation before too, and it would be very handy to have the
GL_RENDERER and other identifying strings stored in OSG for the user code to
query. Since many people don't know you have to have the context valid, and
others don't know where/when OS has a valid context bound, it would be useful.

Potentially, this information could be per-window-specific, couldn't it?
Multiple heterogenous display cards on one machine could return different
results for different contexts.


On Tue, Jan 15, 2013 at 4:32 AM, Alistair Baxter mailto:alist...@mve.com>> wrote:

My solution thus far has been to call glGetString in the same function after
my call to osg::GL2Extensions::Get, since the OpenGL context appears to be
valid at that time - indeed the glGetString call is made internally by the
GLExtensions stuff at that time.

__ __

It just seems like the renderer string should be exposed by the extensions
object and it’s not.

__ __

*From:*osg-users-boun...@lists.openscenegraph.org

[mailto:osg-users-boun...@lists.openscenegraph.org
] *On Behalf Of *Gianluca
Natale
*Sent:* 15 January 2013 10:54
*To:* OpenSceneGraph Users
*Subject:* [osg-users] R: GL_RENDERER string

__ __

Out of OSG/Qt, I think you should:

__1)__Create a very simple rendering context (associated to the window
created by your application);

__2)__Make that rendering context as the current one;

__3)__Call glGetString(GL_RENDERER, …);

__ __

Steps 1 and 2 are required, since all gl calls need a current rendering
context to work with.

About steps 1 and 2, you should look at how OSG create the rendering
context.

__ __

*Da:*osg-users-boun...@lists.openscenegraph.org

[mailto:osg-users-boun...@lists.openscenegraph.org] *Per conto di *Alistair
Baxter
*Inviato:* martedì 15 gennaio 2013 10:47
*A:* osg-users@lists.openscenegraph.org

*Oggetto:* [osg-users] GL_RENDERER string

__ __

I’m wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt
application for debug purposes, and potentially for showing to users for
technical support purposes.

__ __

I can get the likes of GL and GLSL version from the osg::GL2Extensions
object, and I can see the renderer string being queries in the source code,
but I’m having difficulty figuring out how to get it out.


___
osg-users mailing list
osg-users@lists.openscenegraph.org 

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL
• OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography •
Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel
 (775) 623-PIXL [7495]


___
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] Problems running examples -- x86/x64 confusion?

2013-01-15 Thread Chris Hanson
Try downloading my 3.0.1 build here:
http://alphapixel.com/osg/downloads/free-openscenegraph-binary-downloads

This will give you something working to compare with and maybe will help
you find your problems. You can run Depends on my binaries and see how they
are supposed to look.


On Tue, Jan 15, 2013 at 9:42 AM, Jason Fisher  wrote:

> For starters I guess I could use prebuilt binaries to try to figure out
> what the problem is, but at the end of the day I would like to build by
> myself.
>
> 
> ithrak (Jason Fisher)
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=51968#51968
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography
• Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS •
Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Problems running examples -- x86/x64 confusion?

2013-01-15 Thread Jason Fisher
For starters I guess I could use prebuilt binaries to try to figure out what 
the problem is, but at the end of the day I would like to build by myself.


ithrak (Jason Fisher)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51968#51968





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Problems running examples -- x86/x64 confusion?

2013-01-15 Thread Chris Hanson
Do you want to be compiling OSG yourself, or would it be helpful to just
download a pre-built and tested version for now?


On Tue, Jan 15, 2013 at 4:11 AM, Jason Fisher  wrote:

> Hi all,
>
> I'm using MSVS10 SP1 on a Win7 x64 PC and have some issues with getting
> the examples to run. I recently downloaded osg 3.0.1 and created the VS
> project files with CMake, built the osg core for both Debug and Release
> with Win32 configuration (Linker command line does include "/MACHINE:X86").
>
> When trying to run an example however, it exits with "The program '[11304]
> osgteapot.exe: Native' has exited with code -1073741701 (0xc07b)."
>
> A quick view into dependency walker showed that the exe file is
> referencing the 64 bit versions of opengl32.dll, msvcp100.dll, msvcr100.dll
> and kernel32.dll. Also all of the osg dlls are using the 64 bit modules.
>
> I have to say that I'm not into these x86/x64 mixups, for now I always
> went with x86 since it simply worked for me. So I have no idea if what I
> saw here is the actual problem, but it got me alarmed.
>
> If you have an idea about what could be the issue and how to solve it
> please help.
>
> Thanks!
>
> Cheers,
> Jason
>
> 
> ithrak (Jason Fisher)
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=51953#51953
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography
• Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS •
Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] GL_RENDERER string

2013-01-15 Thread Chris Hanson
I've been in this situation before too, and it would be very handy to have
the GL_RENDERER and other identifying strings stored in OSG for the user
code to query. Since many people don't know you have to have the context
valid, and others don't know where/when OS has a valid context bound, it
would be useful.

Potentially, this information could be per-window-specific, couldn't it?
Multiple heterogenous display cards on one machine could return different
results for different contexts.


On Tue, Jan 15, 2013 at 4:32 AM, Alistair Baxter  wrote:

>  My solution thus far has been to call glGetString in the same function
> after my call to osg::GL2Extensions::Get, since the OpenGL context appears
> to be valid at that time - indeed the glGetString call is made internally
> by the GLExtensions stuff at that time.
>
> ** **
>
> It just seems like the renderer string should be exposed by the extensions
> object and it’s not.
>
> ** **
>
> *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Gianluca Natale
> *Sent:* 15 January 2013 10:54
> *To:* OpenSceneGraph Users
> *Subject:* [osg-users] R: GL_RENDERER string
>
> ** **
>
> Out of OSG/Qt, I think you should:
>
> **1)  **Create a very simple rendering context (associated to the
> window created by your application);
>
> **2)  **Make that rendering context as the current one;
>
> **3)  **Call glGetString(GL_RENDERER, …);
>
> ** **
>
> Steps 1 and 2 are required, since all gl calls need a current rendering
> context to work with.
>
> About steps 1 and 2, you should look at how OSG create the rendering
> context.
>
> ** **
>
> *Da:* osg-users-boun...@lists.openscenegraph.org [
> mailto:osg-users-boun...@lists.openscenegraph.org]
> *Per conto di *Alistair Baxter
> *Inviato:* martedì 15 gennaio 2013 10:47
> *A:* osg-users@lists.openscenegraph.org
> *Oggetto:* [osg-users] GL_RENDERER string
>
> ** **
>
> I’m wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt
> application for debug purposes, and potentially for showing to users for
> technical support purposes.
>
> ** **
>
> I can get the likes of GL and GLSL version from the osg::GL2Extensions
> object, and I can see the renderer string being queries in the source code,
> but I’m having difficulty figuring out how to get it out.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography
• Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS •
Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Modifier key mask not working under OS X

2013-01-15 Thread François Génolini
I have just checked out OpenSceneGraph trunk and built it on my mac.osgversion: 
OpenSceneGraph Library 3.1.4uname -a: Darwin 12.2.0 Darwin Kernel Version 
12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 
x86_64XCode: Version 4.5.2 (4G2008a)
I am trying to get some software working: chapter 2 example from the 
OpenSceneGraph 3 cookbook 
(http://www.packtpub.com/openscenegrap-3-for-advanced-3d-programming-using-api-cookbook/book).In
 this example, I cannot pick the sphere or the cube as long as the code expects 
to seemodifierKeyMask & osgGA::GUIEventAdapter::MODKEY_CTRL
If I remove this condition (any left mouse click allows the method to 
continue), then the software works as designed.
Neither Control (left / right) nor Alt modifiers (left / right) are 
reported.Shift (left / right) and Command (left / right) are reported.Key 
combinations (Shift + Control) are not reported (even though, on its own, Shift 
is reported).
Here is a reference to an old discussion on the mailing list:[osg-users] 
Modifier key mask not working under OS X, by Adrian Egli OpenSceneGraph (3D) 
3dhelp at gmail.com, dated Thu Feb 21 22:23:05 PST 2008
This is either a bug that was never fixed or a regression.
What would be the way forward to address this?
Regards,
François Génolini ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Drawable init method?

2013-01-15 Thread Alexandre Valdetaro
Hummm, now i understand. I really makes perfect sense. I will follow your 
advice and implement the gl objects in a multibuffered way then.

Thanks a lot for the explanation, it really helped.

Cheers,
Alexandre

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51964#51964





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Drawable init method?

2013-01-15 Thread Robert Osfield
Hi Alexandre,

On 15 January 2013 12:47, Alexandre Valdetaro  wrote:
> Sorry about this delay, i did not notice when i looked and the 
> compileGLObjects method that it was also const, which still confuses me.
>
> First of all thanks for the explanation!
> Still, how is one supposed to create any opengl element (VBOs, textures...) 
> to use inside the drawImplementation method when overriding it? I apologize 
> if it is something simple and i am not seeing it, but i havent found an 
> example that has such scenario. If there is one, could someone please point 
> me to it?

The compileGLObjects() and draw/drawImplementation() methods are const
to give a strong hint to the developer that these classes can be run
multi-threaded and should not usually modify local data.  For data
like OpenGL objects one does need to modify it during the draw calls
but these are the exception and have to be multi-buffered with one
element in each buffer used for each graphics context, as each
graphics thread has at most one thread the thread safety is not
compromised as long as the buffers used are pre-allocated to be big
enough to contain all the elements required.

Does this make sense?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Drawable init method?

2013-01-15 Thread Alexandre Valdetaro
Sorry about this delay, i did not notice when i looked and the compileGLObjects 
method that it was also const, which still confuses me.

First of all thanks for the explanation! 
Still, how is one supposed to create any opengl element (VBOs, textures...) to 
use inside the drawImplementation method when overriding it? I apologize if it 
is something simple and i am not seeing it, but i havent found an example that 
has such scenario. If there is one, could someone please point me to it?

Thanks in advance!

Cheers,
Alexandre

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51961#51961





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] “Include can't be =?UTF-8?Q?found=E2=80=9D?=, how to fix it?

2013-01-15 Thread Mohamed Alji
Thank you, it did worked.


Mohamed ALJI
Blog http://aljilogy.blogspot.fr


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51960#51960




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] GL_RENDERER string

2013-01-15 Thread Alistair Baxter
My solution thus far has been to call glGetString in the same function after my 
call to osg::GL2Extensions::Get, since the OpenGL context appears to be valid 
at that time - indeed the glGetString call is made internally by the 
GLExtensions stuff at that time.

It just seems like the renderer string should be exposed by the extensions 
object and it's not.

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Gianluca Natale
Sent: 15 January 2013 10:54
To: OpenSceneGraph Users
Subject: [osg-users] R: GL_RENDERER string

Out of OSG/Qt, I think you should:

1)  Create a very simple rendering context (associated to the window 
created by your application);

2)  Make that rendering context as the current one;

3)  Call glGetString(GL_RENDERER, ...);

Steps 1 and 2 are required, since all gl calls need a current rendering context 
to work with.
About steps 1 and 2, you should look at how OSG create the rendering context.

Da: 
osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Alistair 
Baxter
Inviato: martedì 15 gennaio 2013 10:47
A: osg-users@lists.openscenegraph.org
Oggetto: [osg-users] GL_RENDERER string

I'm wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt 
application for debug purposes, and potentially for showing to users for 
technical support purposes.

I can get the likes of GL and GLSL version from the osg::GL2Extensions object, 
and I can see the renderer string being queries in the source code, but I'm 
having difficulty figuring out how to get it out.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Problems running examples -- x86/x64 confusion?

2013-01-15 Thread Jason Fisher
Hi all,

I'm using MSVS10 SP1 on a Win7 x64 PC and have some issues with getting the 
examples to run. I recently downloaded osg 3.0.1 and created the VS project 
files with CMake, built the osg core for both Debug and Release with Win32 
configuration (Linker command line does include "/MACHINE:X86"). 

When trying to run an example however, it exits with "The program '[11304] 
osgteapot.exe: Native' has exited with code -1073741701 (0xc07b)."

A quick view into dependency walker showed that the exe file is referencing the 
64 bit versions of opengl32.dll, msvcp100.dll, msvcr100.dll and kernel32.dll. 
Also all of the osg dlls are using the 64 bit modules.

I have to say that I'm not into these x86/x64 mixups, for now I always went 
with x86 since it simply worked for me. So I have no idea if what I saw here is 
the actual problem, but it got me alarmed.

If you have an idea about what could be the issue and how to solve it please 
help.

Thanks!

Cheers,
Jason


ithrak (Jason Fisher)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51953#51953





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] R: GL_RENDERER string

2013-01-15 Thread Gianluca Natale
Out of OSG/Qt, I think you should:

1)  Create a very simple rendering context (associated to the window 
created by your application);

2)  Make that rendering context as the current one;

3)  Call glGetString(GL_RENDERER, ...);

Steps 1 and 2 are required, since all gl calls need a current rendering context 
to work with.
About steps 1 and 2, you should look at how OSG create the rendering context.

Da: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Alistair Baxter
Inviato: martedì 15 gennaio 2013 10:47
A: osg-users@lists.openscenegraph.org
Oggetto: [osg-users] GL_RENDERER string

I'm wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt 
application for debug purposes, and potentially for showing to users for 
technical support purposes.

I can get the likes of GL and GLSL version from the osg::GL2Extensions object, 
and I can see the renderer string being queries in the source code, but I'm 
having difficulty figuring out how to get it out.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] GL_RENDERER string

2013-01-15 Thread Alistair Baxter
I'm wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt 
application for debug purposes, and potentially for showing to users for 
technical support purposes.

I can get the likes of GL and GLSL version from the osg::GL2Extensions object, 
and I can see the renderer string being queries in the source code, but I'm 
having difficulty figuring out how to get it out.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org