As I mentioned in a recent post about the problems in matching camera paths in Embergen I am now encountering a serious bug. After four days of trial and error I have arrived at a work flow that allows me to take a camera move in syntheyes, modify it slightly in fusion, then convert it to an fbx. This fbx still reads incorrectly in embergen but if I read it into blender and correct blender’s own import issues, then write it out as fbx embergen consistently reads it correctly.
So I finally created my simulation and rendered it out for comping. When I went back to the embergen file to tweak it I found that the camera path had been corrupted - instead of one continuous 494 frame move it now jumped back to an earlier position every 100 or so frames, and was therefore unusable. It was fine when I saved it, and I have the correct render of the sim to prove it. So something happened in either the save or read process to mess up the cam path.
This is the sixth or seventh time this has happened this week, so I’ve taken to making multiple backups and therefore it wasn’t a total disaster. But with all the issues around camera matching (and with fbx files themselves) this is an added layer of potential issues that could really mess you up.
I’ve made a test directory with the embergen file, the backplate images and the fbx file. I’ve changed the geometry and images as the real ones are under heavy NDA but the camera move is the same. The backplate images show what the camera move should be and was, and the embergen render shows what has happened to the cam move.
All three frame rates - import, simulation and backplate - are set to 96 frames a second (4 x 24) to get the scale right on the sim. The version is 7.5.9. I don’t recall seeing this behaviour in earlier versions but then again this is the first time I’ve really hammered it.
If someone from Janga can give me an email address to send it to I can post it on dropbox - it’s about 40 megs.
IMHO this is a bit of a show stopper - hopefully it can be tracked down and fixed ASAP.
Further info - if you reload the fbx asset through the import node the screwed up cam path persists. If you delete the import node, create a new one and reload the fbx asset the path is corrected, but of course you lose the sizing, frame rate and global transform settings you labouriously set up to position the simulation within the fbx camera move. So you have to record the sizing, frame rate and global transform settings from the borked embergen file (I took a still with my camera) and re-enter them into the new one.
Then you get your animation back correct - until the next time the cam path gets corrupted.
Hopefully this info will help in tracking down this serious bug.
Again, I can send a zip file with the files if anyone at Janga responds with an email address.
FURTHER INFO - when I checked my backups I found they all had the camera path jumps in them so clearly it happens on the write out operation.
Working backwards I found that the frame rate changes seem to be what causes it. As I said before, to get the scale I need I set the frame rate in the camera backplate, the frame rate in the import frame rate override and the frame rate in the simulation to be 96 fps. It appears that if I write out the file with the frame rates set at that the camera path corruption happens. If I do my tweaks and render out the file without leaving embergen it’s ok.
So if I do have to save the file I reset all three frame rates to 24 - which means the sim looks pretty weird - then save. When I read it back I reset all three frame rates to 96 which gives me back my correct sim and camera move, then render.
So it looks like I have a workaround for now, painful though it is. Hopefully this gives the Janga dev people a pretty good clue as to where the bug lies.
After a lot more tests it seems the camera move isn’t being corrupted - it has to do with the “loop” checkbox in the “other” tab of the import node. If you uncheck that, make sure looping is turned off in the simulation and the blue loop checkbox is turned off on the timeline gui then save at 96 fps it reads back correctly. Whew.