<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Scripting Structures</title>
	<atom:link href="http://www.softimageblog.com/archives/116/feed" rel="self" type="application/rss+xml" />
	<link>http://www.softimageblog.com/archives/116#utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=scripting-structures</link>
	<description>People and thoughts behind Softimage in production...</description>
	<lastBuildDate>Fri, 23 Jul 2010 12:23:34 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Homam Bahnassi</title>
		<link>http://www.softimageblog.com/archives/116/comment-page-1#comment-6954</link>
		<dc:creator>Homam Bahnassi</dc:creator>
		<pubDate>Sat, 28 Oct 2006 12:12:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.xsi-blog.com/?p=116#comment-6954</guid>
		<description></description>
		<content:encoded><![CDATA[<p>Andy, I’m so sorry for my very late replay…</p>
<p>Actually I’ve two scenarios for using this concept in our production.</p>
<p>The first one is where we store scripts at the scene level. In such cases we store scripts for specific scenes that require some sort of re-initializing or bug fixing.<br />
One actual sample of this was in my last project, where we were animating objects with muted camera projection. The mute option was buggy (each time we open a scene the some projections get broken) and we can’t freeze the camera projection because we need the construction history. This leads me to develop a script that is saved with those buggy scenes to fixes them when required.</p>
<p>The other case for utilizing this concept was used at the model level.<br />
The samples on this case are common in our game production. A lot of times we face characters animated with custom rigs that are not supported with the current exporters. Those rigs require custom scripts for plotting, optimizing before exporting them to the game engine. So we develop the plotting and optimizing script and attach it to root model of the rig.<br />
This way each script is saved with its associated rig and accessed every time very easily.</p>
<p>Now those are some of the cases that come to my mind at the moment… I’ll continue sharing other cases whenever I face them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy Nicholas</title>
		<link>http://www.softimageblog.com/archives/116/comment-page-1#comment-6452</link>
		<dc:creator>Andy Nicholas</dc:creator>
		<pubDate>Fri, 06 Oct 2006 10:04:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.xsi-blog.com/?p=116#comment-6452</guid>
		<description>Hi Homam, it sounds like a powerful concept. Could you give some examples of what sorts of things you use these stored scripts to do in production?</description>
		<content:encoded><![CDATA[<p>Hi Homam, it sounds like a powerful concept. Could you give some examples of what sorts of things you use these stored scripts to do in production?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
