Setting render loop without using FPSAnimator

Hi All. I am not a Java or JOGL pro and come from other languages .What I see here in most of the demos is that the GLCanvas
is passed to the animator  and the init() method if the main class that implements GLEventListener is triggered only after the animator starts .This pipeline creates some restrictions like that I need to wait for the GL3 context to be made in that method .I tried to call init () explicitly without using animator and the context is invalid .My problem here is that I have a Main.java which doesn't implement GLEventListener but  serves only as an entry point for the app.Then I have another class which does implement GLEventListener  called View3d.So I want to init() the  View3D in the Main.java without using any animator and then just add a render loop like this :

while (true){
   view.render()
}

Currently if I add any GL calls after I start the animator the context is still not created .It seems like even when animator.start() is called  the call to init() of View doesn't happen immediately and any code fallowing the animator.start() is executed  . Is it asynchronous ? Or happens on separate thread ?  I mean in C++ it is synchronous and  procedural and I really have a hard time with all this init process in Java .

Thanks for help.

Hi

Why not using correctly the GLEventListener? Anyway you can't perform OpenGL calls before the context is created. Main.java should only start the animator(s) (or do that in the constructor of View3d.So) and any OpenGL calls should be one in init(GLAutoDrawable) and display(GLAutoDrawable).

You can call GLCanvas.createContext(null) and GLCanvas.display() without using an animator but I'm not sure it is a good idea, you will only do what an animator does but in worse...

Ok ,I see , that looks really restricting .What if I need to use an offscreen rendering ? Will I still be forces to init it all that way ?
I see in LWJGL they encapsulate all the context and window init inside Display class. So why you guys can't have smth similar here ? Imposing Animators for context retrieval I think is a limiting thing to do..


Michael.

Also ,yes , for now I put the Animator into the View3d as well. But that means I am going to add gl calls also inside view and not  in the Main. I don't want the end user do it inside View3d as it is meant to abstract all the init internals .
I want him to call and add calls to view from the Main .Smth like this :

Main() {
View3D view-new View3D()

Object3D cube=new Cube();
cube.setMaterial(new ColorMaterial(0xff0000));
view.addChild(cube);

while(true){
  view.render();
}

}

That is it .I want all the init of context and the rest of JOGL specific done in the View3D .

We don't impose its use. For example, I implemented the support of JOGL 2.0 in Ardor3D and it does not use any animator as far as I know.

We don't encapsulate everything into a Display class because it is a limited approach. Our competitor will have to modify its public API in its third major version to support some things already supported in JOGL 2.0. Therefore, the good choice has been done for JOGL.

Why do you see that as a constraint? When you use an animator, you avoid some problems. When you don't do it, you have to handle these problems by yourself. For example, under some operating systems with weak drivers, you cannot create the context and perform OpenGL calls on different threads, you have to do it on the same one. If you don't use any animator, you will have to take care of the thread(s) you use to do that. I wasted several weeks on a bug caused by this behaviour, it was not reproducible on my computer. Do you imagine how much time a newbie would waste on such a problem?

I don't see what is wrong. We do something similar in Java3D, Xith3D, JMonkeyEngine and Ardor3D. Maybe look at our source code. You need to perform OpenGL calls in each "view" to setup the matrices, the viewport, etc... What is a View3D in your case? Is it just a GLCanvas? Now I see what you mean, you want to avoid putting OpenGL calls everywhere, especially in Main.

Edit.: Don't focus on your loop. Your Main class should work fine without it anyway.

Edit.2: You can use final methods and choose an appropriate visibility to avoid exposing all JOGL calls.

Edit.3: Look at how FrameHandler works in Ardor3D. It allows to do what you're trying to do.

My main reason for not wanting to use Animator or any other FPS keeping /ticking tool is that I need to render a some number of frames as fast as possible.I don't need a game loop . My engine has to render some input graphics to images via fbo.So What I need is ability to manually render an arbitrary number of frames as fast as possible.

Thanks .

Then use Animator instead of FPSAnimator and don't enable v-sync.

On 06/05/2012 09:49 AM, sasmaster [via jogamp] wrote: Julien already hinted the benefits of using the GLEventListener (GLEL) model.
Using it allows you to impl. your own GLEL and attach it to an
GLAutoDrawable (GLAD) implementation like GLCanvas (AWT, SWT)
or GLWindow (NEWT).

Supporting such an easy to use mechanism in JOGL doesn't mean at all
to being forced to use it.

Look at the following unit tests how you can use the lower level
JOGL API to create your own GLDrawable and GLContext instance using NEWT:

+++

NEWT-1:
[1] http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/drawable/TestDrawable01NEWT.java;hb=HEAD#l75

Simple manual creation of NEWT window and creating a GLDrawable/GLContext on top of it
while issuing simple GL commands.

+++

NEWT-2:
[2] http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/util/NEWTGLContext.java;hb=HEAD#l92
[3] http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/glsl/TestRulerNEWT01.java;hb=HEAD#l66

[2] uses [3] to create a NEWT window and creating a GLDrawable/GLContext on top of it.
This example [2] also utilizes GLSL rendering.

+++

It is quite complicated to do the above w/ AWT or SWT
since a lot of 'timing' and information has to be passed.
If you look at the AWT GLCanvas implementation you may understand.

So if you like to have a 'view.render()' thingy here for NEWT and AWT,
I would recommend to simply use a GLAD implementation (see above)
and attach you GLEventListener implementation to it:

  GLCanvas glad = ... ; // or GLWindow glad = .. ;
  ...
  while(true) {
     glad.display();
  }

+++

As Julien mentioned, we don't restrict you of anything in our API,
but sometimes it's just easier to use the so called 'managed path'.

Of course, one can always implement their own GLAutoDrawable
and/or GLAnimatorControl (Animator, FPSAnimator).

[4] http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLAutoDrawable.html

To implement your own GLAnimatorCtrl, don't forget to attach
it to your GLAutoDrawable of your choice.

[5] http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLAutoDrawable.html#setAnimator%28javax.media.opengl.GLAnimatorControl%29

~Sven

> Thanks for help.
>
>
>