Make sure you force a repaint on your canvas after the buffer update, like this:


moveObjects();
moveCamera();

buffer.clear();
theWorld.renderScene(buffer);
buffer.update();

glCanvas.repaint();


This topic has been discussed here:
http://www.jpct.net/forum2/index.php/topic,388.0.html

Quote from: qjvictor1. it only records the screen, I need back-end generating the movie

Why? What will the "back-end" visually contain which is not also being displayed on the screen?

Quote from: qjvictor2. it seems that no compression for the movie, I am not sure about this

That is correct, there is no compression for the movie and the really good reason is that there is no time to encode the movie while recording at 30+ FPS. This will cause a significant performance hit. There is a way to post-process the movie and compress it with other tools however. Here is the full FAQ from the fraps site.

QuoteWhy is the AVI movie generated by Fraps so big? How can I reduce the size?

The filesize is big because there isn't enough time to encode the movie while the game is running. The movie frames are slightly compressed, but still require a large amount of disk space due to the high resolutions. Once you have finished capturing you should convert the saved AVI into one of the popular compressed movie formats such as mpeg or divx. Recommended programs for doing this are tmpgenc (Tsunami Mpeg Encoder), and VirtualDub.

Using VirtualDub is quite easy. To create a compressed version of the AVI follow these steps:

    * Start VirtualDub
    * Select File->Open and choose the AVI in the Fraps directory you wish to compress.
    * Select Video->Compression and choose the codec you wish to compress with (usually divx)
    * Select File->Save As AVI and specify a filename for the new AVI.

If you have Windows XP you can also use Windows Movie Maker to compress the video files. If you use Windows Movie Maker it's recommended that you keep your Fraps video files at 800x600 or under.

Quote from: manumoiDoes anyone knows a good tool for obtaining decent movie capture from the whole screen (i.e. not only the open GL part of it)

This is a good one that I've used many times:
http://www.techsmith.com/camtasia.asp

http://www.fraps.com/

This is a good tool for recording video (also does audio!) from any game. Should work with jPCT as well but I haven't personally tried.

QuoteFraps is a universal Windows application that can be used with games using DirectX or OpenGL graphic technology

Quote from: EgonOlsen
At that time, Java3D was the fastest, jME came behind it and Xith was the slowest by far (so much for tuned Java3D...).

Quote from: EgonOlsen
However, all engines have evolved since then, including jPCT. So this test may be no longer valid...

Correct, it is no longer valid. I believe I know which comparison you're talking about. It's over at the jME forum. That discussion has greatly evolved since you last checked. It's now clear that jME is the fastest engine: http://www.jmonkeyengine.com/jmeforum/index.php?topic=2597.75

Quote from: EgonOlsen
jPCT does a lot of things in software while the other engines can do this hardware

So would it be safe to say that the software processing of jPCT hinders its performance? I do understand that this is a trade-off for a more dev-friendly API but nevertheless it still sounds like a sort of performance bottleneck.

Quote from: EgonOlsen
You can add and remove stages from single polygons at runtime. If you want to add 20 texture layers to a single polygon if something has hit the polygon, you can easily do it. You can't do that in any other engine.

From what I'm understanding here, jPCT's biggest strengths are in the texture management system? Please correct me if I'm wrong, I'd really like to understand this.

Quote from: EgonOlsen
you can use the normal GLRenderer as well as the AWTGLRenderer in the same way

Yes, this is definitely a BIG PLUS! 

Quote from: EgonOlsen
You don't have to care about threads or put every jPCT related command into a gameloop-construction like you've to do in jME

I'm not so sure about this, I've had some glitchy behavior if any objects in my scene were handled (i.e. manipulated) outside the main jPCT game loop.

I was just wondering if jPCT has ever been benchmarked against some of the other java scenegraph engines out there: jME, Java3D, Xith3D, etc. I've personally been working with jPCT for almost 2 years now and have never really considered performance vs. the "competition". So I thought this would something useful to consider.

Besides the fact that jPCT is probably the easiest to learn and supports both software/hardware rendering, are there any other advantages? I've read that Xith3D is a tuned version of Java3D basically aimed at higher performances, and jME was actually benchmarked against Xith3D and found to be faster in some cases. So jME seems to be a clear winner in terms of performance. However I've never seen jPCT benchmarked at all.

Another interesting fact   

I just discovered that wireframe rendering:
World.drawWireframe(FrameBuffer, Color)
has a higher framerate in software mode! 

Any ideas for this one? 

QuoteThe main difference between GLRenderer and SoftwareRenderer on the one and the AWTGLRenderer on the other hand is, that the latter one is multi-threaded...it has to be, because drawing has to happen in the AWT-Event-Thread but normal jPCT operations do not

Isn't the AWT thread also needed for software rendering? If so, this would also be multi-threaded since both AWT and jPCT threads need to run.

Quoteit seems to be a dual core/cpu setup or otherwise all renderers would use close to 100% cpu

I actually have an Intel P4 with HT (hyperthreading) so I guess it gives similar results to the dual-core.

QuoteIf you want to throttle cpu usage, use a sleep (as you've already done). The engine itself will try to pump out data as fast as it can, which will always lead to 100% cpu usage

So that means I've "throttled" the jPCT thread which was the most CPU intensive thread of all, correct? If so, how could the overall CPU usage drop to <1% in AWTGLRenderer mode if the AWT thread is still doing all the painting (hasn't been "throttled")? I'm just not understanding such a low CPU usage with that very short (20 milli) sleep...

UPDATE

I've applied a 20 milli-sec sleep to my game loop, and the results are very interesting!

In both software and hardware rendering the FPS dropped (obviously), but the CPU usage results were a little unexpected; the software rendering dropped from 50% CPU to ~20% and the AWTGLRenderer dropped from ~85% to <1% !!! I'd be very interested in knowing why since this doesn't make sense to me anymore

Here are the results from the benchmark tests:

mt_opengl.bat
Frames rendered: 13171
FPS: 177.30
CPU (usage) : 80%-90%

st_software.bat
Frames rendered: 2100
FPS: 28.25
CPU (usage) : 50%

st_opengl.bat
Frames rendered: 11336
FPS: 152.60
CPU (usage) : 50%

It seems that these results are perfectly matched to the results I'm getting with my test bed as well. In all cases, the hardware renderer produces a better framerate, but it seems that the AWTGLRenderer is more CPU intensive than the software renderer 

QuoteHave you disabled the software renderer in addition to enable the canvas one?

Yes, I have. I'm using a modified version of your "CarTest" program. Here is the "switchOtions()" method:


    private void switchOptions()
    {
        switch (switchMode)
        {
            case (SWITCH_RENDERER):
            {
                isIdle = true;
                if (buffer.usesRenderer(IRenderer.RENDERER_OPENGL))
                {
                    keyMapper.destroy();
                    mouseMapper.destroy();
                    keyMapper = new KeyMapper(awtCanvas);
                    mouseMapper = new MouseMapper(awtCanvas);
                    frame.setVisible(false);
                    frame.setTitle(FRAME_TITLE + SOFTWARE_MODE);
                    frame.removeAll();
                    frame.add(awtCanvas);
                    frame.validate();
                    buffer.disableRenderer(IRenderer.RENDERER_OPENGL);
                    buffer.enableRenderer(IRenderer.RENDERER_SOFTWARE,
                            IRenderer.MODE_OPENGL);
                    openGL = false;
                    frame.setVisible(true);
                    gFrame = awtCanvas.getGraphics();
                }
                else
                {
                    keyMapper.destroy();
                    mouseMapper.destroy();
                    frame.setVisible(false);
                    frame.setTitle(FRAME_TITLE + HARDWARE_MODE);
                    frame.removeAll();
                    buffer.disableRenderer(IRenderer.RENDERER_SOFTWARE);
                    Canvas canvas = buffer.enableGLCanvasRenderer(IRenderer.MODE_OPENGL);
                    keyMapper = new KeyMapper(canvas);
                    mouseMapper = new MouseMapper(canvas);
                    frame.add(canvas);
                    frame.validate();
                    frame.setVisible(true);
                    openGL = true;
                }
                isIdle = false;
                break;
            }
        }
        switchMode = 0;
    }


Just a quick question about the performance of renderers. In general, should FrameBuffer.enableGLCanvasRenderer(IRenderer.MODE_OPENGL)

have better performance (lower CPU usage) than FrameBuffer.enableRenderer(IRenderer.RENDERER_SOFTWARE, IRenderer.MODE_OPENGL)
Although the first one is hardware rendering, I'm getting poorer performance out of it. I'm not quite sure why.

I just found the API. It's in org.lwjgl.opengl.Display

public static void setTitle(java.lang.String newTitle);
public static int setIcon(java.nio.ByteBuffer[] icons);


Now all I need to find out is how to get a ByteBuffer out of an Image 

I'm trying to find a way to access the native window that gets created with the FrameBuffer.displayGLOnly() method. I need to change the title and icon of this window. I notice that the title is "http://www.jpct.net" so it seems that jPCT has access to this window and is modifying the title. Is it possible to get a reference to this window through jPCT?