Applet and synchronization - I am using software renderer

[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

[WTH]

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

[EgonOlsen]

Posting the loader's code would be cool...