A feature that might be useful for many people could be the possibility to perform custom rendering inside a SwoglContainer. This would allow to render an environment consisting of arbitrary objects, and augment this environment with SwoglComponents.
A straightforward approach might be to define an interface
interface CustomRenderer
{
void render(GL gl)
}
Instances implementing this interface could then be added to or removed from a SwoglContainer, which maintains them in a List. The SwoglContainer could simply call the ‘render’ method of all CustomRenderer instances at the end of its ‘display’ method, passing in the current GL context.
I’d like to hear any comments and thoughts about this approach. Possibly, a more sophisticated solution could be required to support things like picking or other features?
As Markus pointed out in http://forum.byte-welt.de/showthread.php?t=2392 , the initialization should also be more customizable concerning aspects like DebugGL, Antialiasing or Light settings.
In general, for own, specific configurations, there is always the option of inheriting from SwoglContainer and overwriting the corresponing methods, but of course there should be as much flexibility on the API level as possible. Currently, only the light setup may be configured manually, but the API for that is VERY preliminary.
In general, for custom initialization and rendering, some “callbacks” like the CustomRenderer interface (mentioned above) could be used. Further (and more detailed) suggestions concerning an API for this are welcome.
The requirements for custom rendering and initialization basically show up (exactly?) in the methods that are summarized in the GLEventListener interface:
void init(GLAutoDrawable drawable)
void display(GLAutoDrawable drawable)
void reshape(GLAutoDrawable drawable, int x, int y, int width, int height)
void displayChanged(GLAutoDrawable drawable, boolean modeChanged, boolean deviceChanged)
One option could be to allow the user to simply pass in implementations of the GLEventListener interface, which perform the custom steps, and the SwoglContainer calls them in the appropriate places.
This would also allow an IMHO rather elegant way of configuring things like camera- picking- and light setup: The init- and display-Methods, which currently perform some rather specific things, could then consist of a simple sequence of calls like
This first and the last method would simply call the “display” methods of a list of registered GLEventListeners, where (by default) one GLEventListener does the camera setup, one GLEventListener does the light setup, and optional custom rendering steps could be performed in further GLEventListeners which had been registered by the user.
Some feedback concerning this idea would be interesting.
Again, I feel the tendency to generalize things as far as possible, being tempted to create an API which allows very much control, but may possibly be easily misused.
Concerning the custom behavior (mainly initialization and rendering), I’m currently at the state where I consider the follwing: The SwoglContainer provides the necessary things for Swogl (like SwoglComponent handling and MouseEvent handling). Beyond this, it only implements the GLEventListener interface, and maintains one (or several specific) Lists of further GLEventListeners. In the GLEventListener methods mentioned above, it simply calls the respective method of all GLEventListeners in the List.
In this case, the behavior could completely be controlled by the attached GLEventListener implementations - and virtually everything would be a GLEventListener: There are several inner classes which are used for the “default things”. For example, there is an inner class that and simply applies the current camera in its ‘display’ method. Another implementation updates the Picker (for Picking SwoglComponents). And yes, there is one implementation that actually renders the SwoglComponents. Thus, the “default behavior” of the SwoglContainer may be achieved by initializing the List of GLEventListeners with something like
People might override the method that initializes this list, leave out the second line, and obtain a SwoglContainer that does not allow Picking, or add a line with a GLEventListener that performs custom rendering.
This would be very flexible, but of course there are implicit “contstraints” (e.g. the Picker must be updated after the Camera has been applied), which could hardly be documented in detail.
I’m still thinking about this and experimenting a little bit, but feedback would be very welcome.