Linking problems with Live Character

[Frank Verberne]

Hi all,

I'm encountering a strange problem with linking the mainview to a bone of an animated avatar.

Whenever I use an avatar that's being animated by the Live Character's plugin for MotionBuilder and I link viz.MainView to one of it's bones ('bip01 Head') with the viz.link() function, the result is a choppy mainview. When I link an object ('box.wrl') to the same bone (without linking the mainview to any bone), the avatar seems to be moving smoothly (or the choppyness is only noticeable when the mainview is linked to one of the bones).

The framerate is not a problem, and the stream rate in MotionBuilder (Live Characters plugin) is stable and high enough (set it to 250). However, it seems that the avatar is not updated fast enough when the mainview is linked to one of it's bones (the framerate doesn't drop, but the whole scene is choppy). I already tried adjusting the streamrate of the Live Character plugin, but that didn't help. I also tried linking the mainview to other bones or to use an other avatar, but the problems still exists.

How can I let the headbone move smoothly with the plugin and at the same time link viz.MainView to it?

For the record, I want participants to be able to literally see through the eyes of an animated avatar (they animate it themselves). I'm also working on another solution by linking the mainview to a sensor and then pretranslate that link to just before the eyes. However, that solution is not flawless, and the link-function would be the perfect solution if only the view wasn't choppy.

The code below causes the problem:

import viz
import vizmocap

viz.go( viz.HMD | viz.FULLSCREEN | viz.STEREO )
gallery = viz.add('gallery.ive')
avatar = viz.add('vcc_male.cfg')
lc1 = vizmocap.LiveCharacter('192.168.2.103',8050,model=avatar)
viz.eyeheight(0)
bone = avatar.getBone('Bip01 Head')
viz.link(bone, viz.MainView)

[farshizzo]

Whatever choppiness you are seeing is most likely coming from MotionBuilder. There is no difference between linking a view to a bone than a node. I would NOT set the stream rate of the LiveCharacters plugin too high. Setting it to a value like 250 might cause the client to drop packets, and in this case you will definitely see some choppiness. To ensure the client has a new packet every frame, set the value just a little bit higher than the client framerate. For example, if your framerate is 60Hz, then set the stream rate to 70.

[Frank Verberne]

Good to know that the streamrate shouldn't be too high. I tested various streamrates (70, 65, 61, 60) but changing the streamrate didn't solve the problem. Any other ideas? We have a wireless connection between the motionbuilder pc and the laptop with the HMD attached to it, could that cause any delay? I have tried to run the script on the motionbuilder computer and the problem still existed, so I don't think that could be it.

[farshizzo]

Add the following code to the end of your script:

lc1.lastUpdateTime = 0.0
def CheckUpdateTime():
	t = lc1.getLastUpdateTime()
	if t == lc1.lastUpdateTime:
		print 'Did not receive new update from server on frame',viz.getFrameNumber()
	else:
		lc1.lastUpdateTime = t
vizact.ontimer(0,CheckUpdateTime)

It will print out a message if the character did not receive an update from the server during that frame. If you are getting a lot of these message, then packets are being dropped.

Also, make sure that MotionBuilder is able to sustain the requested stream rate. When you go to the LiveCharacters device screen it will display the actual stream rate underneath the Online checkbox.

Also, what hardware is MotionBuilder connecting to? In reality, there is no point in setting the stream rate higher than the rate of the hardware device. If the hardware is generating new data at under 60Hz, then setting the LiveCharacters stream rate higher is not going to make any improvements at all. You will just end up sending the same data multiple times. So make sure your input device is generating new data at 60Hz.

[Frank Verberne]

Packages are indeed being dropped:

Did not receive new update from server on frame 2
Did not receive new update from server on frame 21
Did not receive new update from server on frame 40
Did not receive new update from server on frame 57
Did not receive new update from server on frame 63
Did not receive new update from server on frame 69
Did not receive new update from server on frame 103
Did not receive new update from server on frame 111
Did not receive new update from server on frame 117
Did not receive new update from server on frame 122
Did not receive new update from server on frame 140
Did not receive new update from server on frame 143
Did not receive new update from server on frame 148
Did not receive new update from server on frame 156
Did not receive new update from server on frame 175
Did not receive new update from server on frame 187
Did not receive new update from server on frame 194
Did not receive new update from server on frame 225
Did not receive new update from server on frame 233
Did not receive new update from server on frame 247
Did not receive new update from server on frame 260
Did not receive new update from server on frame 275

MotionBuilder is able to sustain the streamrate, so that's not the problem. The motionbuilder computer connects via the dtrack listener plugin to the dtrack computer. It also has a setting of framerate and it's set on 60 Hz. Dtrack itself is also set on 60 Hz and the program receives it's data from 16 IR ARTtrack camera's. I don't know if you have enough technical specifications now, so please let me know what else you have to know.

Yours, Frank

[farshizzo]

In general, you would want the hardware to generate data at twice the rate of the client framerate. When the hardware and client are running at the same rate, it is common to run into timing issues where the client will miss new frames. This is especially true in this case, since the data is going through MotionBuilder, then over the network, which is going to add even more delays. There is no easy solution to this other than having hardware that can generate data at a faster rate. Streaming the LiveCharacter data at more than 60Hz will not do anything at this point.