Handling events

Engines, Libraries and Tools Xith3D Forums
#1

I am about to create a 3d application using xith3D, and was wondering what is the best approach to handle events.

After Canvas3D is registered to listen for mouse inputs (for example), do people normally have another a class to further manage events associated with entities in the 3d world? So when there is an event, a loop tries to pick and see which entity is associated with it and process the event accordingly?

If a model consists of different parts, how can one ‘listen’ for mouse events on the different parts of the model? I am sorry for the newbie question, but it would be cool if someone could direct me to a good way of dealing with this.

cheers.
Pedro Teixeira

#2

I suggest you download/print the Getting Started Guide PDF, and go though some of the examples.

There are two excellent tutorials on getting AWT mouse events and also on Picking (which is I think what you are after) which Jens has authored. It shows you how to detect “3d scene” events as you call them.

http://xith.org/tutes.php

If you want an example of Picking in action, the one that is explained in the GSG, goto this JWS link:
http://xith.org/jws/jws-org.xith3d.gsg.Picking.jnlp

More fully explained demo’s from the GSG here:
http://xith.org/demo/org.xith3d.gsg.php

Will.

#3

Thanks for the directions! But I’m running into apparently silly problems. I am basically try to find a way where I can deal with mouse and key events, and ‘tell’ the involved objects to act accordinglt. I would appreciate if someone could spot what’s wrong with the following?

I have a main class, with the following methods:

init() {
start rendering peer, canvas3d, universe,…
addMouseListener( eventManager --> which is a class that holds a Vector of events to be dealt with)
call run();
}

run() {
while(true) {
view.renderOnce();
handleEvents();
}
}

handleEvents() {
goes through events in the queue, and process it.
For example, if mouse was released call pick(x,y)
}

pick(x,y) {
try to pick some objects:
PickRenderResult[] results = view.pick(canvas, x, y, 3, 3);

}

The problem is that I get the following:

java.lang.Error: Pick initiated not from rendering thread
        at com.xith3d.render.jogl.CanvasPeerImpl.render(CanvasPeerImpl.java:853)
        at com.xith3d.scenegraph.View.pick(View.java:713)
        at Main.pickDebug(Main.java:125)
        at Main.handleEvents(Main.java:92)
        at Main.run(Main.java:116)
        at Main.init(Main.java:74)
        at Main.main(Main.java:149)

What’s meant by the rendering thread? It’s the thread from where view.renderOnce() is called, right? Can another thread be granted permission to call the View.pick() ?

Is it necessary to have a queue to hold the events? Can’t events be processed straight from the EventListener class? (instead of just setting up some flags)

[All this is very interesting… :)]

#4

Hi,

The problem is somehow strange, your logic seems to be OK. Anyway, check Xith3DSwitchNodeTest.java - it implements exactly this technique [only event queue is one-level and implemented as locak variables with flag], and it works OK.

Also, you should never mix call to View.renderOnce() and View.startView() because of startView() also starts trivial rendering thread.

[quote]What’s meant by the rendering thread? It’s the thread from where view.renderOnce() is called, right?
[/quote]
Yes, correct. But you should take care that only one RenderingThread exists per one JOGL-based CanvasPeer.

[quote]Can another thread be granted permission to call the View.pick() ?
[/quote]
With OpenGL renderer - no. JOGL requires that all the OpenGL calls for given context are made from same thread, and pick(…) uses OpenGL to perform picking operation (GL_SELECT mode).

Yuri

#5

Post the whole source or a simple example here and I’m sure we can help.

#6

The problem indeed was that I was a calling view.startView() in the init method… Thanks for the help!

And… is there any purpose to call this method at all, since it creates a thread and therefore deny us access to openGL calls?

best regards.
Pedro Teixeira

#7

[quote]And… is there any purpose to call this method at all, since it creates a thread and therefore deny us access to openGL calls?
[/quote]
Currently in my opinion it just makes sense for simple examples. For most applications it is better to have control over the rendering thread. (It might make a bit more sense, when Behaviors are implemented.)

#8

I would agree with this. In java3d you didn’t have direct access to the thread but you could still do intermediat or mixed mode rendering, when behaviours go into xith it will be interesting to see how it’s handled :slight_smile:

Endolf.