Re: [osg-users] OSG Viewer and JOGL

2010-02-08 Thread Allen Saucier
Hi Rafa.  I just found this article in the OSG Forums and am very interested in 
osgvp.

Is there a tutorial on osgvp?  And if so, would you tell me where?  I've 
downloaded the snapshot for all platforms and am compiling the projet with 
maven.

I just need a good tutorial as to how to use this product.  I really really 
like the fact that it can possibly load my dted and cib terrain data on the fly 
w/o having to pre-generate this data specifically for osg.

Thanks so much Rafa.



Rafa Gaitan wrote:
 Hi Kevin,
 
 Well osgvp is quite large currently, but you can take a look to
 libosgvp-viewer library and take only what you need. If you feel
 comfortable with maven, you can try to compile it and use only
 libosgvp-viewer and libosgvp-core library. Currently trunk compiles
 against osg 2.8.2, but you can use a trick to compile it against osg
 trunk just setting the OSG_DIR env var pointing to the osg compiled
 sdk.
 
 This two libraries allow to create the context using jogl with the
 first method that Robert commented. You can take libosgvp-viewer and
 use it and even with a few mods I think you can use without all the
 libosgvp-core wrappers.
 
 The JNI code is inside osgvp/libosgvp/libjni-osgvp/, so you can take a
 look there and use the code you need.
 
 Good luck with  your project,
 Rafa.
 
 
 On Wed, Jan 6, 2010 at 7:05 PM, Robert Osfield  wrote:
 
  Hi Kevin,
  
  I know nothing about Java/JNI so can't comment on the specifics, but
  in general I'd suggest that you could use the
  osgViewer::GraphicsWindowEmbedded functionality that enables the
  standard osgViewer::Viewer/CompositeViewer to handle a single window
  without doing any of its own windows/wgl/glx calls - leaving these
  entirely up to the calling application.  For examples of this in
  action have a look at the osgviewerSDL and osgviewerGLUT examples that
  come as part of the OSG's example set.  Such a embedded window is fine
  for most apps that just require a single window and single threading
  of the viewer, but isn't a scalable as the native OSG windowing
  implementations.
  
  Another route might be to try and get the underlying window handle of
  a window created by java and then pass this to
  osgViewer::GraphicsWindowWin32/X11 using it's support for inheriting
  windows and adding it's own graphics context.  This approach is the
  most flexible w.r.t the OSG as it enables the OSG to handle threading
  and multiple graphics contexts directly.
  
  Robert.
  
  On Wed, Jan 6, 2010 at 5:05 PM, Kevin Tacke  wrote:
  
   We currently have an application that is built around the OSG Viewer 
   using a glut window.  We are interesting in adding a considerable GUI 
   interface to the application and we would prefer to use JAVA to implement 
   the GUI.  So basically I am trying to find a way, probably using JOGL, to 
   create the GUI and graphics window on the JAVA side and perform all of 
   the drawing on the C++/OSG side.
   
   I think I should be able to create a glContext on the JAVA size, with 
   JOGL, and when making a call to C++ with JNI have access to the same 
   context as long as it is done within the same thread.  Unfortunately, I 
   have not figured out how to assign the JAVA created glContex, retrieved 
   with a call to wglGetCurrentContext, to the OSG Viewer/Camera.
   
   I know that osgvp has created a JAVA/JOGL/JNI interface to OSG but it 
   looks like a lot of effort went into creating the JNI interface and 
   making calls into OSG.  I would really like to reduce the JNI to little 
   more than init, display, keyboard, and mouse functions.
   
   Any help is appreciated.
   
   Thanks,
   Kevin
   
   --
   Read this topic online here:
   http://forum.openscenegraph.org/viewtopic.php?p=22166#22166
   
   
   
   
   
   ___
   osg-users mailing list
   
   http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
   
   
  ___
  osg-users mailing list
  
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
 
 
 
 -- 
 Rafael Gaitán Linares
 Instituto de Automática e Informática Industrial  http://www.ai2.upv.es
 Ciudad Politécnica de la Innovación
 Universidad Politécnica de Valencia
 ___
 osg-users mailing list
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
  --
 Post generated by Mail2Forum


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





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


[osg-users] OSG Viewer and JOGL

2010-01-06 Thread Kevin Tacke
We currently have an application that is built around the OSG Viewer using a 
glut window.  We are interesting in adding a considerable GUI interface to the 
application and we would prefer to use JAVA to implement the GUI.  So basically 
I am trying to find a way, probably using JOGL, to create the GUI and graphics 
window on the JAVA side and perform all of the drawing on the C++/OSG side.

I think I should be able to create a glContext on the JAVA size, with JOGL, and 
when making a call to C++ with JNI have access to the same context as long as 
it is done within the same thread.  Unfortunately, I have not figured out how 
to assign the JAVA created glContex, retrieved with a call to 
wglGetCurrentContext, to the OSG Viewer/Camera.  

I know that osgvp has created a JAVA/JOGL/JNI interface to OSG but it looks 
like a lot of effort went into creating the JNI interface and making calls into 
OSG.  I would really like to reduce the JNI to little more than init, display, 
keyboard, and mouse functions.

Any help is appreciated.

Thanks,
Kevin

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





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


Re: [osg-users] OSG Viewer and JOGL

2010-01-06 Thread Robert Osfield
Hi Kevin,

I know nothing about Java/JNI so can't comment on the specifics, but
in general I'd suggest that you could use the
osgViewer::GraphicsWindowEmbedded functionality that enables the
standard osgViewer::Viewer/CompositeViewer to handle a single window
without doing any of its own windows/wgl/glx calls - leaving these
entirely up to the calling application.  For examples of this in
action have a look at the osgviewerSDL and osgviewerGLUT examples that
come as part of the OSG's example set.  Such a embedded window is fine
for most apps that just require a single window and single threading
of the viewer, but isn't a scalable as the native OSG windowing
implementations.

Another route might be to try and get the underlying window handle of
a window created by java and then pass this to
osgViewer::GraphicsWindowWin32/X11 using it's support for inheriting
windows and adding it's own graphics context.  This approach is the
most flexible w.r.t the OSG as it enables the OSG to handle threading
and multiple graphics contexts directly.

Robert.

On Wed, Jan 6, 2010 at 5:05 PM, Kevin Tacke kta...@gmail.com wrote:
 We currently have an application that is built around the OSG Viewer using a 
 glut window.  We are interesting in adding a considerable GUI interface to 
 the application and we would prefer to use JAVA to implement the GUI.  So 
 basically I am trying to find a way, probably using JOGL, to create the GUI 
 and graphics window on the JAVA side and perform all of the drawing on the 
 C++/OSG side.

 I think I should be able to create a glContext on the JAVA size, with JOGL, 
 and when making a call to C++ with JNI have access to the same context as 
 long as it is done within the same thread.  Unfortunately, I have not figured 
 out how to assign the JAVA created glContex, retrieved with a call to 
 wglGetCurrentContext, to the OSG Viewer/Camera.

 I know that osgvp has created a JAVA/JOGL/JNI interface to OSG but it looks 
 like a lot of effort went into creating the JNI interface and making calls 
 into OSG.  I would really like to reduce the JNI to little more than init, 
 display, keyboard, and mouse functions.

 Any help is appreciated.

 Thanks,
 Kevin

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





 ___
 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 Viewer and JOGL

2010-01-06 Thread Rafa Gaitan
Hi Kevin,

Well osgvp is quite large currently, but you can take a look to
libosgvp-viewer library and take only what you need. If you feel
comfortable with maven, you can try to compile it and use only
libosgvp-viewer and libosgvp-core library. Currently trunk compiles
against osg 2.8.2, but you can use a trick to compile it against osg
trunk just setting the OSG_DIR env var pointing to the osg compiled
sdk.

This two libraries allow to create the context using jogl with the
first method that Robert commented. You can take libosgvp-viewer and
use it and even with a few mods I think you can use without all the
libosgvp-core wrappers.

The JNI code is inside osgvp/libosgvp/libjni-osgvp/, so you can take a
look there and use the code you need.

Good luck with  your project,
Rafa.


On Wed, Jan 6, 2010 at 7:05 PM, Robert Osfield robert.osfi...@gmail.com wrote:
 Hi Kevin,

 I know nothing about Java/JNI so can't comment on the specifics, but
 in general I'd suggest that you could use the
 osgViewer::GraphicsWindowEmbedded functionality that enables the
 standard osgViewer::Viewer/CompositeViewer to handle a single window
 without doing any of its own windows/wgl/glx calls - leaving these
 entirely up to the calling application.  For examples of this in
 action have a look at the osgviewerSDL and osgviewerGLUT examples that
 come as part of the OSG's example set.  Such a embedded window is fine
 for most apps that just require a single window and single threading
 of the viewer, but isn't a scalable as the native OSG windowing
 implementations.

 Another route might be to try and get the underlying window handle of
 a window created by java and then pass this to
 osgViewer::GraphicsWindowWin32/X11 using it's support for inheriting
 windows and adding it's own graphics context.  This approach is the
 most flexible w.r.t the OSG as it enables the OSG to handle threading
 and multiple graphics contexts directly.

 Robert.

 On Wed, Jan 6, 2010 at 5:05 PM, Kevin Tacke kta...@gmail.com wrote:
 We currently have an application that is built around the OSG Viewer using a 
 glut window.  We are interesting in adding a considerable GUI interface to 
 the application and we would prefer to use JAVA to implement the GUI.  So 
 basically I am trying to find a way, probably using JOGL, to create the GUI 
 and graphics window on the JAVA side and perform all of the drawing on the 
 C++/OSG side.

 I think I should be able to create a glContext on the JAVA size, with JOGL, 
 and when making a call to C++ with JNI have access to the same context as 
 long as it is done within the same thread.  Unfortunately, I have not 
 figured out how to assign the JAVA created glContex, retrieved with a call 
 to wglGetCurrentContext, to the OSG Viewer/Camera.

 I know that osgvp has created a JAVA/JOGL/JNI interface to OSG but it looks 
 like a lot of effort went into creating the JNI interface and making calls 
 into OSG.  I would really like to reduce the JNI to little more than init, 
 display, keyboard, and mouse functions.

 Any help is appreciated.

 Thanks,
 Kevin

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





 ___
 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




-- 
Rafael Gaitán Linares
Instituto de Automática e Informática Industrial  http://www.ai2.upv.es
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OSG Viewer and JOGL

2010-01-06 Thread Gerrick Bivins
Hi Rafa,

How much of the OSG is exposed through osgvp?
Is it possible to extract out the wrapping into a separate project? I've
been looking into how I can use maven and jna to possibly get access to OSG
from java but I'm just beginning. If the work is already done or you have
some tips/pointers on how to get going that would be great.
Gerrick

On Wed, Jan 6, 2010 at 2:43 PM, Rafa Gaitan rafa.gai...@gmail.com wrote:

 Hi Kevin,

 Well osgvp is quite large currently, but you can take a look to
 libosgvp-viewer library and take only what you need. If you feel
 comfortable with maven, you can try to compile it and use only
 libosgvp-viewer and libosgvp-core library. Currently trunk compiles
 against osg 2.8.2, but you can use a trick to compile it against osg
 trunk just setting the OSG_DIR env var pointing to the osg compiled
 sdk.

 This two libraries allow to create the context using jogl with the
 first method that Robert commented. You can take libosgvp-viewer and
 use it and even with a few mods I think you can use without all the
 libosgvp-core wrappers.

 The JNI code is inside osgvp/libosgvp/libjni-osgvp/, so you can take a
 look there and use the code you need.

 Good luck with  your project,
 Rafa.


 On Wed, Jan 6, 2010 at 7:05 PM, Robert Osfield robert.osfi...@gmail.com
 wrote:
  Hi Kevin,
 
  I know nothing about Java/JNI so can't comment on the specifics, but
  in general I'd suggest that you could use the
  osgViewer::GraphicsWindowEmbedded functionality that enables the
  standard osgViewer::Viewer/CompositeViewer to handle a single window
  without doing any of its own windows/wgl/glx calls - leaving these
  entirely up to the calling application.  For examples of this in
  action have a look at the osgviewerSDL and osgviewerGLUT examples that
  come as part of the OSG's example set.  Such a embedded window is fine
  for most apps that just require a single window and single threading
  of the viewer, but isn't a scalable as the native OSG windowing
  implementations.
 
  Another route might be to try and get the underlying window handle of
  a window created by java and then pass this to
  osgViewer::GraphicsWindowWin32/X11 using it's support for inheriting
  windows and adding it's own graphics context.  This approach is the
  most flexible w.r.t the OSG as it enables the OSG to handle threading
  and multiple graphics contexts directly.
 
  Robert.
 
  On Wed, Jan 6, 2010 at 5:05 PM, Kevin Tacke kta...@gmail.com wrote:
  We currently have an application that is built around the OSG Viewer
 using a glut window.  We are interesting in adding a considerable GUI
 interface to the application and we would prefer to use JAVA to implement
 the GUI.  So basically I am trying to find a way, probably using JOGL, to
 create the GUI and graphics window on the JAVA side and perform all of the
 drawing on the C++/OSG side.
 
  I think I should be able to create a glContext on the JAVA size, with
 JOGL, and when making a call to C++ with JNI have access to the same context
 as long as it is done within the same thread.  Unfortunately, I have not
 figured out how to assign the JAVA created glContex, retrieved with a call
 to wglGetCurrentContext, to the OSG Viewer/Camera.
 
  I know that osgvp has created a JAVA/JOGL/JNI interface to OSG but it
 looks like a lot of effort went into creating the JNI interface and making
 calls into OSG.  I would really like to reduce the JNI to little more than
 init, display, keyboard, and mouse functions.
 
  Any help is appreciated.
 
  Thanks,
  Kevin
 
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=22166#22166
 
 
 
 
 
  ___
  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
 



 --
 Rafael Gaitán Linares
 Instituto de Automática e Informática Industrial  http://www.ai2.upv.es
 Ciudad Politécnica de la Innovación
 Universidad Politécnica de Valencia
 ___
 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 Viewer and JOGL

2010-01-06 Thread Rafa Gaitan
Hi Gerrick,

On Wed, Jan 6, 2010 at 9:51 PM, Gerrick Bivins
gbiv...@objectreservoir.com wrote:
 Hi Rafa,
 How much of the OSG is exposed through osgvp?

Well, in libosgvp-core is a one-to-one (more or less) wrapp for the
most common nodes and functionalities of OSG. libosgvp-viewer has the
logic to manage the render contexts in java and also integrates some
manipulators. The other libraries are mainly for GIS development
inside gvSIG3D.

 Is it possible to extract out the wrapping into a separate project? I've
 been looking into how I can use maven and jna to possibly get access to OSG
 from java but I'm just beginning. If the work is already done or you have
 some tips/pointers on how to get going that would be great.
 Gerrick

Are you trying to do a complete wrapp? or only the basics? We began
with a simple wrapp covering our first milestones and we never
finished growing :). Our goal was a GIS 3D framework for Java using
OSG, but we tried to separate libraries/functionalities with a little
coherence :).

It is possible to use only libosgvp-viewer and libosgvp-core
independently. All the C/C++ JNI source is in a single CMake project
which generates different dynamic libraries (normal dynamic libraries
and jni ones). I think separate only the java OSG part is really easy.
Even use it directly if you decide use maven too in your project
(maven is really a good choice if you work in java).

In this project and also in gvSIG I had to solve the problem of
compile/deploy of native libraries with maven. It is possible to
compile all the source using maven (with cmake accesible). Maven
downloads the native dependencies in a tar.gz and jar dependencies for
the current platform, and is able to use them to compile the sources
with CMake. Once compiled you can point to the necessary dependencies
with maven in your project.

Tomorrow I want to release a new build of gvSIG3D, and of course I
also want to deploy osgvp in the maven repository, so use it is only
add the repo to your pom.xml (maven) file and the dependencies. I will
also upload a ready to use package of osgvp to the web. If you want to
check some code, take a look to libosgvp-examples (trunk version)
there is examples grouped by library, if you take a look to viewer
examples maybe you can get an idea of how use osgvp for a minimal
scene graph in Java.

Cheers,
Rafa.


 On Wed, Jan 6, 2010 at 2:43 PM, Rafa Gaitan rafa.gai...@gmail.com wrote:

 Hi Kevin,

 Well osgvp is quite large currently, but you can take a look to
 libosgvp-viewer library and take only what you need. If you feel
 comfortable with maven, you can try to compile it and use only
 libosgvp-viewer and libosgvp-core library. Currently trunk compiles
 against osg 2.8.2, but you can use a trick to compile it against osg
 trunk just setting the OSG_DIR env var pointing to the osg compiled
 sdk.

 This two libraries allow to create the context using jogl with the
 first method that Robert commented. You can take libosgvp-viewer and
 use it and even with a few mods I think you can use without all the
 libosgvp-core wrappers.

 The JNI code is inside osgvp/libosgvp/libjni-osgvp/, so you can take a
 look there and use the code you need.

 Good luck with  your project,
 Rafa.


 On Wed, Jan 6, 2010 at 7:05 PM, Robert Osfield robert.osfi...@gmail.com
 wrote:
  Hi Kevin,
 
  I know nothing about Java/JNI so can't comment on the specifics, but
  in general I'd suggest that you could use the
  osgViewer::GraphicsWindowEmbedded functionality that enables the
  standard osgViewer::Viewer/CompositeViewer to handle a single window
  without doing any of its own windows/wgl/glx calls - leaving these
  entirely up to the calling application.  For examples of this in
  action have a look at the osgviewerSDL and osgviewerGLUT examples that
  come as part of the OSG's example set.  Such a embedded window is fine
  for most apps that just require a single window and single threading
  of the viewer, but isn't a scalable as the native OSG windowing
  implementations.
 
  Another route might be to try and get the underlying window handle of
  a window created by java and then pass this to
  osgViewer::GraphicsWindowWin32/X11 using it's support for inheriting
  windows and adding it's own graphics context.  This approach is the
  most flexible w.r.t the OSG as it enables the OSG to handle threading
  and multiple graphics contexts directly.
 
  Robert.
 
  On Wed, Jan 6, 2010 at 5:05 PM, Kevin Tacke kta...@gmail.com wrote:
  We currently have an application that is built around the OSG Viewer
  using a glut window.  We are interesting in adding a considerable GUI
  interface to the application and we would prefer to use JAVA to implement
  the GUI.  So basically I am trying to find a way, probably using JOGL, to
  create the GUI and graphics window on the JAVA side and perform all of the
  drawing on the C++/OSG side.
 
  I think I should be able to create a glContext on the JAVA size, with
  JOGL, and when making a