OK! Thanks Alan and Oscar for the insight.
Cheers,
Jean-Louis
On 18 Nov 2013, at 18:52, Alan Fregtman alan.fregt...@gmail.com wrote:
The animation caching pipeline I wrote at work looks at the construction
history stack and if it's operator-free it plots that item's global
kinematics,
I agree with Cesar on that point. It's best practice to not send live
rigs to render and have caching an essential part of the pipeline.
On Friday, November 15, 2013 8:57:20 PM, Cesar Saez wrote:
Or you can just cache the rigs (en everything else) before send them
to the farm... just saying
Yes that’s what we did previously on a model that had just a few surfaces to
cache (a mouse).
Here however we have a robot with hundreds of elements, some rigid and some
deformed, with a pretty huge geometry count. Things risk getting big pretty
quickly, so I was hoping to avoid caching unless
Alembic can save transforms and point caches, you could try with Exocortex
Crate, that would help on the file size front.
You could also script saving plotted global transforms on geometries which
don't have and envelope or deformer and save them to a clip which you load
in your rendering scene,
The animation caching pipeline I wrote at work looks at the construction
history stack and if it's operator-free it plots that item's global
kinematics, else pointcaches. This way we don't have to really think about
it if it's an insane asset.
Actionclips are very light in my experience. On top
That's strange since I used those imports all the time last year when
working on CentOS using Softimage. You'll probably need to post more
info about the errors for more help.
On Friday, November 15, 2013 9:13:48 AM, Jean-Louis Billard wrote:
Hi SI warriors,
We have a rig that was made by
Hi SI warriors,
We have a rig that was made by someone using some python script based property
sets.
He did all this in a windows environment, but the moment we send the scenes to
our linux based renderfarm the clients fail to render.
Looking at his script I see the lines:
import
H… ok, but where does the module reside for it to be accessible by Linux?
Are they installed by XSI?
Jean-Louis
On 15 Nov 2013, at 15:18, Luc-Eric Rousseau luceri...@gmail.com wrote:
these are Windows API modules, but I think they should run in xsibatch
on linux. But no way they'll
on deb:
/usr/Softimage/Softimage_#year#_SP#/Application/python
could it be that your soft python isn't registered on your render boxes ?
from your /app/bin
mwpython win32com/axscript/client/pyscript.py
On 15 November 2013 16:49, Jean-Louis Billard jean-lo...@photon3.comwrote:
H… ok, but
Oooh now that sounds like it could be right…!
I’ll go check it out and see.
Thanks!
Jean-Louis
On 15 Nov 2013, at 16:30, Jon Swindells squi...@gmail.com wrote:
on deb:
/usr/Softimage/Softimage_#year#_SP#/Application/python
could it be that your soft python isn't registered on your
You cannot use those modules outside xsi/xsibatch. They only work within
Softimage. Also, Softimage Linux has its own isolated Python 2.5 (or 2.7 in
2014) environment so don't even try adding them to the module.
They're automatically available within Soft's Python. They should not fail
to import
Or you can just cache the rigs (en everything else) before send them to the
farm... just saying :-)
12 matches
Mail list logo
