Creating custom rendering peers

Engines, Libraries and Tools Xith3D Forums
#1

I’ve got a custom rendering engine which does its own OpenGL rendering and its neither LWJGL or JOGL. It can do rendering in a native window, fullscreen, and an OpenGL canvas.

I’m taking a look at the JOGL implementation but as I look at the RenderPeerImpl I see a lot of things that would be very common amongst all of the various native implementations. There appear to be a lot of change vectors at the integration point between the various Atom/Shader peers and the underlying APIs. As such there seems to be a fairly fragile binding at this point. As atoms are changed, fixed, or redefined - it would break all of the native implementations below.

#2

If you speak about implementation of RenderingPeer in Xith3D, then RenderPeerImpl itself is quite simple.

More complicated part is CanvasPeerImpl, but it contains some code that I think should be factored out from it to higher-level abstract class (for ex., canvas identification, cached resources management, some accessor methods) or to helper class/separate atom (drawing floor, shadows, etc.).

Another big part is ShapeAtomPeer, but it is almost nothing to throw out except of some unused methods, and maybe introducing internal helper methods.

If we speak about all OpenGL bindings, then really A LOT of code can be reused if one condition is met: if all of them provide assignment-compatible implementation of GL (i.e. implement the same GL interface), otherwise we will end up different class names anyway. If Java allow plain preprocessor-level includes, then it is easy to solve. I don’t think that it makes sense to introduce own abstraction layer to OpenGL bindings.

What is possible to make more or less abstract is some generic rendering, but, again, it depends on binding.

If atoms/shaders are changed or fixed (which happens really rarely because of they are just containers for information from scenegraph), native implementations have to be fixed anyway, because of they can not guarantee that they render new structures properly.

Majority (really majority) of rendering process is already on the higher abstraction layer - check classes from com.xith3d.render package and you will find there completely binding-independent state management and caching, geometry sorting, atom creation, etc. - everything needed to isolate Scenegraph from OpenGL binding, and I would be happy if we will factor out some common parts of code to share them between different bindings.

We can not say that right now Xith3D has frozen functionality set, so there will be A LOT of changes before we will reach more or less functonally stable version.

Yuri

#3

I just figured out from another thread that you got another OpenGL binding, so is this a question for creating custom rendering peer? Now if I understand you right, you want to implement RenderingPeer that works with your custom binding, right?

Yuri

#4

[quote]I just figured out from another thread that you got another OpenGL binding, so is this a question for creating custom rendering peer? Now if I understand you right, you want to implement RenderingPeer that works with your custom binding, right?

Yuri
[/quote]
That is correct. I have a system that is a more layered approach than the two main bindings. Basically the architecture that I’ve built is:

Xith3D (current working on)

component layer (component rendering and context management)

gli (gl interface)

#5

Hi,

What do you mean by component layer? [just to avoid any kind of misunderstanding]

I personally really interested in more light-weight (and limited) OpenGL binding than JOGL is, and I even have my reduced version of JOGL (which is compatible with basic JOGL from Xith3D point of view).

As of different OpenGL bindings, what we can do is:

  1. manually introduce minimal common GL abstraction - Xith3D uses just small subset of GL commands, so most of them are just irrelevant. Then for every binding we provide delegate implementation.

  2. Make a preprocessor that will construct correct binding code (most of the com.xith3d.render.something package) during the build. This will save us from introducing several more layers between renderer and GL (even those we have already with JOGL are too much I think)

  3. Use aspect-oriented program (i.e. AspectJ in case of Java) to change calls to one API to calls to another API.

  4. Invent something else.

I really see binding level as cut-line between Xith3D and lower-level APIs. Instead of speaking about JOGL, LWJGL, AnotherOneOpenGLBinding, etc., I would say “OpenGL renderer” and “DirectX renderer”, and under OpenGL, I will see JOGL, LWJGL, etc.

As of Context Management, we will have to provide at least minimum implementation which is binding-specific.

Yuri

#6

[quote]Hi,

What do you mean by component layer? [just to avoid any kind of misunderstanding]
[/quote]
No problem. A clean bind to openGL doesn’t create any components, no native peers, etc. Its just a clean JNI wrapping over the OpenGL commands and absolutely nothing else. By itself, GLI does nothing except make OpenGL calls.

The Component Layer sits above this. It makes a call to GLI.init() (which initializes all of the function pointers), creates a subclass of canvas, attached a GLContext to that canvas and handles its context management. THat’s this layer does. By itself it can create a window, fullscreen display, etc. and that’s it.

When both are used in conjunction you have something that creates a component, initializes GLI, makes the context current, calls a bunch of opengl methods in GLI, swaps buffers, and repeats. There is a clean separation between the two and either one can grow independently of the other - though at the moment, GLI is unlikely to change until there are either some more extensions added to OpenGL or GL2.0 ships. On the component front we now have a GLCanvas, an SWT canvas, and a native full screen view. Haven’t gotten the draw to PBuffer stuff correct yet so the swing component is a little funky. Once that’s done - we now have a component that through a Render interface can make calls to OpenGL. I’ll sit Xith3D on top of this and we’ll have our retained mode API, an immediate mode API, and the GL service itself.

In my eyes this adds some additional benefit to the all-in-one solutions in that we can mix and match what we need from a variety of methodologies.

Indeed. If I understand what you’re saying - that’s exactly what we’re doing. When I went through the Xith stuff, the first thing I realized was how little of OpenGL you have to even support in order to get Xith Atoms happily bound to the rendering interface. This is very pleasing :slight_smile: Makes integration pretty straightforward.

#7

Good things will come of this. Hopefully LWJGL and JOGL can share a common GL layer the exact same way. Leave the component management up to them so that JOGL can support AWT, and LWJGL can remain fully custom with primarily fullscreen support, or strictly native windows.

(I can’t believe how much great stuff has come from this community… Xith3D , JOGL, LWJGL, ODE bindings, Input bindings… heck it’s to the point where all you have to do is write the game ;D)

#8

[quote]The Component Layer sits above this. It makes a call to GLI.init() (which initializes all of the function pointers), creates a subclass of canvas, attached a GLContext to that canvas and handles its context management.
[/quote]
Clear. This sometimes referred as GL Context Management.

[quote]When I went through the Xith stuff, the first thing I realized was how little of OpenGL you have to even support in order to get Xith Atoms happily bound to the rendering interface.
[/quote]
That’s true.

As of component layer, in fact there is not so tight connection between JOGL Context Management (GLCanvas in this case) and Xith3D RenderPeerImpl. Most of it (and most important) in RenderPeerImpl (where context is created) and CanvasPeerImpl (in this case, CanvasPeerImpl implements GLDrawable, but this can be factored out into another binding-specific proxy class).

ShaderPeers and AtomPeers refer to GLCanvas, but just to get pointer to GL, so this can be also factored out really easily.

The rest is binding-independent. Only thing I am worrying about is a way of passing array parameters to specific GL binding - Xith3D uses NIO buffers, and if something else should be used, it is way more complicated than just replacing Component Layer.

As of minimalistic binding, you should have in mind that we are adding more functionality and support for different extensions, so if you implement your minimalistic binding right now, you will probably have to add more GL calls to it later (which is in fact trivial).

Yuri

#9

[quote](I can’t believe how much great stuff has come from this community… Xith3D , JOGL, LWJGL, ODE bindings, Input bindings… heck it’s to the point where all you have to do is write the game ;D)
[/quote]
What do we need games when we have great technology?
:wink: Just kidding. Ally your points are very true. :slight_smile:

#10

Just think of it in the same way as DirectX. For YEARS DirectX was terrible and Direct3D was a chore to just use (execute buffers anyone).Then one day the technology got to a point where it was good and stable and people started using it and never looked back.

Its going to take a little time for large numbers of indies take a chance on Java. But as it happens, it will take off. Its just the same cycle all over again.