Thanks for the reply.

I think i've got no other possibility then to trigger the compiled setup method
by the init method when switching to fullscreen to guarantee that the objects
have the right context.(since i've exposed the Jogl API).
I think i choose flexibility over safety (certainly this requires more documentation!).

Hello,

For my project i integrated a Jogl view inside of Eclipse. In an eclipse view i can not trigger a fullscreen mode thats why i
transfer the GLCanvas to a regular Java frame and then switch to the fullscreen mode. Under certain circumstances the application crashed when
i switched to the fullscreen mode. After an inspecton of the source i found out that  the init method is triggered when i switch to the fullscreen mode.
Since i also have an editor where a user can write regular Jogl code and create new objects (e.g. TextRenderer) these new Objects then are on a thread that does not have a current context.

As you can read in the Jogl user guide:

The init() method is called when a new OpenGL context is created for the given GLAutoDrawable. Any display lists or textures used during the application's normal rendering loop can be safely initialized in init(). It is important to note that because the underlying AWT window may be destroyed and recreated while using the same GLCanvas and GLEventListener, the GLEventListener's init() method may be called more than once during the lifetime of the application
...
It is strongly recommended that applications always refetch the GL object out of the GLAutoDrawable upon each call to the init(), display() and reshape() methods and pass the GL object down on the stack to any drawing routines, as opposed to storing the GL in a field and referencing it from there. The reason is that multithreading issues inherent to the AWT toolkit make it difficult to reason about which threads certain operations are occurring on, and if the GL object is stored in a field it is unfortunately too easy to accidentally make OpenGL calls from a thread that does not have a current context. This will usually cause the application to crash. For more information please see the section on multithreading

Without fullscreen everything works fine.

My fullscreen method works if objects are recreated in an available setup method (triggered by the init method) which the user can also create in his custom code
to guarantee that the current context is available. But i would like to avoid the recall of the init method when i create the fullscreen frame (for more safety
!).

My question is, how can i realize this.
Any tips and comments are appreciated.

Thank you for the suggestions.
Any help is always appreciated!

Hello,

I want to have a splitscreen with a small screen in the top right as a kind of preview or custom screen.
A split into 2 or 4 screens is no problem but to draw one screen in the top right is, because the big screen is also
drawn into that area. My question is, if there is a possibility to draw the little screen in the top right without the drawings of the big screen.
Or how can i clear the background in that area and then draw the little screen on it.

Thanks in advance for any help

It took some time for me to understand
the general concepts of Bullet but it works fine
with Jogl, too.

Thanks again for your fast reply.
Again this information is really useful for me

Have a nice sunday

Ok, thank you very much again for your reply!
I think i need some time to examine this and to
produce and track this behaviour again.

If it don't minds you i have also another question regarding the execution
of a method inside the display method .

Since i 've also a setup method in the compiled class (for loading models etc.).
At the moment i trigger this setup method inside the display with a boolean.

triggerSetup=false;// is triggered with a button to true
 ................
...............
public void display(GLAutoDrawable drawable) {
gl = drawable.getGL();
....................
...................
  if(triggerSetup==true){

  setup(GL gl)// execute the setup code

  triggerSetup=false;
  }
}
This is running very well but i didn't
find any information on the internet
if this is one reasonable approach to trigger
a setup method or any other adjustments.

Again any comment about this is always a
help.

First of all thank you both for the fast reply.
I try to explain it more explicitly.

Inside my display method custom code is executed and then also the compiled code
with a timer. The custom code is still wrapped in a try-catch block
public void display(GLAutoDrawable drawable) {
gl = drawable.getGL();
....................
...................
if (custom != null) {
   try {
      custom.main(gl);
      } catch (RuntimeException e) {

       e.printStackTrace();
      }
   }
}

If now an exception occurs in this method how can i avoid
a freezing of the application so that the embedded code
is executed and the timer isn't stopped.
For example if i try to draw a 3d model (which is defective) in my main method
with the gl context .
Is there is an general advice to safely execute code
which is created for examply by another user which creates some custom code
with the gl context.

By the way the application does not crash. Only
the view freezes and the timer stops.

Hello,

at the moment i'm developing a simple jogl famework for my application
which has a java editor embedded.
The java code in my application can be compiled dynamically to a class.
In this class you can create a main method which makes the GL context available.

main(GL gl){
......
......

}
This main method then if it is compiled is called from the regular display method
inside the application and works fine so far.
The problem is that the display freezes if a failure occurs in the main method.
My question is how can i make the execution of the main method more stable to prevent that the 3d display freezes.

Any help or suggestion is appreciated

Thank you all for the suggestions.
I really appreciated your help!

Looks nice emzic

But I have to generate the terrain from real data.
I guess you've used triangles instead of quads for the height map, right?
I would be also interested in to hear how  you've realized the smoothing of the data.

That sounds really good.

But maybe you can help me a little bit with an example to start.

If i have constructed a world (extended to 1000 units) with a plane in my OpenGL display method how can i create
gravity for the world and a sphere which is affected by this gravity settings falling on a plane in this world:

(assuming a constant frame rate)

display(GLAutoDrawable drawable){
gl = drawable.getGL();
........
gl.drawSphere();
.....
gl.drawPlane();

}

Any help or a code snippet is really appreciated!

Thanks for the suggestions.
I will have a look at it.

Dear jogl developers,

at the moment i develop a jogl application which is using a height map with quads.
For the height map i calculated the normals which looks faceted when i use the specular lightening.
I smoothed this a bit by calculating the averaged sum of the adjacent normals for each quad.
This looks much more better but maybe there is a better method available to make the quads look much more
less faceted.

Any help or suggestion is appreciated

Hello jezek,

i know Bullet from Blender and it is fantastic to hear that you ported this library to java.
For me it would be very interesting to hear if i could use jBullet also in Jogl.
If this is possible could you please post an example how to realize this.

Anyway, keep on with this good work and thank you for making this public available!

With kind regards
Marcel