#1
|
|||
|
|||
Linking problems with Live Character
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: Code:
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) Last edited by Frank Verberne; 06-04-2008 at 11:19 AM. |
#2
|
|||
|
|||
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.
|
#3
|
|||
|
|||
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.
|
#4
|
|||
|
|||
Add the following code to the end of your script:
Code:
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) 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. |
#5
|
|||
|
|||
Packages are indeed being dropped:
Code:
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 Yours, Frank |
#6
|
|||
|
|||
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.
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Live Characters plugin | Frank Verberne | Vizard | 7 | 03-01-2012 03:23 AM |
Locking every bone of a character | Frank Verberne | Vizard | 2 | 03-17-2008 11:21 AM |
problems with webcam plug-in | v-clizzin | Plug-in development | 2 | 01-25-2008 04:06 PM |
Displaying live video in Vizard? | Deltcho | Vizard | 2 | 01-04-2008 12:05 PM |
Problems with lighting in 2.0 | murm | Vizard | 6 | 04-21-2004 10:59 AM |