Problem solved with a simple lock class, locked.

Sorry for all the noise.

I'll, schedule permitting, post the COLLADA reader code here (it makes some assumptions though, but simple ones - like baked matrices) in case anyone can use it.  I've seen a couple of skeletal systems on here that relied on 3rd party COLLADA loaders and maybe this loader will help out.

Cheers,

     WTH

Hi,

I've been using JPCT for a while now, and it's great.  I am currently using it in an applet and it works great there as well.

I recently wrote support for COLLADA meshes and wrote my own skeletal animation system (thanks to the WAZIM COLLADA tutorial), and it all works great.

There is, however, a synchronization issue (presumably) between Java actually painting the screen with the updated frame buffer and the worker run() method triggering renders.

I am using the software renderer, on a rather powerful OSX desktop, JPCT is being used single threaded and the basic architecture of the applet is the same as the applet example code for JPCT.  The main applet method sets up a few things, then spawns a worker thread and the worker thread is the game loop with a small thread sleep call (10 milliseconds.)

I noticed this early on before I implemented the skeletal animation system, because I did a crude morph target animation system at first and if I was using grid super sampling, depending upon the position of the camera, I could see weird rendering artifacts on rare occasions, artifacts that looked like the mesh was half animated and half 'original vertex positions.'  I put this aside, since it was rare, as "some camera usage bug where I'm screwing something up."

When I implemented the skeletal animation system, there was (of course) much more work being done between frames in the 'update skin' method, and (weirdly) when the applet would start up I would see the mesh getting weirdly deformed/properly deformed in alternating frames super fast for about a second or two and then it would render properly continuously.  I wasn't moving the camera at all during this period, and after it stabilized, I didn't move it much except to jump to top/bottom/back/left/right views at the same distance in order to ensure the visual fidelity was proper.

Well, once I'd finished a rough cut of the skeletal animation system I started playing with it and lo and behold, I would (much much more often now) find these sort of 'harmonics' where if I placed the camera correctly, the mesh would alternate between being properly deformed and weirdly deformed and would the framerate would drop from the 30's (non optimized yet!) to the 14's when this happened and if I moved the camera back or forwards just a little bit, it would deform properly each frame and be back in the 30's.

Well, I ignored my instincts for once that this was all my fault (although technically it is) and thought about what I was seeing and said "well, it looks like a classic synchronization issue" and thought to myself "well, I have carefully avoided doing any threading related to rendering", then remembered the base applet spawns a worker thread where all the work is done.

So I went back to the applet, and modified the Sleep period for the thread to 50 milliseconds, started up the applet, and to my amazement the mesh rendered each frame properly from the beginning, but I was, obviously, paralyzing the framerate by only letting JPCT run every 50 milliseconds.  I wanted to see if the reverse was true (if I could make the problem worse) by removing the Sleep call altogether, and it certainly did.  Constant flicker between deformed and partially-deformed no matter where the camera was.

So, I am wondering, has anyone else run into this issue?

Is there a way to know when Java has finished painting the screen (I highly doubt it) sort of like a VSync?  Apparently the framebuffer is providing the image to Java and Java is saying "thanks I've got it" but it doesn't, it starts loading it and the framebuffer starts drawing in it...  I would think that for performance reasons there isn't a double buffer system in the software renderer...

Any way I can replace that Sleep call with something that finds out if Java is done updating the window?

Cheers,

     WTH

That was just absolutely insightful and helpful m8, cheers  .  I guess I'll need to start looking into Applets more.

I've taken a very simple sample applet I found on the forums here, using software rendering, and running it with JPCT and I am getting periodic serious flickering.  The clear color is black, the object is green, and everything appears as it should for about 5 seconds, then it flickers between black and white for about 1 second and returns about 5 seconds later - ad infinitum.  BTW, I am using Applet, not JApplet, as I need to build something that runs on 1.1.

The code I'm using is posted below:


import java.applet.*;
import java.awt.Graphics;

import com.threed.jpct.FrameBuffer;
import com.threed.jpct.IRenderer;
import com.threed.jpct.Object3D;
import com.threed.jpct.Primitives;
import com.threed.jpct.World;

public class TestApplet extends Applet implements Runnable
{
private static final long serialVersionUID = 1L;
   private Object3D box;

   private FrameBuffer buffer = null;
   private World world = null;

   private boolean alive = true;
   private boolean initialized = false;

   // Initialize all components of the applet
   public void init()
   {
       world = new World();
       World.setDefaultThread( Thread.currentThread() );
       world.setAmbientLight( 0, 255, 0 );

       buffer = new FrameBuffer( getWidth(), getHeight(), FrameBuffer.SAMPLINGMODE_NORMAL );
       buffer.enableRenderer( IRenderer.RENDERER_SOFTWARE );

       box = Primitives.getBox( 12.0f, 2.0f );
       box.setName( "MySphere" );
       box.build();
       world.addObject( box );

       world.getCamera().setPosition( 50, -50, -50 );
       world.getCamera().lookAt( box.getTransformedCenter() );

       initialized = true;

       new Thread( this ).start();
   }

   // Main Game Loop:
   public void run()
   {
       while( alive )
       {
           box.rotateY( 0.01f );
           this.repaint();

           try
           {
               Thread.sleep( 10 );
           }
           catch( Exception e )
           {}
       }
   }

   // Draw the scene:
   public void paint( Graphics g )
   {
       if( !initialized )
           return;

       buffer.clear();

       // render the world onto the buffer:
       world.renderScene( buffer );
       world.draw( buffer );
       buffer.update();
       buffer.display( g, 0, 0 );
   }

   // End the main game loop:
   public void destroy()
   {
    alive = false;
   }
}


I'm not experienced with applets, so I'm probably doing something terrifically noobish (and if so, I apologize), but should I be manually double buffering something?  Or, am I using something obviously wrong?

Very much appreciated - btw, I'm testing on Vista SP2, with 1.6 JDK (configured to use 1.3 but emit 1.1 code) - Eclipse IDE