// NetBeans OpenGL Pack is evolving
The NetBeans OpenGL Pack is slowly evolving to a set of useful integrated tools, demo applications and editors for Java OpenGL development.
The features currently included are:
- Editor for the OpenGL Shading Language (GLSL) with compiler error annotation, code folding, syntax highlighting, auto completion and documentation.
- Easy access to the GLSL compiler and linker of your graphics driver integrated in the editor
- OpenGL Capabilities Viewer
- Integration of JOGL GUI components into the Matisse GUI builder
- JOGL project templates
- Ready to run JOGL demos and examples of the OpenGL Programming Guide (also known as Red Book)
We are currently fixing the last bugs and hope to build the first release soon. The early access version is available via Update Center in the download section of the project page.
------------
The project has also been recently mentioned in the NetBeans Magazine [issue four] covering NetBeans 6 features. Geertjan Wielenga interviewed me about the GLSL editor in the Schliemann section of the magazine.
Hi, thank you very much for your work on the NetBeans OpenGL Pack. Do you have any plan to support 64 bit Windows versions?
Currently, the pack ignores this platform, limiting a bit its usefulness for me (I'm on Vista x64).
Massimiliano
Posted by Massimiliano Bussi on January 13, 2008 at 05:36 PM CET #
Hello Massimiliano,
I am aware of that issue but it is actually not easy to fix (because of several reasons).
JOGL's 32 and 64 bit natives have identical names and can't be deployed in the same folder. Additional to that there is no mechanism to specify the library path of a NetBeans lib wrapper module.
Last but not least, natives are always loaded with VM scope. Which causes version conflicts if you have a different JOGL build in your project (eg in the Matisse GUI Builder preview)
see:
http://www.netbeans.org/issues/show_bug.cgi?id=118951
or a part of the discussion (there is more on the NB dev mailing list):
http://www.javagaming.org/forums/index.php?topic=17220.0
I don't expect a solution from the NetBeans corner. We will probably try to solve that from JOGL's point of view.
This bug has pretty high priority because it causes a lot of problems. But I have currently no time to fix it (-> exams), so you have to be patient (or a volunteer ;) )
Posted by Michael Bien on January 13, 2008 at 08:45 PM CET #
possible workarounds for you:
-run NetBeans with a 32bit JVM
-or copy the 64bit natives into <your home>/.netbeans/6.0/modules/lib/ and the jars into <your home>/.netbeans/6.0/modules/ext/
Posted by Michael Bien on January 13, 2008 at 08:51 PM CET #
Hi Michael, that's exactely what I did (I copied the libs into .netbeans/6.0/modules/lib directory.
If you want, I can help you develop/adapt the module, but since NetBeans module development is something I have never done, you will have to guide me.
Massimiliano
Posted by Massimiliano Bussi on January 14, 2008 at 10:13 PM CET #
Sorry - I have currently no time to guide you how to fix the NetBeans native library loading issue for us.
I will look into it in around 3 weeks
(but thanks)
-michael
Posted by Michael Bien on January 18, 2008 at 08:56 PM CET #
I am getting an error GLException: "Unable to lock surface" when I try to view a JFrame that contains a GLCanvas from the design view of the Netbeans GUI editor. I have read online that this particular exception can occur when a GLCanvas is added to a component before setVisible(true) has been called for the component. I believe this is happening in this case because the netbeans gui editor adds all components to the frame before setVisible(true) is called. I should mention that my program runs fine at runtime. The only problem I am having is with the Design view. I tried calling setVisible(true) before the call to initComponents() but this did not fix the problem with the Design view. Do you have any suggestions on how to fix this problem?
Posted by Russell Bolles on February 15, 2008 at 01:34 AM CET #
Hello Russel,
I never noticed this issue. I am always adding the (GL) components before setting the root component to visible and I also think this could be considered "best practice".
Does the GL capabilities viewer work for you (Tools | OpenGL Capabilities). This tool has been designed with matisse and the component designer and preview worked for me.
https://netbeans-opengl-pack.dev.java.net/source/browse/netbeans-opengl-pack/trunk/gl-capabilities-viewer/src/net/java/nboglpack/glcapabilities/GLCapabilitiesPanel.java?rev=330&view=markup
Posted by Michael Bien on February 15, 2008 at 11:57 PM CET #
Hi Michael,
Installed the pack on linux (gentoo) amd64 platform. GL Capabilities viewer failed and so did SimpleJOGL project.
All issues were fixed when I replaced the native libraries at:
"~/.netbeans/6.0/modules/lib"
"~/.netbeans/6.0/libs/jogl.jar-natives-linux-amd64
"~/.netbeans/6.0/libs/gluegen-rt.jar-natives-linux-amd64
with those from jogl-1.1.1-rc6-linux-amd64.
Suspect that the incorrect native library files have been packaged for linux-amd64.
Andrew.
Posted by Andrew on February 21, 2008 at 05:51 AM CET #
Thank you Andrew for the Heads Up,
this is related to the issue on 64bit systems Massimiliano pointed out earlier. I will look into it soon (and package a new JOGL build). But at least it works for you after updating the native libraries.
thank you for your comment!
Posted by Michael Bien on February 22, 2008 at 04:22 PM CET #
Michael,
I am not sure if this is the right place to post this, so if you can point me in the right direction it would be much appreciated.
Using Netbeans 6.0.1, I can go File > New Project > Simple JOGL Application, and I can compile and run it just fine.
However, if tweak this code, and add some new libraries, those libraries are not found. Output of System.getProperty("java.library.path"):
C:\Documents and Settings\Techport 13 Inc\.netbeans\6.0\jogl-runtime\jogl.jar-natives-windows-i586;C:\Documents and Settings\Techport 13 Inc\.netbeans\6.0\jogl-runtime\gluegen-rt.jar-natives-windows-i586
This is regardless of what I put in the VM Options in the Project properties (-Djava.library.path="C:\windows\system32\" for example).
So, I am interested in knowing how/where the Simple JOGL App modifies the class path, and what I can do about adding my new libraries to it.
Thank you very much,
--- Travis
Posted by Travis on April 12, 2008 at 04:27 AM CEST #
hello Travis,
good question;)
could you please re-send your post to the user mailing list?
https://netbeans-opengl-pack.dev.java.net/servlets/ProjectMailingListList
this is probably a bug. But adding your library path to the run-sys-prop.java.library.path property should workaround the problem.
Its in nbproject/project.properties
thank you for your comment!
Posted by Michael Bien on April 12, 2008 at 04:26 PM CEST #
Are you going to include FreeBSD binaries?
Posted by Monty Hall on August 10, 2009 at 07:10 PM CEST #
you mean FreeBSD binaries for JOGL? I am only packaging up what I get from the JOGL project. You should ask them http://kenai.com/projects/jogl in case the regular linux libs do not work on FreeBSD.
regards,
Posted by Michael Bien on August 10, 2009 at 09:14 PM CEST #
this was helpful
Posted by Alok Kumar on March 02, 2010 at 12:04 PM CET #
Since this post is so old I don't know if Michael will get this but maybe someone knows how the JOGL pack is supposed to work. I'm setting up World Wind in a 64bit Windows 7 environment. When I manually copied the current version JOGL files to the project directory I got it to work. Since I had tried so many different configurations trying to get it to work and I still had a few errors I thought that I would delete everything and recreate it using current clean world wind and JOGL pack installations. After completing this I now receive a runtime error, no jogl found. To test the JOGL installation I tried the Team Kenai CPS project and received the same error. (I'm new to all this so bear with me.) To my understanding the JOGL pack will take care of using/selecting the right library files when building an application but does it not take care of it at runtime? Do I need to specify an option on the command line or specify a directory for the runtime library? I guess I could just copy all the files again to the project root but doesn't that defeat the purpose of how the gluegen-rt is supposed to automatically using the right library files? How do you specify the target platform, maybe that's all I need to do somewhere?
Posted by Joseph Barnes on March 13, 2010 at 07:33 AM CET #
hi Joseph,
sorry for being late, your post has been taged as stam thats why i haven't noticed it.
the NOGL Pack has project templates which should use the right libraries for your system. Just create a new "Simple JOGL Application" project and test it. In java there are two important paths: the library path for native-, system dependent libraries and the classpath for java libraries. Both will be set up automatically for the project.
Posted by Michael Bien on April 01, 2010 at 03:29 PM CEST #