That sounds great Homam, I'm really looking forward to reading it.
The reason I brought up the "merge object" situation was because I know
that in a hectic production, you can't rely on artists to remember to copy
the scripts across by hand. This also applies to Raf's comment, since
unless you can stop an artist from using the native merge tool (which I
don't think you can, since you can't remove menu items from XSI), then
you're at risk of breaking the pipeline.
I guess the only solution is to completely customise the interface with
your own toolbars, so that they have to use your own wrappers to the
modelling operations which could handle the script transfer. But it still
doesn't make for a water tight pipeline, unless there was an ability to
stop them accessing the old menus.
If Softimage added a few more event hooks to XSI it might be possible to
sort out, but maybe at the expense of performance. At the moment, the
custom display host obtains some of events that would help you, but it
then means you have to have that window open all the time, so it's still
not fool proof.
Anyway, I hope I'm not pouring cold water on your concept! It's just that
these problems are ones that I've thought about before when trying to do
something that's kind of related to what you're discussing.
I look forward to your article.
Cheers
Andy
> Thanks for the good idea Andy! I?ll try to re-write my narration on the
> presentation slides as an article and post it to xsi-blog.
> I?ll try to include also some production samples for this system in the
> article.
>
> Regarding the merge objects case and other object generator operators,
> since the scripts on each object are stored in their own properties;
> they?re easily transferred to the new generated object simply by dragging
> and dropping and they?ll get executed both as they?re truly merged.
> For me I prefer to make the merge operator have the ability to transfer
> the attached properties to the new generated objects like it do with
> materials and UVs.
>
> Thanks,
>
>> Hi Homam,
>>
>> Looks interesting, thanks for posting. I was wondering if you could
>> elaborate about how you see such a system being used in production?
>> Maybe
>> even write an article on www.xsi-blog.com?
>>
>> For example, a concern I have is that I find it difficult to see how it
>> would be used in an artist's workflow, e.g. what happens when an artist
>> merges two objects (that may have scripts on them)? The scripts would be
>> lost since the merge operation generates a new object.
>>
>> I'm interested to hear how you see this being used.
>>
>> Thanks
>>
>> Andy
>>
>>
>>
>> -----Original Message-----
>> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf
>> Of
>> Homam Bahnassi
>> Sent: 17 August 2006 20:57
>> To: xsi(at)Softimage.COM
>> Subject: [ANN] Scripting structures
>>
>> Greetings,
>>
>> A new scripting workflow inside XSI scenes that exploits scripts as
>> object-oriented scene entities inside of XSI...
>>
>> http://www.inframez.com/events_scriptstrct_slide01.htm
>>
>> Have good time.
>>
>> Homam Bahnassi
>> 3D Supervisor
>> In|Framez
>> --
>> In|Structurez Arabic 3D Community
>> www.instructurez.com
>>
>>
>> ---
>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
>> body:
>> unsubscribe xsi
>>
>>
>> ---
>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
>> body:
>> unsubscribe xsi
>>
>
>
> Homam Bahnassi
> 3D Supervisor
> In|Framez
> --
> In|Structurez Arabic 3D Community
> www.instructurez.com
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
