Hi
I have been having a problem with one of my animations. it is a Animation 1750 frames long, for various reasons I have had to start/stop [a few times] the rendering process. I am rendering over a network with all the files on a server which all machines have access to, using anywhere between 1 and 8 machines.
I have got to a stage where I want to continue the rendering from frame 899. When I set it to start at 899 it shows in the distibuted render dialog box as :-
105% Recording frame 899 of 851
and stays there not completing the frame. I have left it over night on two computers, one picked up frame 899 another picked up 900, but both just sat there till the morning - roughly 15hrs - not doing anything else, when the frames individually have been taking less than 4 min each this behaviour is odd.
If I tell the record script dialog box to start at frame 1, the process starts as expected and completes frame 0 then picks up the next frame. Is there something screwy going on with the frame numbering system in modo/ distributed render setup?
That does sound wacky and I have not seen this before. Paul is out on vacation I can have him take a look when he gets back. In the meantime you could manually use Distributed Rendering by using the File Continue Recorded Sequence option from the Animation Producer. The Distributed rendering controller uses this too it just automates the process for you.
If you have the necessay files and textures visble from multiple machines you can start MicroStation and load the file with the animation script it will be read only from all but the first machine but that is okay.
Start your record script on the first machine and make sure you are rendering frames to a location that all machines can access. Go to the second machine and open the model read only and then choose File Continue Recorded Sequence, browse to the folder where the frames are being rendered and double click on the .asf file (animation settings file) and the machine will start to render and pick up the next frame. Go to the rest of the machines that you wnat to chime in with and repeat the process.
One advantage you have with this process is you can start and stop machines and pick up where you left off. You don't have to say render frame 799 to 1750 if the original asf file had 0 to 1750 it will just pick up the next frame in sequence and go from there.
Jerry
I had left the computer running from frame 874 after work, it got to frame 899 at 17.27 [barely half an hour after I left] and has stayed there since. So I guess it is a problem with that particular frame, nothing extra special is happening in the animation at that point.
It is a [I think] simple animation of a camera following a path round a ship set in water [with pattern and bump map increment] and an environment with an image.
I have not used the continue record sequence tool - that looks like a better way for me to go. I'll have a play with that one:)
I tried this morning to render frame 899 from inside microstation using the luxology render dialog. I set the animtion time slider to 899 and set it to render from a view of the correct viewng ratio. It took [what seemed like] longer to process the light passes. And appeared to hang after a couple of blocks were fully rendered [see below]
I then went forward to frame 900 which didn't complete, frame 905 - didn't complete. BUT frame 910 did [in 4min 26s], so I went back to 909 with success [4min 23s]. I'm going to slowly creep back to see which frames are having problems.
Below is frame 910
Now looking at it the animation is comming to the point where the camera goes below the waterline to rotate underneath the ship to show the hull and thruster units. Maybe it is having trouble passing through the water surface? - a flat circle with pattern, bump, diffuse, and displacement modified.
RIGHT, I went through individual frames using the luxology render dialog from miocrostation starting from 910 going back. There appears to be a range of frames I doesn't like = 899 to 906. So I have copied the image of frame 898 and re-named them 899, 900, 901 etc within the folder where the images are saved. Then went to the animation producer dialog box and continued the record animation sequence, the animation started and picked up the next avaliable frame [911] and has completed a couple of frames - So it looks like I got past that glitch, I guess I'm going to have an 8 frame error near the middle of the animation [I wonder if anyone'll notice:)]
I originally setup the animtion as a distributed process using a group that ONLY I am in. So what would be the best way to get other machines to contribute to the animation at a later stage? - add them into that group using the Animation Scheduler? - go to their machine and do the continue record sequence thing? - go to each machine and set them to do a specific range? - OR any other birght ideas?
An 8 frame stutter might look pretty bad, maybe you can make a packager file and post the data set so that we can have a look. If you can drop it to ftp.bentley.com/pub/incoming and send me an email with the file name I will take a look to see why you cannot render those frames.
Cheers,
jerry
Good Morning Jerry,
I will try to load up the file [dgn] to the ftp site, not sure what you mean by a packager file of the data set? I'll give you an e-mail with the name when it is successful.
I had a nother look at those frames I rendered through the Luxology Dialog box within microsttion, they appear different from frames rendered through the distributed process/ the record animation tool. It looks like the Luxology doesn't take into account the bump and pattern map incriment from the aimation. Over the frames I rendered using the Luxology dilog the water element doesn't change. See Images below...
Above is frame 898, the frame before the error, and is rendered as it should be. 899-906 are [at present] missing. [898 was rendered using the record animation dialog box with distributed render]
Above is frame 907, the next 'good'/ renderable image after the bad patch. On first glace I thought it looked ok, but looking at it next to the frames before or after there is a substantial difference. [907 was rendered throught the Luxology render dialog from within microstation]
Above is 908, it is hard to tell but the camera had move down and to the left alittle. The animation camera path takes you aft and underneath the vessel [down and left] but the water image stays the same, there is no ripple movement. It is easier to see this when I use the windows photo viewer and skip forward/backward through the image set. [908 render using the Luxology render]
Above is 909, again camera moves alittle down and to the left, water stays the same [render through luxology render]
Above 910 [render through luxology render]
Above 911 [rendered through the record animation render] I was using the same lights render setup and environmnet when rendering through bothe the luxology render dialog and the record animation dialog so I cannot understand the difference?
Above 912 - The water has changed slightly [again difficult to tell from here - but if looking at a set of images with the windows photo viewer and 'flicking' back and forth between the images the movement of the water is obvious]
The 8 frame stutter may not be so bad as it is at the point of diving through the water, so the change in visualision from above to below the water line might hide the slighly bigger jump/movement of the camera. I'll have you stitch all the jpg to an avi to tell though!
I have also noted another inconsistincy, for a couple of frames [633-640] It loses some of the textures, it appers to be just the environment and the water element & texture.
Above 632
Above 633.
Seems a bit weird that as all the textures, info, files etc are on the server why only some of the information goes missing. If network connection was interupted then surely the whole animation would fail. So not sure why it loses bits over a couple of frames then finds them again!?