Re: Goodbyes (was this is the end...)

[Rob Wuijster]

And to add to that, si-community is more or less the one place on the 
web to go for us Softies.
It has become a little bit more quiet after the EOL, but is still there 
and active.


So, in addition to a possible new email list somewhere sometime, I would 
suggest to create an account at the forum.
There's a dedicated corner for jobs, news, work done with Soft and a lot 
of us visit the forum at least once a day.


In addition to earlier praises, this list has some of the most generous 
people in 'software land' I encountered in my 3d years.
From Ed's website that helped me out in the early years of XSI, to the 
video's of people like Brad, Paul, Adam, Chris, and tips and tricks from 
other peeps on this listtoo many to mention, there is always a friendly 
answer, tip or example scene to share. I hope this will go on for as 
long as possible.


cheers all!

Rob

\/-\/\/

On 3-2-2016 1:14, Jason S wrote:

If such a case would arise,
Hirazi? Given your excellent job (also in terms of fairness) in the 
rare cases when moderation was required at SI-Community,

would you be open to moderate the list as well?


On 02/02/16 19:01, Jason S wrote:

If we want, we could follow their example

http://community.avid.com/forums/p/8263/365964.aspx

(and avoid the all consuming vortex  ¦P )
Ladies & Gentlemen:
Due to reasons all too convoluted to go into here, it has been 
decided that the original DS list hosted at Softimage.com will be 
closed down. The community has taken the situation into our own hands 
and moved to a new home. We've now passed 270 members. If you'd like 
to join us, visit the list web page at:


http://groups.google.com/group/DS-List/

At least for us, all previous messages would be kept and new ones 
added at the same place,
except subscriptions & posts would just be sent through at a 
different list @googlegroups.com address.




On 02/02/16 10:23, Bradley Gabe wrote:
I appreciate the sentiment folks, you've already thanked me enough 
over the years. :-)


For the first time, I am concerned that the list might disappear 
once and for all, and possibly without warning. At the moment, this 
has been my only contact with the old user base. I'm afraid if the 
list goes, I won't be able to keep up as I am being sucked into an 
entirely different, all-consuming vortex.






Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com 
Versie: 2016.0.7357 / Virusdatabase: 4522/11546 - datum van uitgifte: 
02/03/16

Re: Goodbyes (was this is the end...)

[Leendert A. Hartog]

@Jason - Thanks for the compliment!
If and when the need were to arise, I would certainly consider it, but not as a 
sole moderator. 
I have learned from my time with the si-community that important decisions such 
as banning someone shouldn't be taken by one person alone.
The si-community has a rule that any temporary or permanent ban must be agreed 
upon by at least two moderators.
That said, IIRC, we only once had an incident that seemed to warrant a 
temporary ban.
Genuine spammers, however, get kicked out without such discretion...

Greetz
Leendert
AKA Hirazi Blue

Greetz
Leendert
AKA Hirazi Blue
Softimage hobbyist, admin at si-community.com & xsiforum.de
On 03/02/2016 01:14:54, Jason S  wrote:
If such a case would arise,
Hirazi? Given your excellent job (also in terms of fairness) in the rare cases 
when moderation was required at SI-Community,
would you be open to moderate the list as well?


On 02/02/16 19:01, Jason S wrote:

If we want, we could follow their example

http://community.avid.com/forums/p/8263/365964.aspx 
[http://community.avid.com/forums/p/8263/365964.aspx]

(and avoid the all consuming vortex ¦P )

Ladies & Gentlemen:
Due to reasons all too convoluted to go into here, it has been decided that the 
original DS list hosted at Softimage.com will be closed down. The community has 
taken the situation into our own hands and moved to a new home. We've now 
passed 270 members. If you'd like to join us, visit the list web page at:

http://groups.google.com/group/DS-List/ 
[http://groups.google.com/group/DS-List/]
At least for us, all previous messages would be kept and new ones added at the 
same place,
except subscriptions & posts would just be sent through at a different list 
@googlegroups.com address.



On 02/02/16 10:23, Bradley Gabe wrote:

I appreciate the sentiment folks, you've already thanked me enough over the 
years. :-)

For the first time, I am concerned that the list might disappear once and for 
all, and possibly without warning. At the moment, this has been my only contact 
with the old user base. I'm afraid if the list goes, I won't be able to keep up 
as I am being sucked into an entirely different, all-consuming vortex.

What's going on here? (Vectors in ICE)

[Tim Bolland]

Hi, I'm little stumped with this behavior in ICE. I'm using a static version of 
a mesh to pick up and store curve tangencies. I then use the reinterpret 
location node to grab the stored vectors on an animated copy of the mesh. This 
works as expected and I see the vectors have translated nicely. However If I 
emit particles from the animated mesh and grab the tangency data from the emit 
location, the vectors don't show up 'correctly'. It's as if it's reading the 
tangency from the initial static mesh, or something like that. 


Has anyone got any ideas what's going on?


Dropbox image:https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0

Regards,


Tim
p.s Sent again with dropbox link instead of attachment


  

Re: this is the end......

[Graham Bell]

I'm saying nothing, this is getting too close to becoming a 'where did it
go all go wrong' type discussion.
On Wed, 3 Feb 2016 at 18:49, Olivier Jeannel  wrote:

> Too bad there was no "lead" with a vision for the future of SI. I'm sure
> people would have follow if you guys had a produced some different ways of
> working and thinking... Isn't it what happened to us with ice ? At least
> for me, before  XSI 7 I wouldn't believed I'd do some vector math, and 1
> month ago I wouldn't believe I'd type some criptic vex code.
>
> On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau 
> wrote:
>
>> On 3 February 2016 at 09:57, Olivier Jeannel 
>> wrote:
>> > Luc Eric, do you mean that ice modeling developpment was in a stall
>> state,
>> > with nothing to do to enhance it because of that glass "ceiling" ?
>>
>> Yeah, ICE modelling nodes expose the operator stack's low-level
>> commands we always had, and we have all the design with clusters and
>> properties to deal with, etc, and that's limiting.
>>
>> We did have to do something to add materials IDs that by-passes this,
>> as you know, because you can't modify a cluster during evaluation and
>> therefore would not have been able set a local material (kind of a
>> showstopper!), but the other tools in XSI do not "see" this material
>> ID concept.
>>
>> ICE really shines at processing data arrays in parallel, but when it
>> gets to modeling, you're constructing a linear sequence
>> single-threaded calls to the geometry engine and you'd need a
>> different kind of design approach to be able to got the next level -
>> and then update the rest of XSI to know about those new structures.
>> Meshes in XSI are not fundamentally arrays of points with attributes,
>> it's more like there is a mesh and there is a cluster somewhere else,
>> and then a property which might be inherited, and then, etc.. the
>> graph is more like a spider web of dependancies and you can't
>> elegantly modify it with a low level general procedural graph.  It's
>> designed for the operator stack.
>>
>> This whole cluster and property inheritance is not to be seen as a
>> "legacy burden", however, but rather it is a large part of the
>> elegance of XSI and what makes it easy to use.  So there is a design
>> and engineering conflict there.  I think the team pretty much did go
>> as far as they could in the totally reasonable implementation approach
>> that it adopted, except perhaps we didn't NURBS support if I recall.
>>
>> There was a similar problem with ICE Kinematic, where we could have
>> gone just not care about breaking all the Softimage tools and workflow
>> people are used to and tell people to just rebuild everything. ICE
>> Kinematic took instead the more conservative approach of allowing you
>> connecting to the existing Kinematic property rather than allowing you
>> to define your own arbitrary property (with maybe just a "rotateZ"
>> parameter). Helge had something working with that second approach, but
>> there would have been so much stuff to redo.
>>
>
>

Re: this is the end......

[Mirko Jankovic]

wait what" if I understood well it was "don't do anything for animation
and rigging, but do something else?" :(


On Wed, Feb 3, 2016 at 3:28 PM, Luc-Eric Rousseau 
wrote:

> There is kind of an architectural glass ceilling with ICE modeling,
> unfortunately.
> As it's implemented, it's like writing a script that calls the functions
> we have
> internally, there is no actual geometry going through the ICE graph.
>
> I'm more curious about what we could have done for animation and rigging,
> and what the dev team could have done instead of ViewportHD
> or ICE Crowd.  If I recall correctly, nobody really knew what to do
> next back then,
> the only opinion I had was "not these two".  Motion graphics stuff,
> perhaps.
>
> On 3 February 2016 at 02:46, Gerbrand Nel  wrote:
> > I agree.
> > Softimage is like those nice spaceship Lego sets, with specialized shapes
> > and parts, to help you build something awesome quick.
> > Houdini is just a shit-load of the basic square Lego bricks, with a few
> of
> > the level 35 lego technic parts thrown into the mix.
> > You want something awesome, you better build it all from scratch.
> > Don't get me wrong.. I'm loving it, but I miss the simplicity of the day
> to
> > day things in soft
> >
> > On 03/02/2016 09:15, Olivier Jeannel wrote:
> >>
> >> I'm digging houdini, but although it has more brutal power, it is way
> more
> >> convoluted.
> >
> >
>



-- 
Mirko Jankovic
skype: mirko-jankovic
https://vimeo.com/mirkoj

Need some help with rendering an Redshift project?
http://www.gpuoven.com/

Re: this is the end......

[Luc-Eric Rousseau]

There is kind of an architectural glass ceilling with ICE modeling,
unfortunately.
As it's implemented, it's like writing a script that calls the functions we have
internally, there is no actual geometry going through the ICE graph.

I'm more curious about what we could have done for animation and rigging,
and what the dev team could have done instead of ViewportHD
or ICE Crowd.  If I recall correctly, nobody really knew what to do
next back then,
the only opinion I had was "not these two".  Motion graphics stuff, perhaps.

On 3 February 2016 at 02:46, Gerbrand Nel  wrote:
> I agree.
> Softimage is like those nice spaceship Lego sets, with specialized shapes
> and parts, to help you build something awesome quick.
> Houdini is just a shit-load of the basic square Lego bricks, with a few of
> the level 35 lego technic parts thrown into the mix.
> You want something awesome, you better build it all from scratch.
> Don't get me wrong.. I'm loving it, but I miss the simplicity of the day to
> day things in soft
>
> On 03/02/2016 09:15, Olivier Jeannel wrote:
>>
>> I'm digging houdini, but although it has more brutal power, it is way more
>> convoluted.
>
>

Re: this is the end......

[Dan Yargici]

I'm pretty sure Luc-Eric meant "not HQViewport and ICE Crowds" Mirko.

DAN

On Wed, Feb 3, 2016 at 2:31 PM, Mirko Jankovic 
wrote:

> wait what" if I understood well it was "don't do anything for
> animation and rigging, but do something else?" :(
>
>
> On Wed, Feb 3, 2016 at 3:28 PM, Luc-Eric Rousseau 
> wrote:
>
>> There is kind of an architectural glass ceilling with ICE modeling,
>> unfortunately.
>> As it's implemented, it's like writing a script that calls the functions
>> we have
>> internally, there is no actual geometry going through the ICE graph.
>>
>> I'm more curious about what we could have done for animation and rigging,
>> and what the dev team could have done instead of ViewportHD
>> or ICE Crowd.  If I recall correctly, nobody really knew what to do
>> next back then,
>> the only opinion I had was "not these two".  Motion graphics stuff,
>> perhaps.
>>
>> On 3 February 2016 at 02:46, Gerbrand Nel  wrote:
>> > I agree.
>> > Softimage is like those nice spaceship Lego sets, with specialized
>> shapes
>> > and parts, to help you build something awesome quick.
>> > Houdini is just a shit-load of the basic square Lego bricks, with a few
>> of
>> > the level 35 lego technic parts thrown into the mix.
>> > You want something awesome, you better build it all from scratch.
>> > Don't get me wrong.. I'm loving it, but I miss the simplicity of the
>> day to
>> > day things in soft
>> >
>> > On 03/02/2016 09:15, Olivier Jeannel wrote:
>> >>
>> >> I'm digging houdini, but although it has more brutal power, it is way
>> more
>> >> convoluted.
>> >
>> >
>>
>
>
>
> --
> Mirko Jankovic
> skype: mirko-jankovic
> https://vimeo.com/mirkoj
>
> Need some help with rendering an Redshift project?
> http://www.gpuoven.com/
>

Re: this is the end......

[Dan Yargici]

...and I'd have agreed with him too for what it's worth!

On Wed, Feb 3, 2016 at 2:43 PM, Dan Yargici  wrote:

> I'm pretty sure Luc-Eric meant "not HQViewport and ICE Crowds" Mirko.
>
> DAN
>
> On Wed, Feb 3, 2016 at 2:31 PM, Mirko Jankovic 
> wrote:
>
>> wait what" if I understood well it was "don't do anything for
>> animation and rigging, but do something else?" :(
>>
>>
>> On Wed, Feb 3, 2016 at 3:28 PM, Luc-Eric Rousseau 
>> wrote:
>>
>>> There is kind of an architectural glass ceilling with ICE modeling,
>>> unfortunately.
>>> As it's implemented, it's like writing a script that calls the functions
>>> we have
>>> internally, there is no actual geometry going through the ICE graph.
>>>
>>> I'm more curious about what we could have done for animation and rigging,
>>> and what the dev team could have done instead of ViewportHD
>>> or ICE Crowd.  If I recall correctly, nobody really knew what to do
>>> next back then,
>>> the only opinion I had was "not these two".  Motion graphics stuff,
>>> perhaps.
>>>
>>> On 3 February 2016 at 02:46, Gerbrand Nel  wrote:
>>> > I agree.
>>> > Softimage is like those nice spaceship Lego sets, with specialized
>>> shapes
>>> > and parts, to help you build something awesome quick.
>>> > Houdini is just a shit-load of the basic square Lego bricks, with a
>>> few of
>>> > the level 35 lego technic parts thrown into the mix.
>>> > You want something awesome, you better build it all from scratch.
>>> > Don't get me wrong.. I'm loving it, but I miss the simplicity of the
>>> day to
>>> > day things in soft
>>> >
>>> > On 03/02/2016 09:15, Olivier Jeannel wrote:
>>> >>
>>> >> I'm digging houdini, but although it has more brutal power, it is way
>>> more
>>> >> convoluted.
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Mirko Jankovic
>> skype: mirko-jankovic
>> https://vimeo.com/mirkoj
>>
>> Need some help with rendering an Redshift project?
>> http://www.gpuoven.com/
>>
>
>

RE: Goodbyes (was this is the end...)

[Morten Bartholdy]

Well said Adam, and amen to that.

Morten


Den 2. februar 2016 kl. 19:38 skrev Adam Sale :

> 
> We've had a pretty good run. For me, I remember starting on the original
> si3d list with many of you original si adopters. There were so many
> heavyweights on the list, i drank in all of the information being shared
> for months before i felt knowledgeable enough to post something
> intelligent. That was back when Beckman hosted the si archives.  Then there
> was the infamous discussion list in the days where Porl and Kim led the
> Fnar'ing, Christine posted her cartoons, and Ed was the cheesemeister. Many
> of you on this list have been some of my best mentors, advisors and
> friends, and have felt like a part of my extended family for nearly 20
> years. Like I said to start this post, it's been a pretty good run.
> 
> Adam
> 
> On Feb 2, 2016 10:24 AM, "Scott Lange" < sc...@turbulenceffects.com
>  > wrote:
> > 
> > Cheese!
> > 
> > 
> > 
> > From: softimage-boun...@listproc.autodesk.com
> >  [mailto:
> > softimage-boun...@listproc.autodesk.com
> >  ] On Behalf Of adrian wyer
> > Sent: Tuesday, February 02, 2016 1:02 PM
> > To: softimage@listproc.autodesk.com
> > 
> > Subject: RE: Goodbyes (was this is the end...)
> > 
> > 
> > 
> > what's that... speak up, us old folks don't hear too good... dang gummit,
> > kids today with your ice trees and your terra flops
> > 
> > 
> > 
> > i remember when all this was fields, and the discussion list was all about
> > cheese and monkeys.
> > 
> > 
> > 
> > 
> > 
> > why when i was a lad.. mumble mumble..
> > 
> > 
> > 
> > 
> > 
> > NURSE!!   need some fresh sheets over here
> > 
> > 
> > 
> > a
> > 
> > 
> > 
> > 
> > 
> > From: softimage-boun...@listproc.autodesk.com
> >  [
> > mailto:softimage-boun...@listproc.autodesk.com
> >  ] On Behalf Of Bradley
> > Gabe
> > Sent: 02 February 2016 15:24
> > To: softimage@listproc.autodesk.com
> > 
> > Subject: Re: Goodbyes (was this is the end...)
> > 
> > 
> > 
> > I appreciate the sentiment folks, you've already thanked me enough over the
> > years. :-)
> > 
> > 
> > 
> > For the first time, I am concerned that the list might disappear once and
> > for all, and possibly without warning. At the moment, this has been my only
> > contact with the old user base. I'm afraid if the list goes, I won't be
> > able to keep up as I am being sucked into an entirely different,
> > all-consuming vortex.
> > 
> > 
> > 

Re: this is the end......

[Olivier Jeannel]

Luc Eric, do you mean that ice modeling developpment was in a stall state,
with nothing to do to enhance it because of that glass "ceiling" ?

On Wed, Feb 3, 2016 at 3:44 PM, Dan Yargici  wrote:

> ...and I'd have agreed with him too for what it's worth!
>
> On Wed, Feb 3, 2016 at 2:43 PM, Dan Yargici  wrote:
>
>> I'm pretty sure Luc-Eric meant "not HQViewport and ICE Crowds" Mirko.
>>
>> DAN
>>
>> On Wed, Feb 3, 2016 at 2:31 PM, Mirko Jankovic > > wrote:
>>
>>> wait what" if I understood well it was "don't do anything for
>>> animation and rigging, but do something else?" :(
>>>
>>>
>>> On Wed, Feb 3, 2016 at 3:28 PM, Luc-Eric Rousseau 
>>> wrote:
>>>
 There is kind of an architectural glass ceilling with ICE modeling,
 unfortunately.
 As it's implemented, it's like writing a script that calls the
 functions we have
 internally, there is no actual geometry going through the ICE graph.

 I'm more curious about what we could have done for animation and
 rigging,
 and what the dev team could have done instead of ViewportHD
 or ICE Crowd.  If I recall correctly, nobody really knew what to do
 next back then,
 the only opinion I had was "not these two".  Motion graphics stuff,
 perhaps.

 On 3 February 2016 at 02:46, Gerbrand Nel  wrote:
 > I agree.
 > Softimage is like those nice spaceship Lego sets, with specialized
 shapes
 > and parts, to help you build something awesome quick.
 > Houdini is just a shit-load of the basic square Lego bricks, with a
 few of
 > the level 35 lego technic parts thrown into the mix.
 > You want something awesome, you better build it all from scratch.
 > Don't get me wrong.. I'm loving it, but I miss the simplicity of the
 day to
 > day things in soft
 >
 > On 03/02/2016 09:15, Olivier Jeannel wrote:
 >>
 >> I'm digging houdini, but although it has more brutal power, it is
 way more
 >> convoluted.
 >
 >

>>>
>>>
>>>
>>> --
>>> Mirko Jankovic
>>> skype: mirko-jankovic
>>> https://vimeo.com/mirkoj
>>>
>>> Need some help with rendering an Redshift project?
>>> http://www.gpuoven.com/
>>>
>>
>>
>

Re: this is the end......

[Andres Stephens]

Overriding cluster materials... yeah I had that discovery the other day.  Had 
to reshader each cluster within the pass overrides using laborous scripts!
Is there a work around for that?

 Original message 
From: Sven Constable 
Date: 03/02/2016  18:12  (GMT-05:00)
To: softimage@listproc.autodesk.com
Subject: RE: this is the end..

Nothing wrong with Softimage, except NURBS/curve modeling and overriding 
cluster materials in passes. :)



sven



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Graham Bell
Sent: Wednesday, February 03, 2016 11:13 PM
To: softimage@listproc.autodesk.com
Subject: Re: this is the end..



I'm saying nothing, this is getting too close to becoming a 'where did it go 
all go wrong' type discussion.

On Wed, 3 Feb 2016 at 18:49, Olivier Jeannel  wrote:

Too bad there was no "lead" with a vision for the future of SI. I'm sure people 
would have follow if you guys had a produced some different ways of working and 
thinking... Isn't it what happened to us with ice ? At least for me, before  
XSI 7 I wouldn't believed I'd do some vector math, and 1 month ago I wouldn't 
believe I'd type some criptic vex code.



On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau  wrote:

On 3 February 2016 at 09:57, Olivier Jeannel  wrote:
> Luc Eric, do you mean that ice modeling developpment was in a stall state,
> with nothing to do to enhance it because of that glass "ceiling" ?

Yeah, ICE modelling nodes expose the operator stack's low-level
commands we always had, and we have all the design with clusters and
properties to deal with, etc, and that's limiting.

We did have to do something to add materials IDs that by-passes this,
as you know, because you can't modify a cluster during evaluation and
therefore would not have been able set a local material (kind of a
showstopper!), but the other tools in XSI do not "see" this material
ID concept.

ICE really shines at processing data arrays in parallel, but when it
gets to modeling, you're constructing a linear sequence
single-threaded calls to the geometry engine and you'd need a
different kind of design approach to be able to got the next level -
and then update the rest of XSI to know about those new structures.
Meshes in XSI are not fundamentally arrays of points with attributes,
it's more like there is a mesh and there is a cluster somewhere else,
and then a property which might be inherited, and then, etc.. the
graph is more like a spider web of dependancies and you can't
elegantly modify it with a low level general procedural graph.  It's
designed for the operator stack.

This whole cluster and property inheritance is not to be seen as a
"legacy burden", however, but rather it is a large part of the
elegance of XSI and what makes it easy to use.  So there is a design
and engineering conflict there.  I think the team pretty much did go
as far as they could in the totally reasonable implementation approach
that it adopted, except perhaps we didn't NURBS support if I recall.

There was a similar problem with ICE Kinematic, where we could have
gone just not care about breaking all the Softimage tools and workflow
people are used to and tell people to just rebuild everything. ICE
Kinematic took instead the more conservative approach of allowing you
connecting to the existing Kinematic property rather than allowing you
to define your own arbitrary property (with maybe just a "rotateZ"
parameter). Helge had something working with that second approach, but
there would have been so much stuff to redo.

RE: this is the end......

[Sven Constable]

Nothing wrong with Softimage, except NURBS/curve modeling and overriding 
cluster materials in passes. :)

 

sven 

 

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Graham Bell
Sent: Wednesday, February 03, 2016 11:13 PM
To: softimage@listproc.autodesk.com
Subject: Re: this is the end..

 

I'm saying nothing, this is getting too close to becoming a 'where did it go 
all go wrong' type discussion.

On Wed, 3 Feb 2016 at 18:49, Olivier Jeannel  wrote:

Too bad there was no "lead" with a vision for the future of SI. I'm sure people 
would have follow if you guys had a produced some different ways of working and 
thinking... Isn't it what happened to us with ice ? At least for me, before  
XSI 7 I wouldn't believed I'd do some vector math, and 1 month ago I wouldn't 
believe I'd type some criptic vex code.

 

On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau  wrote:

On 3 February 2016 at 09:57, Olivier Jeannel  wrote:
> Luc Eric, do you mean that ice modeling developpment was in a stall state,
> with nothing to do to enhance it because of that glass "ceiling" ?

Yeah, ICE modelling nodes expose the operator stack's low-level
commands we always had, and we have all the design with clusters and
properties to deal with, etc, and that's limiting.

We did have to do something to add materials IDs that by-passes this,
as you know, because you can't modify a cluster during evaluation and
therefore would not have been able set a local material (kind of a
showstopper!), but the other tools in XSI do not "see" this material
ID concept.

ICE really shines at processing data arrays in parallel, but when it
gets to modeling, you're constructing a linear sequence
single-threaded calls to the geometry engine and you'd need a
different kind of design approach to be able to got the next level -
and then update the rest of XSI to know about those new structures.
Meshes in XSI are not fundamentally arrays of points with attributes,
it's more like there is a mesh and there is a cluster somewhere else,
and then a property which might be inherited, and then, etc.. the
graph is more like a spider web of dependancies and you can't
elegantly modify it with a low level general procedural graph.  It's
designed for the operator stack.

This whole cluster and property inheritance is not to be seen as a
"legacy burden", however, but rather it is a large part of the
elegance of XSI and what makes it easy to use.  So there is a design
and engineering conflict there.  I think the team pretty much did go
as far as they could in the totally reasonable implementation approach
that it adopted, except perhaps we didn't NURBS support if I recall.

There was a similar problem with ICE Kinematic, where we could have
gone just not care about breaking all the Softimage tools and workflow
people are used to and tell people to just rebuild everything. ICE
Kinematic took instead the more conservative approach of allowing you
connecting to the existing Kinematic property rather than allowing you
to define your own arbitrary property (with maybe just a "rotateZ"
parameter). Helge had something working with that second approach, but
there would have been so much stuff to redo.

 

Re: Goodbyes (was this is the end...)

[Jason S]

  
  
On 02/03/16 4:36, Leendert A. Hartog
  wrote:
  
@Jason - Thanks for the compliment!
If and when the need were to
  arise, I would certainly consider it, but not as a sole
  moderator. 

  
  Cool! :) 
  Otherwise perhaps Luc-Eric(?) would also (continue to)  be up to
  the challenge?
  
  But I wouldnt worry to much about it since as you said, such a
  need has been close to non-existant.
  
  
  Also perhaps interesting to note, 
  although the  DS-List
  move (orignally much smaller community) was done quite a while ago
  (2006) it's still going quite strong ;
  
  Many posts about all kinds of solutions 
  Ae Pre-Comp Stretch question
  conform
logic in MC 
  Premiere CC deck control
  MC and Windows 10
  
  
  And some of the recent (dec-jan) DS related threads among
  technical and troubleshooting ones, include ;
  
  DS

11.1.1 running on windows 10 64 bit :)
  
  What

AVID killed DS for
  Joking around about MC drawbacks (still in 2016), like no
  procedural effect trees, longstanding performance issues, and lack
  of things as basic as blending modes.
  
  
  and a few (long) threads about pros & cons of what can
  reasonably replace DS.  
  Viable

DS replacement 
  DS

Replacement
  
  With comments ranging from things like  ,  to  .
  
  At least their situation was perhaps somewhat less difficult (not
  just because it's 2D), 
  as there has been a few different solutions that can come much
  closer to functionality they were use to (mostly relating to
  procedural node-based effects on timeline clips) including ,
  Resolve/Fusion combo, the (pricey & now rental-only)
  Smoke/Flame solutions, and Nuke studio (with AJA hardware)
  
  So perhaps similarly at some point on the 3D side, existing or
  emerging alternatives would evolve in directions making them come
  closer to the main aspects of what could describe "the XSI
  expericence", for me alluding to (the combination of), reliability
  (being able to 'take-it'), -proceduralism-, good overall
  performance & creation speed, versatility (everything working
  with everything), and ease of -advanced- use (for technical
  -artists-),  hopefully happening within the next decade.
  
  
  
  On 02/03/16 4:36, Leendert A. Hartog wrote:


  
  @Jason - Thanks for the compliment!
  If and when the need were to
arise, I would certainly consider it, but not as a sole
moderator. 
  I have learned from my
  time with the si-community that important decisions such as
  banning someone shouldn't be taken by one person alone.
  The si-community has a rule
  that any temporary or permanent ban must be agreed upon by at
  least two moderators.
  That said, IIRC, we only
  once had an incident that seemed to warrant a temporary ban.
  Genuine spammers, however,
  get kicked out without such discretion...
  

  
Greetz
Leendert
AKA Hirazi Blue
  
  



  Greetz
  Leendert
  AKA Hirazi Blue
  Softimage hobbyist, admin at
  si-community.com & xsiforum.de

  
  
On 03/02/2016
  01:14:54, Jason S  wrote:
If such a case would arise,
  Hirazi? Given your excellent job (also in terms of fairness)
  in the rare cases when moderation was required at
  SI-Community, 
  would you be open to moderate the list as well?
  
  
  On 02/02/16 19:01, Jason S wrote:


  
  If we want, we could follow their
example 

http://community.avid.com/forums/p/8263/365964.aspx

(and avoid the all consuming vortex  ¦P )

  

  Ladies &
  Gentlemen: 
  Due to reasons all too convoluted to go into here,
  it has been decided that the original DS list
  hosted at Softimage.com will be closed down. The
  community has taken the situation into our own
  hands and moved to a new home. We've now passed
  270 members. If you'd like to join us, visit the
  list web page at: 
 
  http://groups.google.com/group/DS-List/


  

  

At least for us, all previous messages would be kept and new
ones added at the same 

Re: this is the end......

[Cristobal Infante]

just don't put materials on clusters ;)

On 4 February 2016 at 00:28, Andres Stephens  wrote:

> Overriding cluster materials... yeah I had that discovery the other day.
> Had to reshader each cluster within the pass overrides using laborous
> scripts!
>
> Is there a work around for that?
>
>
>  Original message 
> From: Sven Constable 
> Date: 03/02/2016 18:12 (GMT-05:00)
> To: softimage@listproc.autodesk.com
> Subject: RE: this is the end..
>
> Nothing wrong with Softimage, except NURBS/curve modeling and overriding
> cluster materials in passes. :)
>
>
>
> sven
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Graham Bell
> *Sent:* Wednesday, February 03, 2016 11:13 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: this is the end..
>
>
>
> I'm saying nothing, this is getting too close to becoming a 'where did it
> go all go wrong' type discussion.
>
> On Wed, 3 Feb 2016 at 18:49, Olivier Jeannel 
> wrote:
>
> Too bad there was no "lead" with a vision for the future of SI. I'm sure
> people would have follow if you guys had a produced some different ways of
> working and thinking... Isn't it what happened to us with ice ? At least
> for me, before  XSI 7 I wouldn't believed I'd do some vector math, and 1
> month ago I wouldn't believe I'd type some criptic vex code.
>
>
>
> On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau 
> wrote:
>
> On 3 February 2016 at 09:57, Olivier Jeannel 
> wrote:
> > Luc Eric, do you mean that ice modeling developpment was in a stall
> state,
> > with nothing to do to enhance it because of that glass "ceiling" ?
>
> Yeah, ICE modelling nodes expose the operator stack's low-level
> commands we always had, and we have all the design with clusters and
> properties to deal with, etc, and that's limiting.
>
> We did have to do something to add materials IDs that by-passes this,
> as you know, because you can't modify a cluster during evaluation and
> therefore would not have been able set a local material (kind of a
> showstopper!), but the other tools in XSI do not "see" this material
> ID concept.
>
> ICE really shines at processing data arrays in parallel, but when it
> gets to modeling, you're constructing a linear sequence
> single-threaded calls to the geometry engine and you'd need a
> different kind of design approach to be able to got the next level -
> and then update the rest of XSI to know about those new structures.
> Meshes in XSI are not fundamentally arrays of points with attributes,
> it's more like there is a mesh and there is a cluster somewhere else,
> and then a property which might be inherited, and then, etc.. the
> graph is more like a spider web of dependancies and you can't
> elegantly modify it with a low level general procedural graph.  It's
> designed for the operator stack.
>
> This whole cluster and property inheritance is not to be seen as a
> "legacy burden", however, but rather it is a large part of the
> elegance of XSI and what makes it easy to use.  So there is a design
> and engineering conflict there.  I think the team pretty much did go
> as far as they could in the totally reasonable implementation approach
> that it adopted, except perhaps we didn't NURBS support if I recall.
>
> There was a similar problem with ICE Kinematic, where we could have
> gone just not care about breaking all the Softimage tools and workflow
> people are used to and tell people to just rebuild everything. ICE
> Kinematic took instead the more conservative approach of allowing you
> connecting to the existing Kinematic property rather than allowing you
> to define your own arbitrary property (with maybe just a "rotateZ"
> parameter). Helge had something working with that second approach, but
> there would have been so much stuff to redo.
>
>
>
>

Re: What's going on here? (Vectors in ICE)

[Tim Bolland]

Hi Martin, 2015 SP2. The node no longer crashes which is good, but I have that 
behaviour still. I even checked in an older version and it happens there too. 

Cheers,

Tim

From: Martin Chatterjee 
Sent: Wednesday, February 03, 2016 5:32 PM
To: softimage@listproc.autodesk.com 
Subject: Re: What's going on here? (Vectors in ICE)

Hey there Tim, 

what Softimage version are you using?

AFAIK the Reinterpret Location node has been broken in 2015, but supposedly got 
fixed in 2015 SP2.  Maybe that's the reason?

Cheers, Martin

--
   Martin Chatterjee
 
[ Freelance Technical Director ]
[   http://www.chatterjee.de   ]
[ https://vimeo.com/chatterjee ] 

On Wed, Feb 3, 2016 at 2:10 PM, Tim Bolland  wrote:

  Hi, I'm little stumped with this behavior in ICE. I'm using a static version 
of a mesh to pick up and store curve tangencies. I then use the reinterpret 
location node to grab the stored vectors on an animated copy of the mesh. This 
works as expected and I see the vectors have translated nicely. However If I 
emit particles from the animated mesh and grab the tangency data from the emit 
location, the vectors don't show up 'correctly'. It's as if it's reading the 
tangency from the initial static mesh, or something like that.  

  Has anyone got any ideas what's going on?

  Dropbox image:
  https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0

  Regards,

  Tim

  p.s Sent again with dropbox link instead of attachment

RE: What's going on here? (Vectors in ICE)

[Tim Bolland]

Hey Dan, all the animation is point cache based so I don't think that's it. 
Could there be a work around with the "Point Reference Frame" node? I'm not 
using it but I have seen other compounds that have. Paul Smith's "Cage Strands" 
for example, does something similar and uses it. I've never used it before so 
I'm little in the dark about what it's doing.
Cheers,
Tim

From: danyarg...@gmail.com
Date: Wed, 3 Feb 2016 16:46:10 +
Subject: Re: What's going on here? (Vectors in ICE)
To: softimage@listproc.autodesk.com

Hey Tim,
If I'm not mistaken, you should be multiplying the re-interpreted vectors by 
the global transformation matrix of the re-interpret target object.  Or perhaps 
just it's rotation matrix...
DAN


On Wed, Feb 3, 2016 at 4:40 PM, Tim Bolland  wrote:




Hi Martin, 2015 SP2. The node no longer crashes which is good, but I have 
that behaviour still. I even checked in an older version and it happens there 
too. 
 
Cheers,
 
Tim


 

From: Martin Chatterjee 

Sent: Wednesday, February 03, 2016 5:32 PM
To: softimage@listproc.autodesk.com 

Subject: Re: What's going on here? (Vectors in 
ICE)
 

Hey there Tim, 
 
what Softimage version are you using?
 
AFAIK the Reinterpret Location node has been broken in 2015, but supposedly 
got fixed in 2015 SP2.  Maybe that's the reason?
 
Cheers, Martin
 


--
   Martin 
Chatterjee
 
[ Freelance 
Technical Director ]
[   http://www.chatterjee.de   ]
[ https://vimeo.com/chatterjee ] 

 
On Wed, Feb 3, 2016 at 2:10 PM, Tim Bolland  wrote:


  
  
  Hi, I'm little stumped with this behavior in ICE. I'm using a static 
  version of a mesh to pick up and store curve tangencies. I then use the 
  reinterpret location node to grab the stored vectors on an animated copy of 
  the mesh. This works as expected and I see the vectors have translated 
nicely. 
  However If I emit particles from the animated mesh and grab the tangency data 
  from the emit location, the vectors don't show up 'correctly'. It's as if 
it's 
  reading the tangency from the initial static mesh, or something like 
  that.  
   
  Has anyone got any ideas what's going on?
  
   
  Dropbox image:
  https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0
   
  Regards,
   
  Tim
   
  p.s Sent again with dropbox link instead of attachment
   
   
   
 

  

Re: What's going on here? (Vectors in ICE)

[paul]

Yes, you’ll need to rotate the vectors. THe reinterpret node will find the 
correct location on the identical object, but it wont do anything to the actual 
vectors.

If the object is not deforming, you can just multiply them by the rotation part 
of the SRT of the transformed object.. 

If it IS deforming, you’ll have to use the pointreferenceframe (PRF) of the 
original static object, and the moving one. 
Invert the PRF of the static and multiply it by the moving.. then on the 
vectors “multiply vector by matrix” using that resulting matrix. and they 
should work fine. I think. without checking it makes sense anyway


From: Dan Yargici 
Sent: Wednesday, February 03, 2016 4:46 PM
To: softimage@listproc.autodesk.com 
Subject: Re: What's going on here? (Vectors in ICE)

Hey Tim, 

If I'm not mistaken, you should be multiplying the re-interpreted vectors by 
the global transformation matrix of the re-interpret target object.  Or perhaps 
just it's rotation matrix...

DAN



On Wed, Feb 3, 2016 at 4:40 PM, Tim Bolland  wrote:

  Hi Martin, 2015 SP2. The node no longer crashes which is good, but I have 
that behaviour still. I even checked in an older version and it happens there 
too. 

  Cheers,

  Tim

  From: Martin Chatterjee 
  Sent: Wednesday, February 03, 2016 5:32 PM
  To: softimage@listproc.autodesk.com 
  Subject: Re: What's going on here? (Vectors in ICE)

  Hey there Tim, 

  what Softimage version are you using?

  AFAIK the Reinterpret Location node has been broken in 2015, but supposedly 
got fixed in 2015 SP2.  Maybe that's the reason?

  Cheers, Martin

  --
 Martin Chatterjee
   
  [ Freelance Technical Director ]
  [   http://www.chatterjee.de   ]
  [ https://vimeo.com/chatterjee ] 

  On Wed, Feb 3, 2016 at 2:10 PM, Tim Bolland  wrote:

Hi, I'm little stumped with this behavior in ICE. I'm using a static 
version of a mesh to pick up and store curve tangencies. I then use the 
reinterpret location node to grab the stored vectors on an animated copy of the 
mesh. This works as expected and I see the vectors have translated nicely. 
However If I emit particles from the animated mesh and grab the tangency data 
from the emit location, the vectors don't show up 'correctly'. It's as if it's 
reading the tangency from the initial static mesh, or something like that.  

Has anyone got any ideas what's going on?

Dropbox image:
https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0

Regards,

Tim

p.s Sent again with dropbox link instead of attachment

Re: What's going on here? (Vectors in ICE)

[Martin Chatterjee]

Hey there Tim,

what Softimage version are you using?

AFAIK the Reinterpret Location node has been broken in 2015, but supposedly
got fixed in 2015 SP2.  Maybe that's the reason?

Cheers, Martin

--
   Martin Chatterjee

[ Freelance Technical Director ]
[   http://www.chatterjee.de   ]
[ https://vimeo.com/chatterjee ]

On Wed, Feb 3, 2016 at 2:10 PM, Tim Bolland 
wrote:

> Hi, I'm little stumped with this behavior in ICE. I'm using a static
> version of a mesh to pick up and store curve tangencies. I then use the
> reinterpret location node to grab the stored vectors on an animated copy of
> the mesh. This works as expected and I see the vectors have translated
> nicely. However If I emit particles from the animated mesh and grab the
> tangency data from the emit location, the vectors don't show up
> 'correctly'. It's as if it's reading the tangency from the initial static
> mesh, or something like that.
>
> Has anyone got any ideas what's going on?
>
> Dropbox image:
> https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0
>
> Regards,
>
> Tim
>
> p.s Sent again with dropbox link instead of attachment
>
>
>
>

Re: this is the end......

[Jason S]

  
  
On 02/03/16 13:33, Luc-Eric Rousseau
  wrote:


  Yeah, ICE modelling nodes expose the operator stack's low-level
  commands we always had, and we have all the design with clusters
  and
  properties to deal with, etc, and that's limiting.


I agree.

And although ICE may to this day remain one of the most approachable
visual programming systems, and that it braught the guts out of 3D
for a much more direct access,

after having been 'spoiled' by the construction stack's straight
forward, yet perhaps 'black-boxed' operators,
I still wished (when ICE modeling came) that procedural modeling
could also be more like "direct modeling", (or like a tree view
version of the stack), where you can relatively easily &
-visually- define or select what you want to somehow modify and then
just as simply go ahead and modify,... but with the clarity of
seeing what comes from where, which only freeform nodes layed-out in
space can provide as opposed to stacks, specifically for more
elaborate things.
 
Houdini may come to mind, but I was thinking more of something like
'regular', simple, yet reliable modeling operations, except
nodebased.

and although ICE can be easier to grasp than other procedural
systems, It's no secret that ICE modeling can be quite a challenge
when faced with the varying Per-element contexts, array types,
etc... and much time can be spent on figuring out how to make
connections happen, 
as opposed to the stack with operators, which allows to just do
things very visually and directly, perhaps collapsing 50 move-points
into one concactenated "OffsetComponents", and have some things
remain "live".


On 02/03/16 9:28, Luc-Eric Rousseau
  wrote:


  If I recall correctly, nobody really knew what to do next back then,
the only opinion I had was "not these two".  Motion graphics stuff, perhaps.


There; softimage.uservoice.com
would have been a good place to start, I wonder if management ever
made a trip there, 
with the number one wish being 'ice-ification' of the schematic.

And a revamped front-end to the schematic would no doubt have been
considerably less spaghetti-like than the revamped front-end to the
spaghetti-like hypergraph.


@Graham; Without going too far into 'what-if' scenarios,

   On 02/02/16 17:08, Graham Bell wrote:
    I wish you luck with that. It was hard enough
  trying to sell them Soft and ICE. So Houdini could be
  even harder.

If only had there generally been some  (or not to say  any
sort of) effort on that front, 
other than at best, (re-)presenting it as not much more than a
standalone particle plugin, .. or if only depreciation wasn't the
point.

But rest assured all such things is mostly water under the bridge by
now.


On 02/03/16 13:33, Luc-Eric Rousseau
  wrote:


  On 3 February 2016 at 09:57, Olivier Jeannel  wrote:

  
Luc Eric, do you mean that ice modeling developpment was in a stall state,
with nothing to do to enhance it because of that glass "ceiling" ?

  
  Yeah, ICE modelling nodes expose the operator stack's low-level
commands we always had, and we have all the design with clusters and
properties to deal with, etc, and that's limiting.

We did have to do something to add materials IDs that by-passes this,
as you know, because you can't modify a cluster during evaluation and
therefore would not have been able set a local material (kind of a
showstopper!), but the other tools in XSI do not "see" this material
ID concept.

ICE really shines at processing data arrays in parallel, but when it
gets to modeling, you're constructing a linear sequence
single-threaded calls to the geometry engine and you'd need a
different kind of design approach to be able to got the next level -
and then update the rest of XSI to know about those new structures.
Meshes in XSI are not fundamentally arrays of points with attributes,
it's more like there is a mesh and there is a cluster somewhere else,
and then a property which might be inherited, and then, etc.. the
graph is more like a spider web of dependancies and you can't
elegantly modify it with a low level general procedural graph.  It's
designed for the operator stack.

This whole cluster and property inheritance is not to be seen as a
"legacy burden", however, but rather it is a large part of the
elegance of XSI and what makes it easy to use.  So there is a design
and engineering conflict there.  I think the team pretty much did go
as far as they could in the totally reasonable implementation approach
that it adopted, except perhaps we didn't NURBS support if I recall.

There was a similar problem with ICE Kinematic, where we could have
gone just 

Re: this is the end......

[Stephen Davidson]

Could this help?
http://www.si-community.com/community/viewtopic.php?f=4=5115


Best Regards,
*  Stephen P. Davidson*

*(954) 552-7956*sdavid...@3danimationmagic.com

*Any sufficiently advanced technology is indistinguishable from magic*


 - Arthur C. Clarke



On Wed, Feb 3, 2016 at 7:28 PM Andres Stephens  wrote:

> Overriding cluster materials... yeah I had that discovery the other day.
> Had to reshader each cluster within the pass overrides using laborous
> scripts!
>
> Is there a work around for that?
>
>
>  Original message 
> From: Sven Constable 
> Date: 03/02/2016 18:12 (GMT-05:00)
> To: softimage@listproc.autodesk.com
> Subject: RE: this is the end..
>
> Nothing wrong with Softimage, except NURBS/curve modeling and overriding
> cluster materials in passes. :)
>
>
>
> sven
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Graham Bell
> *Sent:* Wednesday, February 03, 2016 11:13 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: this is the end..
>
>
>
> I'm saying nothing, this is getting too close to becoming a 'where did it
> go all go wrong' type discussion.
>
> On Wed, 3 Feb 2016 at 18:49, Olivier Jeannel 
> wrote:
>
> Too bad there was no "lead" with a vision for the future of SI. I'm sure
> people would have follow if you guys had a produced some different ways of
> working and thinking... Isn't it what happened to us with ice ? At least
> for me, before  XSI 7 I wouldn't believed I'd do some vector math, and 1
> month ago I wouldn't believe I'd type some criptic vex code.
>
>
>
> On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau 
> wrote:
>
> On 3 February 2016 at 09:57, Olivier Jeannel 
> wrote:
> > Luc Eric, do you mean that ice modeling developpment was in a stall
> state,
> > with nothing to do to enhance it because of that glass "ceiling" ?
>
> Yeah, ICE modelling nodes expose the operator stack's low-level
> commands we always had, and we have all the design with clusters and
> properties to deal with, etc, and that's limiting.
>
> We did have to do something to add materials IDs that by-passes this,
> as you know, because you can't modify a cluster during evaluation and
> therefore would not have been able set a local material (kind of a
> showstopper!), but the other tools in XSI do not "see" this material
> ID concept.
>
> ICE really shines at processing data arrays in parallel, but when it
> gets to modeling, you're constructing a linear sequence
> single-threaded calls to the geometry engine and you'd need a
> different kind of design approach to be able to got the next level -
> and then update the rest of XSI to know about those new structures.
> Meshes in XSI are not fundamentally arrays of points with attributes,
> it's more like there is a mesh and there is a cluster somewhere else,
> and then a property which might be inherited, and then, etc.. the
> graph is more like a spider web of dependancies and you can't
> elegantly modify it with a low level general procedural graph.  It's
> designed for the operator stack.
>
> This whole cluster and property inheritance is not to be seen as a
> "legacy burden", however, but rather it is a large part of the
> elegance of XSI and what makes it easy to use.  So there is a design
> and engineering conflict there.  I think the team pretty much did go
> as far as they could in the totally reasonable implementation approach
> that it adopted, except perhaps we didn't NURBS support if I recall.
>
> There was a similar problem with ICE Kinematic, where we could have
> gone just not care about breaking all the Softimage tools and workflow
> people are used to and tell people to just rebuild everything. ICE
> Kinematic took instead the more conservative approach of allowing you
> connecting to the existing Kinematic property rather than allowing you
> to define your own arbitrary property (with maybe just a "rotateZ"
> parameter). Helge had something working with that second approach, but
> there would have been so much stuff to redo.
>
>
>
>

Re: What's going on here? (Vectors in ICE)

[Martin Chatterjee]

Hey Tim,

yeah, I'd like to suggest storing your vectors in PointReference mode.

You can think of PointReferenceFrame as the local coordinate system of the
vertex:  Y being the normal direction and X pointing towards the first
neighbor vertex.

If you select a vertex of a polygon mesh, enter the Translate tool and
switch to "Local" then that's the coordinate system represented by
PointReferenceFrame.


*So, try something like this for storing :*

YourVectorPerPoint   >
 MultiplyVectorByMatrix  ---> SetData(self.crvTanAvg)
  /
GetData(self.PointReferenceFrame) >  Invert -/



*And then this for retrieving and applying:*

GetClosestLocation --->  GetData(crvTanAvg)  -->
 MultiplyVectorByMatrix  ---> SetData(self.tmp)
/
  GetData(self.PointReferenceFrame) ---/



Cheers, -M


--
   Martin Chatterjee

[ Freelance Technical Director ]
[   http://www.chatterjee.de   ]
[ https://vimeo.com/chatterjee ]

On Wed, Feb 3, 2016 at 5:53 PM, Tim Bolland 
wrote:

> Hey Dan, all the animation is point cache based so I don't think that's
> it. Could there be a work around with the "Point Reference Frame" node? I'm
> not using it but I have seen other compounds that have. Paul Smith's "Cage
> Strands" for example, does something similar and uses it. I've never used
> it before so I'm little in the dark about what it's doing.
>
> Cheers,
>
> Tim
>
> --
> From: danyarg...@gmail.com
> Date: Wed, 3 Feb 2016 16:46:10 +
> Subject: Re: What's going on here? (Vectors in ICE)
> To: softimage@listproc.autodesk.com
>
>
> Hey Tim,
>
> If I'm not mistaken, you should be multiplying the re-interpreted vectors
> by the global transformation matrix of the re-interpret target object.  Or
> perhaps just it's rotation matrix...
>
> DAN
>
>
>
> On Wed, Feb 3, 2016 at 4:40 PM, Tim Bolland 
> wrote:
>
> Hi Martin, 2015 SP2. The node no longer crashes which is good, but I have
> that behaviour still. I even checked in an older version and it happens
> there too.
>
> Cheers,
>
> Tim
>
> *From:* Martin Chatterjee 
> *Sent:* Wednesday, February 03, 2016 5:32 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: What's going on here? (Vectors in ICE)
>
> Hey there Tim,
>
> what Softimage version are you using?
>
> AFAIK the Reinterpret Location node has been broken in 2015, but
> supposedly got fixed in 2015 SP2.  Maybe that's the reason?
>
> Cheers, Martin
>
> --
>Martin Chatterjee
>
> [ Freelance Technical Director ]
> [   http://www.chatterjee.de   ]
> [ https://vimeo.com/chatterjee ]
>
> On Wed, Feb 3, 2016 at 2:10 PM, Tim Bolland 
> wrote:
>
> Hi, I'm little stumped with this behavior in ICE. I'm using a static
> version of a mesh to pick up and store curve tangencies. I then use the
> reinterpret location node to grab the stored vectors on an animated copy of
> the mesh. This works as expected and I see the vectors have translated
> nicely. However If I emit particles from the animated mesh and grab the
> tangency data from the emit location, the vectors don't show up
> 'correctly'. It's as if it's reading the tangency from the initial static
> mesh, or something like that.
>
> Has anyone got any ideas what's going on?
>
> Dropbox image:
> https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0
>
> Regards,
>
> Tim
>
> p.s Sent again with dropbox link instead of attachment
>
>
>
>
>
>
>
>

RE: What's going on here? (Vectors in ICE)

[Tim Bolland]

Thank you guys! I'll take a look at these solutions :) 
Date: Wed, 3 Feb 2016 18:11:28 +0100
Subject: Re: What's going on here? (Vectors in ICE)
From: martin.chatterjee.li...@googlemail.com
To: softimage@listproc.autodesk.com

Hey Tim,
yeah, I'd like to suggest storing your vectors in PointReference mode. 
You can think of PointReferenceFrame as the local coordinate system of the 
vertex:  Y being the normal direction and X pointing towards the first neighbor 
vertex.
If you select a vertex of a polygon mesh, enter the Translate tool and switch 
to "Local" then that's the coordinate system represented by PointReferenceFrame.

So, try something like this for storing :
YourVectorPerPoint   >  
MultiplyVectorByMatrix  ---> SetData(self.crvTanAvg)
  /GetData(self.PointReferenceFrame) >  Invert 
-/


And then this for retrieving and applying:
GetClosestLocation --->  GetData(crvTanAvg)  -->  
MultiplyVectorByMatrix  ---> SetData(self.tmp)  
  /  
GetData(self.PointReferenceFrame) ---/

 Cheers, -M
--
   Martin Chatterjee
 
[ Freelance Technical Director ]
[   http://www.chatterjee.de   ][ https://vimeo.com/chatterjee ] 

On Wed, Feb 3, 2016 at 5:53 PM, Tim Bolland  wrote:



Hey Dan, all the animation is point cache based so I don't think that's it. 
Could there be a work around with the "Point Reference Frame" node? I'm not 
using it but I have seen other compounds that have. Paul Smith's "Cage Strands" 
for example, does something similar and uses it. I've never used it before so 
I'm little in the dark about what it's doing.
Cheers,
Tim

From: danyarg...@gmail.com
Date: Wed, 3 Feb 2016 16:46:10 +
Subject: Re: What's going on here? (Vectors in ICE)
To: softimage@listproc.autodesk.com

Hey Tim,
If I'm not mistaken, you should be multiplying the re-interpreted vectors by 
the global transformation matrix of the re-interpret target object.  Or perhaps 
just it's rotation matrix...
DAN


On Wed, Feb 3, 2016 at 4:40 PM, Tim Bolland  wrote:




Hi Martin, 2015 SP2. The node no longer crashes which is good, but I have 
that behaviour still. I even checked in an older version and it happens there 
too. 
 
Cheers,
 
Tim


 

From: Martin Chatterjee 

Sent: Wednesday, February 03, 2016 5:32 PM
To: softimage@listproc.autodesk.com 

Subject: Re: What's going on here? (Vectors in 
ICE)
 

Hey there Tim, 
 
what Softimage version are you using?
 
AFAIK the Reinterpret Location node has been broken in 2015, but supposedly 
got fixed in 2015 SP2.  Maybe that's the reason?
 
Cheers, Martin
 


--
   Martin 
Chatterjee
 
[ Freelance 
Technical Director ]
[   http://www.chatterjee.de   ]
[ https://vimeo.com/chatterjee ] 

 
On Wed, Feb 3, 2016 at 2:10 PM, Tim Bolland  wrote:


  
  
  Hi, I'm little stumped with this behavior in ICE. I'm using a static 
  version of a mesh to pick up and store curve tangencies. I then use the 
  reinterpret location node to grab the stored vectors on an animated copy of 
  the mesh. This works as expected and I see the vectors have translated 
nicely. 
  However If I emit particles from the animated mesh and grab the tangency data 
  from the emit location, the vectors don't show up 'correctly'. It's as if 
it's 
  reading the tangency from the initial static mesh, or something like 
  that.  
   
  Has anyone got any ideas what's going on?
  
   
  Dropbox image:
  https://www.dropbox.com/s/nmomf3jkg2r81d8/VectorsAlign.jpg?dl=0
   
  Regards,
   
  Tim
   
  p.s Sent again with dropbox link instead of attachment
   
   
   
 

  

  

Re: this is the end......

[Olivier Jeannel]

Too bad there was no "lead" with a vision for the future of SI. I'm sure
people would have follow if you guys had a produced some different ways of
working and thinking... Isn't it what happened to us with ice ? At least
for me, before  XSI 7 I wouldn't believed I'd do some vector math, and 1
month ago I wouldn't believe I'd type some criptic vex code.

On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau 
wrote:

> On 3 February 2016 at 09:57, Olivier Jeannel 
> wrote:
> > Luc Eric, do you mean that ice modeling developpment was in a stall
> state,
> > with nothing to do to enhance it because of that glass "ceiling" ?
>
> Yeah, ICE modelling nodes expose the operator stack's low-level
> commands we always had, and we have all the design with clusters and
> properties to deal with, etc, and that's limiting.
>
> We did have to do something to add materials IDs that by-passes this,
> as you know, because you can't modify a cluster during evaluation and
> therefore would not have been able set a local material (kind of a
> showstopper!), but the other tools in XSI do not "see" this material
> ID concept.
>
> ICE really shines at processing data arrays in parallel, but when it
> gets to modeling, you're constructing a linear sequence
> single-threaded calls to the geometry engine and you'd need a
> different kind of design approach to be able to got the next level -
> and then update the rest of XSI to know about those new structures.
> Meshes in XSI are not fundamentally arrays of points with attributes,
> it's more like there is a mesh and there is a cluster somewhere else,
> and then a property which might be inherited, and then, etc.. the
> graph is more like a spider web of dependancies and you can't
> elegantly modify it with a low level general procedural graph.  It's
> designed for the operator stack.
>
> This whole cluster and property inheritance is not to be seen as a
> "legacy burden", however, but rather it is a large part of the
> elegance of XSI and what makes it easy to use.  So there is a design
> and engineering conflict there.  I think the team pretty much did go
> as far as they could in the totally reasonable implementation approach
> that it adopted, except perhaps we didn't NURBS support if I recall.
>
> There was a similar problem with ICE Kinematic, where we could have
> gone just not care about breaking all the Softimage tools and workflow
> people are used to and tell people to just rebuild everything. ICE
> Kinematic took instead the more conservative approach of allowing you
> connecting to the existing Kinematic property rather than allowing you
> to define your own arbitrary property (with maybe just a "rotateZ"
> parameter). Helge had something working with that second approach, but
> there would have been so much stuff to redo.
>