Blender plugin recording speeds up


#1

Hi there, I have a quick question. Using your plugin for blender, over time the recording of the animation significantly drops in frames, therefore making all movements look really fast on playback. I can play the animation back at full speed, but it’s quite obvious as time goes on with the animation that it’s slowly going faster and faster.


NI mate v2.14 released!
#2

Hello!

Sorry about the late response.

Could you include the .blend file with your recorded data? There are a few reasons why something like this could happen, but I’d like to get an idea on what the problem looks like first.


#3

Can do.Now, I should mention this computer is no slouch, and can in fact keep up in the NI Mate program at a full 30 FPS tracking. https://drive.google.com/file/d/0BwpqFXYYNpt0cl9qUl9PTEFyb2M/view?usp=sharing


#4

This seems like the keyframes were made more and more delayed when the recording happened, up to the point where in the end only every “nth” keyframe was placed. What’s odd about that is that the keyframes are still placed on every frame. If there was a delay in recording the keyframes, there’d be gaps in the graphs instead of every single frame being filled in.

Did you perform any kind of cleanup on this data? For example, did you use the “Sample Keyframes” or “Clean keyframes” utilities, or is the mocap data in this file unedited?


#5

To notify you, @ProjectAlpha22, I’ve moved this in a new topic.


#6

None. This is raw input to output. What you see is what was input into the program with no alterations, smoothing, or sampling that I am aware of. As said earlier, my FPS goes down over time while recording, but I can assure you that isn’t the Blender side of this as when I run back the animation it stays at a full 30. Unless you put in some sort of code for the free version of NI Mate that makes this happen, which I hope not (As a High-School student, this program is my saving grace), I’m unaware what is going on!


#7

There are no artificial slowdowns of any kind. The trial version only locks a few features.

The process of sending the skeleton tracker data is as follows:

  • Sensor sends data over USB to NI mate
  • NI mate processes this data
  • The OSC scripting system on the skeleton tracker page is used to modify these values and form OSC messages (Documentation: OSC (Open Sound Control) and parameter tags)
  • The messages are sent over OSC to the Blender plugin where they are parsed one at a time (one message for each bone) and the data in the scene is updated to match the received values

You said NI mate runs at stable 30 FPS. This means we can eliminate any USB related trouble, which is good - it’s really tricky to fix a bottleneck at USB level. This also means we can eliminate the OSC scripting system which can occasionally be slow. The problem is then in Blender in either parsing the OSC messages or updating the scene data / saving the keyframes. It could also be in transmitting the OSC messages themselves, but if this is on the same computer it’s unlikely unless something is interfering with the traffic (antivirus or firewall).

Typically a slowdown in Blender can happen if the scene has a large amount of data in it, particularly if there’s already animation taking place, requiring the objects to be updated to new poses every frame. The .blend file you linked is pretty light though, so I’m not sure where the slowdown is.

You could take a look at your task manager (Windows) or activity monitor (Mac) and keep an eye on the CPU / Disk usage when you’re streaming data to Blender and recording it. Maybe we can get an idea on if the NI mate or Blender process is the one using resources.


#8

I recorded it, I made sure to keep personal info out and such, but I did want to showcase exactly what happens. It clearly is an issue in regards to CPU on the side of Blender, however it seems to be based off your addon’s usage. You can watch as the CPU seriously increases, and see how it does not when replaying the animation.

I also re-recorded in 30 fps, just to prove it isn’t some sort of desync.

had to remove the https because of auto loading files.


#9

Out of interest, could you open the Blender console window when you’re recording? One idea I have is that something is constantly being printed in the Blender console and that’s the reason for the slowdown. On Windows you can find the console window under Help -> Toggle System Console, and on Mac you’ll need to run Blender from the terminal.


#10

Alright, I am on it. I also list off a bunch of stuff during this that could be problems within code, as well as a few ideas that I think in general may be good additions to the script, such as being able to have multiple empty groups to record multiple people.
(https://)drive.google.com/file/d/0BwpqFXYYNpt0NkNrT0JVTjdscnc/view?usp=sharing


#11

Thank you for the continued benchmarks!

For having empties named differently for each shoot you can use the “Custom OSC Path” field under “Sensor parameters” on the main sensor page to add a prefix on all skeleton OSC paths. For example, add “rec1_” in that field and all bones will be named “/rec1_left_hand” etc.

We did some testing without NI mate and it turns out this is a slowdown in how Blender records keyframes in the first place and / or dispays the 3D viewport. The test we did was:

  • Create some empties. I noticed the problems started after 4 empties.
  • Select all of them
  • Arm the timeline for recording
  • Start playback, move the empties around as the timeline ticks
  • Framerate tanks really quickly

I’ll be asking around the Blender developers about how we could optimize this.

Meanwhile, there appears to be a workaround: enable VBOs in the system preferences.

  • Open User Preferences
  • System
  • Check VBOs
  • Save User Settings
  • Restart Blender to be sure
  • Framerate might go up
  • If framerate is still low, try enabling “Only Render” in the “Display” section of the 3D view controls at the right side of the 3D view.