Tango

Here we go again. I have gone through this before and ended up not animating with EI. I have several models in 3Ds format, all with textures and UV mapping. I can read the models with textures in Maya, Silo, Meshlab, Blender and even Poser, but EI can't deal with them. I make sure the preferences for import allow UVs, import a model in and get an all black object, no textures. I exported the models through Silo, converted .objs with O2F, still black. I give up... Why can other programs read them as is, no gymnastic, no sweat? Why do I have to wonder what could I be doing wrong? We are in the middle of a big project and I don't have time to send a model for testing (there is nothing wrong with the models). All I hope is that someone will tell me I missed a step somewhere, something simple. I have to get some sleep now and if I can't quickly figure it out in the morning, I'll have to move to plan B (which does not involve using EI). Thanks, Christian

Yes Tomas, the path is weird. My bad, it's a typo. It should be a forward slash. Also, I have been using underscores in names and paths without problems for as long as I can remember. I tried the same script on a different Mac (different name) and crashed on the first frame rendering directly from EI. I moved the EIAS 8.0.0 folder to the desktop and tried. Crash, it did not like that a bit. I thought that folder "had to be" in the Applications folder?.. Moved it back and did another test after re-entering my Unlock Code, I turned off the shader and it rendered a full sequence without a blink. I still believe it has to do with paths, maybe some routine getting confused? Can you really get EI to run from the desktop? I may try it on a different computer but I have to make sure I have my Code with me.... Christian

Hi Bill, Unfortunately, I don't have an answer to this one. I have experienced the same thing, 92, 96, 98%... Sometimes it's the 2GB size limit, but not all the time. I can get away with restarting as long as I am around. Not good for overnight renders that need to be ready in the morning. We are using a MacPro 8 core as a small renderfarm, controlled by my MacBookPro. It was working well under v7. So, I have the feeling it has something to do with v8. I may go back to v7 just to see if it is more reliable, it's just a lot of work to re-install with all the plug-ins. I'll let you know if I find anything. Christian

Hi Tomas, In my case, either it refuses to open the script (if it has active plug-ins or shaders in it), or it crashes while rendering. And this is the weird part, it will do a different length sequence before the crash depending on the script (20, 40, 120, it seems to be multiples of 20). If done through RAMA, I can restart and it will crash Camera after the exact numbers of frames. So, I can get the renders done by restarting till it's done. I did a complete clean-up of my MacBookPro over Christmas and even re-installed v8. It did not solve the problem. I ran a small test with Renderama this morning and got this message: Camera Error : A system API function has returned an unexpected error number. Library : MCIO Error ID : 4 Error number : -35 File : /Volumes/Tango_2?Applications/EIAS 8.0.0/ Renderama_Output.img Then tried a straight render and got an Error ID : 17 Error number : -42 instead. Both errors are MCIO (Mac specific) and complained about "System error and file path given". So, I wonder why does it crash after a number of frames and not right away? Why a different number? It reminds me of memory leaks we experienced when I was working with Houdini on SGIs. Could it be UNIX related? I have the same problem on another MacIntel and a PowerMac. Maybe I should test it on a PC. We may have to switch back to v7 until it gets solved, I am just not entirely convinced the problem is on our side. Thanks, Christian

Hi Dave, Since I can't open scripts using the UberShapes in v8, I had to open them in v7 and export from there. Unfortunately, it doesn't have the great auto-import v8 offers. I had to reposition the .fac to match the UberShape I replaced. I managed to do it once with v8 and it was great (that was before it started crashing). The strange thing about this is that I can create new UberShapes, save the script and re-open without any problems. It feels like it looses connection wit the plug-in in older scripts. Could this have to do with the fact that I re-installed v8 during my trouble shooting. Most error messages complain about "System error and file path given", wether it is an MCIO or SCAL type error. It may be specific to the Mac version. I should try it on PC since I have a dual dongle. But not today, I have too much production to do. My current scripts are large when collected due to large texture maps, I would like to send you a script but would need to post-it on an FTP server. Is there an email I can use to send the info? Thanks, Christian

Hi Tomas, It is one of a series of plug-ins by TripleDTools ( aEdge, aRamp, aRIM, aSEM, bFraktal and aStorm ). I have been experiencing problems using some of them and the venerable UberShape as well. I just can't use plug-ins or shaders anymore.... Christian

Hi, The more I wrestle with my problems, the more convinced I am that v8 (for Mac) has an issue with plug-ins and shaders. I just restarted the same script turning off "aSEM" and rendering a PIT sequence. It's all going well, except that it is not the right look and I am not doing it with Rama. We have a big project on the back-burner waiting for this one to finish. I may try completing it in v7 to check this theory. I have to be able to run plug-ins and shaders. I'll do more testing and get back to you on this one. Christian

Hi Dave, I used to run Houdini on an SGI and numbered frames were the way to go. It is safer than quicktime in case of crash. I tried and failed to make it work in EI a long time ago. I am not sure what the issue may have been but I could not get numbered frames from it. I just did a quick test and it rendered PIT frames to the Renderama Output folder, the folder where it picks-up the frames for stitching. Not sure why they are not where I told them to go. The test didn't make it to the end, it crashed at frame 20. Apparently a MCIO error no.4. That's a different story, I just don't get this one. I did a bunch of renders this morning, no problem. All I know is that I am using a shader and I have been experiencing tons of problems with scripts using shaders and plug-ins with v8. But I digress.... I will try a frame sequence again once I solve this new problem. Thanks, Christian Hi Tomas, You make an interesting point there. I always tried to do the numbered frame sequence render through Renderama. That would explain why it wants to stitch the files. My problem is that we are rendering on an 8 core MacPro. I can get 8 Cameras running, a beauty to watch rendering, and that has to be done with Renderama. Is there any way to get Rama to spit out numbered frames? Thanks, Christian

Hi, We are facing an old Camera (or maybe Rama problem). We have long HD sequences to render for a documentary, as long as 28 sec. a piece. This is above the usual 2 GB size limit Rama will stitch. Rama reports a stitching error as it reaches 2GB. It is usually impossible to go back, break the rendered files in smaller groups and stitch manually. We get around it by breaking the renders in sections but multi layers renders make it a pain to manage, specially that we have animated texture maps on some layers. We have to make sure we indicate a new in point for the maps in the different sections... It's prone to human errors. Any idea on where EI stands on this issue, it's been around for a while now? (maybe it's been fixed and I just don't know how to do it properly) Thanks, Christian