Need help understanding the Peer system

Engines, Libraries and Tools Xith3D Forums
#1

I’ve been trying to figure out how the native peer’ing system works. What I’m trying to do is get the Canvas from the rendering system so that I can put it into a lightweight container. What I need to understand is what these commands actually do so I can get a better understanding of how to get it to do what I want.


            // create a canvas for our graphics
            RenderPeer rp = new RenderPeerImpl();
            CanvasPeer cp = rp.makeCanvas(null, 640, 480, 32, false);
            Canvas3D canvas = new Canvas3D();
            canvas.set3DPeer(cp);

            // modify our view so we can see the cube
            view.addCanvas3D(canvas);


        long time=System.currentTimeMillis();
        while (System.currentTimeMillis()-time<5000)
        {
                view.renderOnce();
        }

Can someone add some light to what exactly is happening here? I would much appreciate it.

#2

Hi,

RenderPeer is a binding-independent abstraction layer which is responsible for creation of binging-specific CanvasPeer and associating binding-specific Shader implementations with cross-binding Shader info containers.

Example [all examples are given for JOGL]:

RenderPeerImpl creates CanvasPeerImpl and associates JOGL-specific PolygonAttrShaderPeer with cross-binding PolygonAttrShader. Cross-binding PolygonAttrShader does nothing except holding polygon attributes for specific rendering state, and does not perform any rendering. PolygonAttrShaderPeer accepts PolygonAttrShader as a parameter to its shade(…) method and performs actual changes of context state using GL API calls provided by JOGL. In short words, PolygonAttrShader holds information about polygon params, and PolygonAttrShaderPeer performs actual manipulation of GL context (say, drawing).

Now coming to CanvasPeer. CanvasPeer is an abstract representation of GL rendering context in Xith3D. CanvasPeerImpl is resopnsible for binging-specific context initialization (for JOGL, it creates GLCanvas), rendering process initialization (setting global GL state parameters) and actual rendering process.

Canvas3D is a connection mechanism between SceneGraph root (View in your example) and actual GL canvas (CanvasPeerImpl). Canvas3D is here primarily for compatibility with Java3D.

When you call View.renderOnce(), this causes traversing scenegraph and preparing multiple Atoms (shapes) and Shaders (shape attributes, aka rendering states), placing them in appropriate rendering pass queues (aggregated as RenderFrame), state sorting and calling display(RenderFrame) of CanvasPeerImpl.

After that, CanvasPeerImpl iterates over atom queues (lists) and draws them by calls to binding-specific AtomPeers and ShaderPeers provided by RenderPeerImpl.

That’s generally all.

If you need more details, let me know.

Yuri

P.S. Once we will need developer docs and explanations on how Xith3D works…

#3

Okay, I will restate what you just said based on my understanding. Please correct me if there is a difference.

RenderPeer doesn’t create a component, but creates something that holds the rendering state/rendering context. It is responsible for updating the state by calling JOGL/LWJGL/etc functions as the scene graph is parsed.

CanvasPeer is the actual Component that will be rendered/painted/etc. It is the ‘native peer’ that the OS will be drawing on when the OpenGL functions are called.

Canvas3D is a component, but only insomuch as it wraps the CanvasPeer and performs pass through calls on the CanvasPeer.

Therefore in Xith/JOGL, when I have a CanvasPeer - I actually have something that is talking to a GLCanvas? Having taken a look at the Canvas3D (which by its definition looks like it more belongs in the render package than the scenegraph package) it appears that its basically providing enough functionality to give the Java windowing system enough information to get to the CanvasPeer and perform operations on it.

While going through the code to CanvasPeerImpl.java for JOGL it also seems to store a log file called opengl.log in c:/ (if you ask for the Option.TRACE). Need to be able to configure this since OSX,Linux, etc don’t have a c:.

#4

[quote]RenderPeer doesn’t create a component, but creates something that holds the rendering state/rendering context.
[/quote]
RenderPeer doesn’t create a GL rendering component, but may create other components needed to create GL component (for example, it may create top-level window if owner is null). [Maybe this concept is wrong, but this is as it is now]

[quote]It is responsible for updating the state by calling JOGL/LWJGL/etc functions as the scene graph is parsed.
[/quote]
No, RenderPeer never updates the OpenGL state, but only creates associations between Shaders and ShaderPeers. ShaderPeers later update OpenGL state.

[quote]CanvasPeer is the actual Component that will be rendered/painted/etc.
[/quote]
CanvasPeer is a Xith3D wrapper for the actual Component that will be rendered/painted/etc. In case of JOGL, CanvasPeer holds a reference to GLCanvas.

[quote]Therefore in Xith/JOGL, when I have a CanvasPeer - I actually have something that is talking to a GLCanvas?
[/quote]
Yes. CanvasPeerImpl holding a reference to GLCanvas.

[quote]Having taken a look at the Canvas3D (which by its definition looks like it more belongs in the render package than the scenegraph package) it appears that its basically providing enough functionality to give the Java windowing system enough information to get to the CanvasPeer and perform operations on it.
[/quote]
Canvas3D is a “glue” between CanvasPeer and View. It connects Rendering Subsystem to Scenegraph. Canvas3D named this way to preserve compatibility with Java3D.

[quote]Need to be able to configure this since OSX,Linux, etc don’t have a c:.
[/quote]
100% true, to be changed.

Yuri

#5

[quote]P.S. Once we will need developer docs and explanations on how Xith3D works…
[/quote]
Sounds good, a summery of this thread could be a good start.

[quote]While going through the code to CanvasPeerImpl.java for JOGL it also seems to store a log file called opengl.log in c:/ (if you ask for the Option.TRACE). Need to be able to configure this since OSX,Linux, etc don’t have a c:.
[/quote]
Agreed - Issue #45 :slight_smile:

Will.

#6

Thanks Yuri… could not have explained it any better!