Hi Todd,

Thanks for the input.

Since I want the entire set of transforms (6 or 7) being changed "at once" I think I 
think to synchronize before the loop and not just before each set. Since the method 
does nothing more than the loop, I figured it would be fine just to synchronize the 
entire method.

As for testing the Thread.. I have placed a print call in the processStimulus mehtod 
of my behaviour and it definitely stops being called after a time. I guess what I 
should do is acquire a reference to the Behaviour thread and see if it is still alive. 
 Is there an easy way to do this?

josh

>>> [EMAIL PROTECTED] 01/04/02 11:55AM >>>
Josh,

Maybe you could try synchronizing only on the jointTransforms array in both
your methods, as in:

public void someMethod()
{ synchronized(jointTransform)
  { do something to jointTransform...}
}

Another idea is to check that the Java3D thread is actually getting bogged
down, instead of your updating methods simply not sending new values or
repeating the old ones.  This would make it look like Java3D was stopped
when actually there was nothing new to draw.

-Todd


-----Original Message-----
From: Josh Richmond [mailto:[EMAIL PROTECTED]] 
Sent: Friday, January 04, 2002 9:43 AM
To: [EMAIL PROTECTED] 
Subject: [JAVA3D] On Threads but a slightly different topic


Hi everyone,

All this talk on Threads has encouraged me to relate a problem I'm having
with Java3D and Threads. Hopefully it's something I'm doing wrong that I can
fix.

My application essentially animates an articulated arm (a TransformGroup for
each joint). The user drags a JSlider which sends data over a socket to a C
application (historic kin/invkin engine that i must use), which processes
the data quickly and sends joint data back over the socket to my Java app.

I have a few threads involved, but here's my basic scheme:

1) One thread continually reads the socket and updates a set of transforms
in my Manipulator object. These transforms are not placed in the live
Transform groups.

// This method is called by the socket-reading thread with new joint values
void synchronized Manipulator::setJointValues(double[] newJointValues)
{
    for (int j = 0; j < jointTransforms.length; j++) {
        jointTransforms[j].rotX(newJointValues[j]);
    }
}

2) A behaviour runs every 31ms and calls a synchronized "latchJoints" method
on the Manipulator object which places the transforms into the live
TransformGroups.

// This method is called from processStimulus of the behaviour
void synchronized Manipulator::latchJoints()
{
    for (int j = 0; j < jointTransforms.length; j++) {
        jointTG[j].setTransform(jointTransforms[j]);
    }
}

This works fine for a while, then eventually stalls the Java3D Behaviour
thread. The socket-reading thread continues. It's worse with a smaller
scene.

I have tried using the InputDevice mechanism but it had the same problem
(albeit an older version of Java3D). I have also tried waking the behaviour
after every frame, but it's much worse.

Alas, when I run the app in a debugger it never crashes! Typically Threading
problem, right?

Unfortunately my app is too huge to be useful as a test app and I haven't
the time right now to pare it down, but if anyone sees an obvious blunder on
my part I'd appreciate some insight. I'd appreciate debugging strategies
too.

Thanks everyone,
Josh


----------------------------------------------------
Joshua L. Richmond, BASc, MSc.
Systems Engineering (R&D)

MD Robotics
9445 Airport Rd, Brampton, ON, Canada
(905) 790-2800 x4332
-----------------------------------------------------

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

==========================================================================To 
unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to