Re: Emit particles from camera FOV

[peter_b]

Do check the recent “ICE test vector inside cone” thread here – that should 
provide the basis for solving camera frustrum, which you can use for anything, 
such as filter on emission.

Also: simply model a frustrum box, constrained to camera, and use delete by 
volume.
Wether or not deleting points plays nice with your pointcloud is a bit 
unpredictable. (see: all particles disappearing on random frames, bounding box 
of the cloud disappearing on random frames rendering the cloud unrenderable – 
shudders... ) 
Other than that – I find delete by volume quite handy in optimising pointclouds 
– getting rid of stuff that’s not needed, not visible or just stray particles.


From: Gene Crucean 
Sent: Monday, March 04, 2013 10:58 PM
To: softimage@listproc.autodesk.com 
Subject: Re: Emit particles from camera FOV

Sheesh. Didn't even get a chance to try myself yet lol. This list can be pretty 
fast at times. 

Thanks Vincent I'll play with it in a bit.



On Mon, Mar 4, 2013 at 10:36 AM, Vincent Ullmann 
 wrote:

  maybe this could help:

  a compound that creates a Grid of "Pixels" in front of your connected cam, 
and orients them properly...

  now you just have to press "Strg+A" and "Strg+G" to create a Group of your 
scene.
  then: do a raycast from each point along its orientation (rotate vector + 
particle ori). (do this on emit)
  if you have all this on a simulated ice-tree it should add new particles each 
frame... so you clould "paint"

  Am 04.03.2013 19:22, schrieb Gene Crucean:

Well it's a little more complicated than that because I need to "paint" 
with the fov :) 

So the accumulation of particles over time is required.



On Mon, Mar 4, 2013 at 9:08 AM, Alok Gandhi  
wrote:

  Hmmm, I think I have done it once for an effect. The workflow was really 
not that straight. I was emitting particles from a ground mesh. As a first 
pass, I was writing a weight map on the geo based on the camera move, setting 
value of 1.0 for all vertex in fov and 0 for non-visible. Then I froze the 
weight map. And in the sim, I was filtering the emission by this weight map. 

  But there can be other simpler ways around it depending use case 
scenario. One way that I think of right off my head is to delete particles not 
in view. But this can be time consuming if you have high particle density and 
only a small part of it visible to fov.






-- 

Gene Crucean - Emmy winning - Oscar nominated CG Supervisor / iOS-OSX 
Developer / Filmmaker / Photographer

** Freelance for hire **
www.genecrucean.com

~~ Please use my website's contact form on www.genecrucean.com for any 
personal emails. Thanks. I may not get them at this address. ~~






-- 

Gene Crucean - Emmy winning - Oscar nominated CG Supervisor / iOS-OSX Developer 
/ Filmmaker / Photographer

** Freelance for hire **
www.genecrucean.com

~~ Please use my website's contact form on www.genecrucean.com for any personal 
emails. Thanks. I may not get them at this address. ~~

Re: Emit particles from camera FOV

[Dan Yargici]

You all know there's a factory 'Test Visibility From Camera' node, right?
 :)

DAN


On Tue, Mar 5, 2013 at 8:13 AM,  wrote:

>   Do check the recent “ICE test vector inside cone” thread here – that
> should provide the basis for solving camera frustrum, which you can use for
> anything, such as filter on emission.
>
> Also: simply model a frustrum box, constrained to camera, and use delete
> by volume.
> Wether or not deleting points plays nice with your pointcloud is a bit
> unpredictable. (see: all particles disappearing on random frames, bounding
> box of the cloud disappearing on random frames rendering the cloud
> unrenderable – shudders... )
>  Other than that – I find delete by volume quite handy in optimising
> pointclouds – getting rid of stuff that’s not needed, not visible or just
> stray particles.
>
>
>  *From:* Gene Crucean 
> *Sent:* Monday, March 04, 2013 10:58 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Emit particles from camera FOV
>
>  Sheesh. Didn't even get a chance to try myself yet lol. This list can be
> pretty fast at times.
>
> Thanks Vincent I'll play with it in a bit.
>
>
> On Mon, Mar 4, 2013 at 10:36 AM, Vincent Ullmann <
> vincent.ullm...@googlemail.com> wrote:
>
>>  maybe this could help:
>>
>> a compound that creates a Grid of "Pixels" in front of your connected
>> cam, and orients them properly...
>>
>> now you just have to press "Strg+A" and "Strg+G" to create a Group of
>> your scene.
>> then: do a raycast from each point along its orientation (rotate vector +
>> particle ori). (do this on emit)
>> if you have all this on a simulated ice-tree it should add new particles
>> each frame... so you clould "paint"
>>
>> Am 04.03.2013 19:22, schrieb Gene Crucean:
>>
>> Well it's a little more complicated than that because I need to "paint"
>> with the fov :)
>>
>> So the accumulation of particles over time is required.
>>
>>
>> On Mon, Mar 4, 2013 at 9:08 AM, Alok Gandhi wrote:
>>
>>> Hmmm, I think I have done it once for an effect. The workflow was really
>>> not that straight. I was emitting particles from a ground mesh. As a first
>>> pass, I was writing a weight map on the geo based on the camera move,
>>> setting value of 1.0 for all vertex in fov and 0 for non-visible. Then I
>>> froze the weight map. And in the sim, I was filtering the emission by this
>>> weight map.
>>>
>>> But there can be other simpler ways around it depending use case
>>> scenario. One way that I think of right off my head is to delete particles
>>> not in view. But this can be time consuming if you have high particle
>>> density and only a small part of it visible to fov.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Gene Crucean - Emmy winning - Oscar nominated CG Supervisor / iOS-OSX
>> Developer / Filmmaker / Photographer
>> ** *Freelance for hire* **
>> www.genecrucean.com
>>
>> ~~ Please use my website's contact form on www.genecrucean.com for any
>> personal emails. Thanks. I may not get them at this address. ~~
>>
>>
>>
>
>
> --
> Gene Crucean - Emmy winning - Oscar nominated CG Supervisor / iOS-OSX
> Developer / Filmmaker / Photographer
> ** *Freelance for hire* **
> www.genecrucean.com
>
> ~~ Please use my website's contact form on www.genecrucean.com for any
> personal emails. Thanks. I may not get them at this address. ~~
>

MOMA - Modo for Maya

[Paul Griswold]

This is pretty cool:

http://www.jacobobarreiro.com/jweb/moma/

Since there are plenty of Softimage to _ connections for various render
engines, would something like this be possible for Soft?

Having Modo's preview window in Softimage would be pretty slick.

He's also got a version for Nuke and in one video compares MOMA to SItoA,
which is really interesting.

Paul

RE: ice crowds and rendering

[Jeff McFall]

Just wanted to say thanks again for the help on this and a big thanks to 
Fabricio for sending that compound.
These texture issues I was having seem to be alleviated by using this compound.
In addition I was also having all sort of problems with the crowd not sticking 
to the ground and with custom variables not being read correctly by the render 
tree.  With a few tweaks of this compound all of the issues I was having  seem 
fixed and all is working as expected now.

What a drag to have gone around in circles so many times trying to fix this.  I 
recall seeing the topic of these problems being caused by overly aggressive 
optimization before but had not assumed it was as widespread as I was 
experiencing.  This was really key a lot of the problems I was having and I am 
looking forward to more warm dinners in my future.

Also thanks to Adam and Stephen for their insight and suggestion on the issue 
as well.  Being a somewhat isolated user I would never be able to make as much 
use of this software without all the help and insight this list provides.

Jeff





From: Jeff McFall
Sent: Tuesday, February 26, 2013 8:58 PM
To: 'softimage@listproc.autodesk.com'
Subject: RE: ice crowds and rendering

Thanks all, this compound seemed to lock them pretty well in my first test.


From: 
softimage-boun...@listproc.autodesk.com
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Fabricio Chamon
Sent: Tuesday, February 26, 2013 3:40 PM
To: softimage@listproc.autodesk.com
Subject: Re: ice crowds and rendering

I do what Adam said...but before I make sure the ice projection is calculated 
correclty (not bypassed by those evil ice optimizations) by using the attached 
compound at the very end of in the first icetree on each "actor_copies" mesh. 
It's really simple, it ensures the attribute is set by using it inside a null 
equation that get/set point positions.



2013/2/26 Jeff McFall mailto:jeff.mcf...@sas.com>>
Thanks Adam, I appreciate your response
Yeah, I have done that a gazillion times and they still seem to disconnect when 
rendering.  Though I have been jiggling with the materials quite a bit...
However I'll try again as my experience seems to indicate that things magically 
begin to work *after* after posting on the list

I don't do much scripting so would like to ask if it is conceivable that one 
could create a script that would execute every frame and snap those connections 
together?

Thanks again
Jeff


From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Adam Sale
Sent: Tuesday, February 26, 2013 1:37 PM
To: softimage@listproc.autodesk.com
Subject: Re: ice crowds and rendering

Hi Jeff.. This is a known issue for sure.

I work around the issue by doing the following,

I generally just get in and edit the texture projection in the render tree per 
image node on each actor copy. You have to point each image to the 
TextureProjection UV available to each ActorCopy.)
On the Mesh Proxy you have to set the UV's to the correct projection in the Set 
Mesh Proxy compound in the ICE tree.

Once I do that, I have no problems with textures showing on rendered sequences.

Adam

On Tue, Feb 26, 2013 at 9:08 AM, Jeff McFall 
mailto:jeff.mcf...@sas.com>> wrote:
I have been working with crowds and am excited about some of the results I am 
getting but have one nagging problem that I have not been able to overcome.

That problem has to do with rendering and the fact that texture projections 
seem to become broken/disconnected from the material when the job distributed 
to a farm (we are using RR).
When submitting jobs as a continuous sequence that begin on the first frame 
(frame 1) all seems to work fine.  However when the job is spread across 
machines the textures are broken.

As a quick overview of my setup I am using an random integer to drive a color 
switch in the render tree which basically selects the appropriate texture.
As I said this all works fine as long as I render from the first frame of the 
sequence.

Just a guess but I suspect this has something to do with the fact that the 
texture projections are created when the ice tree initializes on the first 
frame.
Has anyone else experienced this and maybe know of a fix or workaround?

I am wondering if I can tweak the scene or render software somehow to force the 
simulation to begin on frame 1 for each frame rendered?
Seems I recall some scripts that may do this but I have been unable to track 
any down.

Any suggestions much appreciated
Thanks
Jeff

Video codecs no longer working for Viewport Capture...

[Tim Crowson]

Just a month ago I was able to export viewport captures as QuickTime 
files. Now, when I click on the 'Codec' button, if either QuickTime or 
AVI is selected as the format, I get the following error:


/'Could not create the file and initialize the render - verify the path'/

I'm not sure what path it's talking about. This happens in both 2012 SAP 
and 2013...


--
Signature

*Tim Crowson
*/Lead CG Artist/

*Magnetic Dreams, Inc.
*2525 Lebanon Pike, Building C. Nashville, TN 37214
*Ph*  615.885.6801 | *Fax*  615.889.4768 | www.magneticdreams.com
tim.crow...@magneticdreams.com

/Confidentiality Notice: This email, including attachments, is 
confidential and should not be used by anyone who is not the original 
intended recipient(s). If you have received this e-mail in error please 
inform the sender and delete it from your mailbox or any other storage 
mechanism. Magnetic Dreams, Inc cannot accept liability for any 
statements made which are clearly the sender's own and not expressly 
made on behalf of Magnetic Dreams, Inc or one of its agents./

Re: Video codecs no longer working for Viewport Capture...

[Matt Morris]

I've had problems with this when its trying to output to a network drive.
It didn't give me any issues outputting locally.



On 5 March 2013 16:20, Tim Crowson  wrote:

>  Just a month ago I was able to export viewport captures as QuickTime
> files. Now, when I click on the 'Codec' button, if either QuickTime or AVI
> is selected as the format, I get the following error:
>
> *'Could not create the file and initialize the render - verify the path'*
>
> I'm not sure what path it's talking about. This happens in both 2012 SAP
> and 2013...
>
> --
>
>
>
> *Tim Crowson
> **Lead CG Artist*
>
> *Magnetic Dreams, Inc.
> *2525 Lebanon Pike, Building C. Nashville, TN 37214
> *Ph*  615.885.6801 | *Fax*  615.889.4768 | www.magneticdreams.com
> tim.crow...@magneticdreams.com
>
> *Confidentiality Notice: This email, including attachments, is
> confidential and should not be used by anyone who is not the original
> intended recipient(s). If you have received this e-mail in error please
> inform the sender and delete it from your mailbox or any other storage
> mechanism. Magnetic Dreams, Inc cannot accept liability for any statements
> made which are clearly the sender's own and not expressly made on behalf of
> Magnetic Dreams, Inc or one of its agents.*
>
>
>



-- 
www.matinai.com

importing OLD models

[Neil Kidney]

Hey folks,
 
Trying to import models from 2006 ish (so whatever version that was. v5 or
v6?) Into 2012, but getting 
Missing object to load this model . object missing is [[CLSID\
Have tried various other models from 2006 - 2008 that we have and getting
the same error so I assume it's not bug in the model.
 
Anyone know anything about it?
 
Cheers.
 
 

Re: importing OLD models

[Eric Thivierge]

Usually means it's missing a shader or plug-in. Some known ones:
http://softimage.wiki.softimage.com/index.php?title=CLSID_Reference


Eric Thivierge
http://www.ethivierge.com


On Tue, Mar 5, 2013 at 11:32 AM, Neil Kidney wrote:

> Hey folks,
>
> ** **
>
> Trying to import models from 2006 ish (so whatever version that was… v5
> or v6?) Into 2012, but getting 
>
> Missing object to load this model … object missing is [[CLSID\
>
> Have tried various other models from 2006 – 2008 that we have and getting
> the same error so I assume it’s not bug in the model.
>
> ** **
>
> Anyone know anything about it?
>
> ** **
>
> Cheers.
>
> ** **
>
> ** **
>

Re: Video codecs no longer working for Viewport Capture...

[Tim Crowson]

I get the error no matter where I'm outputting the file. Local or Network.
-Tim

On 3/5/2013 10:25 AM, Matt Morris wrote:
I've had problems with this when its trying to output to a network 
drive. It didn't give me any issues outputting locally.




On 5 March 2013 16:20, Tim Crowson > wrote:


Just a month ago I was able to export viewport captures as
QuickTime files. Now, when I click on the 'Codec' button, if
either QuickTime or AVI is selected as the format, I get the
following error:

/'Could not create the file and initialize the render - verify the
path'/

I'm not sure what path it's talking about. This happens in both
2012 SAP and 2013...

-- 


*Tim Crowson
*/Lead CG Artist/

*Magnetic Dreams, Inc.
*2525 Lebanon Pike, Building C. Nashville, TN 37214
*Ph* 615.885.6801  | *Fax* 615.889.4768
 | www.magneticdreams.com

tim.crow...@magneticdreams.com 

/Confidentiality Notice: This email, including attachments, is
confidential and should not be used by anyone who is not the
original intended recipient(s). If you have received this e-mail
in error please inform the sender and delete it from your mailbox
or any other storage mechanism. Magnetic Dreams, Inc cannot accept
liability for any statements made which are clearly the sender's
own and not expressly made on behalf of Magnetic Dreams, Inc or
one of its agents./




--
www.matinai.com 


--
Signature

Re: Video codecs no longer working for Viewport Capture...

[Stephen Blair]

Sounds like a job for Process Monitor. Find out what file that cryptic 
error is talking about.




On December 11, 2009 at 4:23 PM Bradley Gabe > wrote:


> I'm not saying this is your issue, but I tend to do this a lot where 
I start
> a capture session, notice something is wrong, then cancel it 
immediately. I
> fix the issue and then try to recapture, don't notice that my last 
capture

> is already open on my system. There is no file overwrite warning or any
> other notification, my capture session simply terminates when it cannot
> overwrite the file on the first frame.
>
> Not everyone is aware that Quicktime, on windows at least, tends to 
open a
> file for writing before it writes the captured movie stream. The 
moment you

> press that codec button, you've got an open file. I've seen issues when
> someone, for example, tries to set the codec first, change the filepath,
> then do a capture. Sometimes the default filepath in the capture window
> points to a valid, local, temp location, and then when setting the 
desired

> capture path to something else, say, a production path over a network for
> dailies, the destination doesn't actually exist or is read only.
>
> I suspect that the fact Quicktime opens files for writing header info 
prior
> to capture makes it difficult to interrupt the process and notify the 
user

> that a file is about to get overwritten. Instead, the way we learn that a
> filepath is invalid for writing due to whatever reason (read only, 
invalid
> address, someone else or some other process already has the file 
open, etc)
> is that the quicktime capture session simply shuts down after 
attempting to

> write the first frame.
>




On 05/03/2013 11:39 AM, Tim Crowson wrote:

I get the error no matter where I'm outputting the file. Local or Network.
-Tim

On 3/5/2013 10:25 AM, Matt Morris wrote:
I've had problems with this when its trying to output to a network 
drive. It didn't give me any issues outputting locally.




On 5 March 2013 16:20, Tim Crowson > wrote:


Just a month ago I was able to export viewport captures as
QuickTime files. Now, when I click on the 'Codec' button, if
either QuickTime or AVI is selected as the format, I get the
following error:

/'Could not create the file and initialize the render - verify
the path'/

I'm not sure what path it's talking about. This happens in both
2012 SAP and 2013...

-- 


*Tim Crowson
*/Lead CG Artist/

*Magnetic Dreams, Inc.
*2525 Lebanon Pike, Building C. Nashville, TN 37214
*Ph* 615.885.6801  | *Fax* 615.889.4768
 | www.magneticdreams.com

tim.crow...@magneticdreams.com


/Confidentiality Notice: This email, including attachments, is
confidential and should not be used by anyone who is not the
original intended recipient(s). If you have received this e-mail
in error please inform the sender and delete it from your mailbox
or any other storage mechanism. Magnetic Dreams, Inc cannot
accept liability for any statements made which are clearly the
sender's own and not expressly made on behalf of Magnetic Dreams,
Inc or one of its agents./




--
www.matinai.com 


--
Signature

Re: Video codecs no longer working for Viewport Capture...

[Matt Morris]

Well either a restart or renaming the save file to a new name normally
solves it for me, but it does pop up way to often...



On 5 March 2013 16:39, Tim Crowson  wrote:

>  I get the error no matter where I'm outputting the file. Local or Network.
> -Tim
>
>
> On 3/5/2013 10:25 AM, Matt Morris wrote:
>
> I've had problems with this when its trying to output to a network drive.
> It didn't give me any issues outputting locally.
>
>
>
> On 5 March 2013 16:20, Tim Crowson  wrote:
>
>>  Just a month ago I was able to export viewport captures as QuickTime
>> files. Now, when I click on the 'Codec' button, if either QuickTime or AVI
>> is selected as the format, I get the following error:
>>
>> *'Could not create the file and initialize the render - verify the path'*
>>
>> I'm not sure what path it's talking about. This happens in both 2012 SAP
>> and 2013...
>>
>> --
>>
>>
>>
>> *Tim Crowson
>> **Lead CG Artist*
>>
>> *Magnetic Dreams, Inc.
>> *2525 Lebanon Pike, Building C. Nashville, TN 37214
>> *Ph*  615.885.6801 | *Fax*  615.889.4768 | www.magneticdreams.com
>> tim.crow...@magneticdreams.com
>>
>> *Confidentiality Notice: This email, including attachments, is
>> confidential and should not be used by anyone who is not the original
>> intended recipient(s). If you have received this e-mail in error please
>> inform the sender and delete it from your mailbox or any other storage
>> mechanism. Magnetic Dreams, Inc cannot accept liability for any statements
>> made which are clearly the sender's own and not expressly made on behalf of
>> Magnetic Dreams, Inc or one of its agents.*
>>
>>
>>
>
>
>
>  --
> www.matinai.com
>
>
> --
>
>
>



-- 
www.matinai.com

Re: Video codecs no longer working for Viewport Capture...

[Bradley Gabe]

Keep in mind that when prepping a Quicktime, Softimage actually writes a
small header to the intended capture file before you actually do the
capture. Not sure if Windows video codecs do the same, but wouldn't be
surprised.

If for some odd reason the file path you set is invalid (check to see how
your tokens resolve!) or if it goes to a directory that lacks write
permissions, this can be an issue.

In your case, it's probably not this issue, but just thought I'd put this
out there. :-)

On Tue, Mar 5, 2013 at 10:55 AM, Matt Morris  wrote:

> Well either a restart or renaming the save file to a new name normally
> solves it for me, but it does pop up way to often...
>
>
>
> On 5 March 2013 16:39, Tim Crowson  wrote:
>
>>  I get the error no matter where I'm outputting the file. Local or
>> Network.
>> -Tim
>>
>>
>> On 3/5/2013 10:25 AM, Matt Morris wrote:
>>
>> I've had problems with this when its trying to output to a network drive.
>> It didn't give me any issues outputting locally.
>>
>>
>>
>> On 5 March 2013 16:20, Tim Crowson wrote:
>>
>>>  Just a month ago I was able to export viewport captures as QuickTime
>>> files. Now, when I click on the 'Codec' button, if either QuickTime or AVI
>>> is selected as the format, I get the following error:
>>>
>>> *'Could not create the file and initialize the render - verify the path'
>>> *
>>>
>>> I'm not sure what path it's talking about. This happens in both 2012 SAP
>>> and 2013...
>>>
>>> --
>>>
>>>
>>>
>>> *Tim Crowson
>>> **Lead CG Artist*
>>>
>>> *Magnetic Dreams, Inc.
>>> *2525 Lebanon Pike, Building C. Nashville, TN 37214
>>> *Ph*  615.885.6801 | *Fax*  615.889.4768 | www.magneticdreams.com
>>> tim.crow...@magneticdreams.com
>>>
>>> *Confidentiality Notice: This email, including attachments, is
>>> confidential and should not be used by anyone who is not the original
>>> intended recipient(s). If you have received this e-mail in error please
>>> inform the sender and delete it from your mailbox or any other storage
>>> mechanism. Magnetic Dreams, Inc cannot accept liability for any statements
>>> made which are clearly the sender's own and not expressly made on behalf of
>>> Magnetic Dreams, Inc or one of its agents.*
>>>
>>>
>>>
>>
>>
>>
>>  --
>> www.matinai.com
>>
>>
>> --
>>
>>
>>
>
>
>
> --
> www.matinai.com
>

Re: Video codecs no longer working for Viewport Capture...

[Tim Crowson]

I thought of that as well, and tried different paths where nothing had 
ever been captured. Same thing. Restarting my box has no effect.  Criminy.


By the way, Bradley, nice work with your Shotgun/Tank integration. The 
webinar the other day when Tony presented was frickin' sweet.



-Tim


On 3/5/2013 11:03 AM, Bradley Gabe wrote:
Keep in mind that when prepping a Quicktime, Softimage actually writes 
a small header to the intended capture file before you actually do the 
capture. Not sure if Windows video codecs do the same, but wouldn't be 
surprised.


If for some odd reason the file path you set is invalid (check to see 
how your tokens resolve!) or if it goes to a directory that lacks 
write permissions, this can be an issue.


In your case, it's probably not this issue, but just thought I'd put 
this out there. :-)


On Tue, Mar 5, 2013 at 10:55 AM, Matt Morris > wrote:


Well either a restart or renaming the save file to a new name
normally solves it for me, but it does pop up way to often...



On 5 March 2013 16:39, Tim Crowson mailto:tim.crow...@magneticdreams.com>> wrote:

I get the error no matter where I'm outputting the file. Local
or Network.
-Tim


On 3/5/2013 10:25 AM, Matt Morris wrote:

I've had problems with this when its trying to output to a
network drive. It didn't give me any issues outputting locally.



On 5 March 2013 16:20, Tim Crowson
mailto:tim.crow...@magneticdreams.com>> wrote:

Just a month ago I was able to export viewport captures
as QuickTime files. Now, when I click on the 'Codec'
button, if either QuickTime or AVI is selected as the
format, I get the following error:

/'Could not create the file and initialize the render -
verify the path'/

I'm not sure what path it's talking about. This happens
in both 2012 SAP and 2013...

-- 


*Tim Crowson
*/Lead CG Artist/

*Magnetic Dreams, Inc.
*2525 Lebanon Pike, Building C. Nashville, TN 37214
*Ph* 615.885.6801  | *Fax* 615.889.4768
 | www.magneticdreams.com

tim.crow...@magneticdreams.com


/Confidentiality Notice: This email, including
attachments, is confidential and should not be used by
anyone who is not the original intended recipient(s). If
you have received this e-mail in error please inform the
sender and delete it from your mailbox or any other
storage mechanism. Magnetic Dreams, Inc cannot accept
liability for any statements made which are clearly the
sender's own and not expressly made on behalf of Magnetic
Dreams, Inc or one of its agents./

RE: Orientation and vectors, foundations

[Grahame Fuller]

A particle's orientation is its offset in rotation relative to the point 
cloud's local reference frame. If as is typical, you leave the point cloud 
untransformed, then this is the same as its offset in rotation relative to the 
scene's global reference frame.

The orientation is expressed as a rotation in axis and angle form, i.e., [X, Y, 
Z] coordinates that define a vector relative to the point cloud, and an angle 
of rotation around that vector.

Axis and angle is just one of several ways to represent a rotation. The other 
ways that are available in ICE are Euler angles, quaternions, and matrices (but 
be aware that in general 3x3 matrices represent both rotation and scaling, and 
4x4 matrices represent rotation, scaling, and translation, so be careful when 
using them in case you inadvertently apply more than just rotation). Each of 
these formats has advantages and disadvantages in different situations. There 
are nodes that can convert between them as required.

Axis and angle was chosen to represent orientation and other rotations after 
some discussion on the Ariane beta list. It was felt to be fairly intuitive for 
artists, and is fairly easy to use in computations (or at least, easy to 
convert under the hood to a format that is useful for computations).

As with transforms in general, rotations can be used to manipulate vectors and 
positions, or to convert between reference frames, among other things. It 
depends on the problem you are trying to solve and how it is framed.

gray

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Andy Moorer
Sent: Tuesday, March 05, 2013 12:58 PM
To: softimage@listproc.autodesk.com
Subject: Orientation and vectors, foundations

Hi all,

As I was working today I realized that despite doing operations on ice 
"orientations" regularly I don't have a firm grasp on what they really are. 
Orientation relative to what? And what form is this orientation in?

Trying to phrase it differently...

How is a particle's "orientation" different from a 3x3 matrix describing the 
difference in rotation between it's local coordinate space and the global frame 
of reference? Both are clearly descriptions of the same thing.

I know this is kind of an abstract subject, and (being tired at the moment) my 
question may not even be clear, but being self-taught and lacking adequate 
formal math education I'd be very interested in your answers and any discussion 
in general on how you all visualize rotations and orientation,

For some people I talk to about rotations (I'm the life of any party) it seems 
to be all about manipulating vectors, others seem more comfortable thinking 
about rotations as transformations between reference frames... and I see a 
similar wide range of how people go about some of this stuff when looking into 
various compounds.
<>

Re: Orientation and vectors, foundations

[Bradley Gabe]

In intro physics, the concept of vectors are always taught using position
since the x,y,z coordinate space results in arrows that show you the
relative values in a format that is intuitive. Thus it would follow, for
position, velocity, acceleration, vector math is more readily grasped,
since it's easier to conceptualize.

But then they move into rotations and lose most of the class, because they
forgot to mention that vectors aren't *always* representing something you
can easily visualize in a one-to-one fashion.

In CG, we have another example of vectors we use all the time but where the
values aren't easily associated with a spatial position: RGB colors. Three
values contained in a single vector (4 for RGBA), but unless you've got a
nice color volume that shows you what the values mean, the association
between an arrow floating in space and a resulting color is rather
disconnected.

Meanwhile, you could represent that color using other vectors:
hue/brightness/saturation, CMYK, or hue/saturation/value, etc. Notice how
CMYK has 4-dimensions, while the others have 3? Yet they all ultimately
generate a color output. Also notice how changing the values of one of the
dimensions in RGB color interpolates the resulting color differently from
changing one of the values in HSV, yet both can result in the same range of
colors?

And so it goes with rotations. Different heuristics to represent the same
result. Euler uses 3-dimensions, whereas angle/axis and quaternion use 4.
Each one results in a different interpolation from changing one of the
values, and each one is useful in different circumstances. Yet none of them
(save maybe angle/axis) is easily visualized with an arrow in space.

-Bradley

On Tue, Mar 5, 2013 at 11:57 AM, Andy Moorer  wrote:

> Hi all,
>
> As I was working today I realized that despite doing operations on ice
> "orientations" regularly I don't have a firm grasp on what they really *
> are*. Orientation relative to what? And what form is this orientation in?
>
> Trying to phrase it differently...
>
> How is a particle's "orientation" different from a 3x3 matrix describing
> the difference in rotation between it's local coordinate space and the
> global frame of reference? Both are clearly descriptions of the same thing.
>
> I know this is kind of an abstract subject, and (being tired at the
> moment) my question may not even be clear, but being self-taught and
> lacking adequate formal math education I'd be very interested in your
> answers and any discussion in general on how you all visualize rotations
> and orientation,
>
> For some people I talk to about rotations (I'm the life of any party) it
> seems to be all about manipulating vectors, others seem more comfortable
> thinking about rotations as transformations between reference frames... and
> I see a similar wide range of how people go about some of this stuff when
> looking into various compounds.
>

Re: Orientation and vectors, foundations

[Rob Chapman]

ah I see where your going with this Andy, so how can I get a particles
rotation into a current direction of rotation vector?   say its spinning or
'tumbling' how to get the vector to rotate with it. I was thinking an 'up
vector' but particles dont have them

On 5 March 2013 19:33, Grahame Fuller  wrote:

> A particle's orientation is its offset in rotation relative to the point
> cloud's local reference frame. If as is typical, you leave the point cloud
> untransformed, then this is the same as its offset in rotation relative to
> the scene's global reference frame.
>
> The orientation is expressed as a rotation in axis and angle form, i.e.,
> [X, Y, Z] coordinates that define a vector relative to the point cloud, and
> an angle of rotation around that vector.
>
> Axis and angle is just one of several ways to represent a rotation. The
> other ways that are available in ICE are Euler angles, quaternions, and
> matrices (but be aware that in general 3x3 matrices represent both rotation
> and scaling, and 4x4 matrices represent rotation, scaling, and translation,
> so be careful when using them in case you inadvertently apply more than
> just rotation). Each of these formats has advantages and disadvantages in
> different situations. There are nodes that can convert between them as
> required.
>
> Axis and angle was chosen to represent orientation and other rotations
> after some discussion on the Ariane beta list. It was felt to be fairly
> intuitive for artists, and is fairly easy to use in computations (or at
> least, easy to convert under the hood to a format that is useful for
> computations).
>
> As with transforms in general, rotations can be used to manipulate vectors
> and positions, or to convert between reference frames, among other things.
> It depends on the problem you are trying to solve and how it is framed.
>
> gray
>
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Andy Moorer
> Sent: Tuesday, March 05, 2013 12:58 PM
> To: softimage@listproc.autodesk.com
> Subject: Orientation and vectors, foundations
>
> Hi all,
>
> As I was working today I realized that despite doing operations on ice
> "orientations" regularly I don't have a firm grasp on what they really are.
> Orientation relative to what? And what form is this orientation in?
>
> Trying to phrase it differently...
>
> How is a particle's "orientation" different from a 3x3 matrix describing
> the difference in rotation between it's local coordinate space and the
> global frame of reference? Both are clearly descriptions of the same thing.
>
> I know this is kind of an abstract subject, and (being tired at the
> moment) my question may not even be clear, but being self-taught and
> lacking adequate formal math education I'd be very interested in your
> answers and any discussion in general on how you all visualize rotations
> and orientation,
>
> For some people I talk to about rotations (I'm the life of any party) it
> seems to be all about manipulating vectors, others seem more comfortable
> thinking about rotations as transformations between reference frames... and
> I see a similar wide range of how people go about some of this stuff when
> looking into various compounds.
>

Re: MOMA - Modo for Maya

[Steven Caron]

once modo has a proper api for it... probably. the amount of work jacobo is
doing to make this work is staggering as is any renderer
integration/plugin. i know, i tried to do it for thea render but realized
how much time i put in was no where near what i was going to get back for
it.

i couldn't find the moma to sitoa comparison, i saw a moma and mtoa (maya
to arnold) comparison. i am surprised though, someone who has worked with
arnold before (at zinkia on pocoyo) he should know mtoa integration might
not represent arnold standalone in the best light. since he does have
experience with arnold, i am also interested in his opinion of it versus
arnold.

s


On Tue, Mar 5, 2013 at 5:08 AM, Paul Griswold <
pgrisw...@fusiondigitalproductions.com> wrote:

> This is pretty cool:
>
> http://www.jacobobarreiro.com/jweb/moma/
>
> Since there are plenty of Softimage to _ connections for various
> render engines, would something like this be possible for Soft?
>
> Having Modo's preview window in Softimage would be pretty slick.
>
> He's also got a version for Nuke and in one video compares MOMA to SItoA,
> which is really interesting.
>
> Paul
>
>

RE: Orientation and vectors, foundations

[Grahame Fuller]

“Direction of rotation” isn’t a well defined concept. Imagine a spinning jack 
(a.k.a. knucklebone). At the moment that one of the arms is pointing north, 
that arm is tangentially moving east-west. At the same time, the next arm is 
pointing east and moving tangentially north-south, another arm is point south 
and moving west-east, and the last arm is pointing east and moving south-north.

The closest thing to describing the “direction” of a rotation is the axis 
vector, similar to the way we use the normal vector to define a plane.

gray

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: Tuesday, March 05, 2013 01:48 PM
To: softimage@listproc.autodesk.com
Subject: Re: Orientation and vectors, foundations

ah I see where your going with this Andy, so how can I get a particles rotation 
into a current direction of rotation vector?   say its spinning or 'tumbling' 
how to get the vector to rotate with it. I was thinking an 'up vector' but 
particles dont have them
On 5 March 2013 19:33, Grahame Fuller 
mailto:grahame.ful...@autodesk.com>> wrote:
A particle's orientation is its offset in rotation relative to the point 
cloud's local reference frame. If as is typical, you leave the point cloud 
untransformed, then this is the same as its offset in rotation relative to the 
scene's global reference frame.

The orientation is expressed as a rotation in axis and angle form, i.e., [X, Y, 
Z] coordinates that define a vector relative to the point cloud, and an angle 
of rotation around that vector.

Axis and angle is just one of several ways to represent a rotation. The other 
ways that are available in ICE are Euler angles, quaternions, and matrices (but 
be aware that in general 3x3 matrices represent both rotation and scaling, and 
4x4 matrices represent rotation, scaling, and translation, so be careful when 
using them in case you inadvertently apply more than just rotation). Each of 
these formats has advantages and disadvantages in different situations. There 
are nodes that can convert between them as required.

Axis and angle was chosen to represent orientation and other rotations after 
some discussion on the Ariane beta list. It was felt to be fairly intuitive for 
artists, and is fairly easy to use in computations (or at least, easy to 
convert under the hood to a format that is useful for computations).

As with transforms in general, rotations can be used to manipulate vectors and 
positions, or to convert between reference frames, among other things. It 
depends on the problem you are trying to solve and how it is framed.

gray

From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Andy Moorer
Sent: Tuesday, March 05, 2013 12:58 PM
To: softimage@listproc.autodesk.com
Subject: Orientation and vectors, foundations

Hi all,

As I was working today I realized that despite doing operations on ice 
"orientations" regularly I don't have a firm grasp on what they really are. 
Orientation relative to what? And what form is this orientation in?

Trying to phrase it differently...

How is a particle's "orientation" different from a 3x3 matrix describing the 
difference in rotation between it's local coordinate space and the global frame 
of reference? Both are clearly descriptions of the same thing.

I know this is kind of an abstract subject, and (being tired at the moment) my 
question may not even be clear, but being self-taught and lacking adequate 
formal math education I'd be very interested in your answers and any discussion 
in general on how you all visualize rotations and orientation,

For some people I talk to about rotations (I'm the life of any party) it seems 
to be all about manipulating vectors, others seem more comfortable thinking 
about rotations as transformations between reference frames... and I see a 
similar wide range of how people go about some of this stuff when looking into 
various compounds.

<>

Re: MOMA - Modo for Maya

[Tim Crowson]

I don't have a lot to show for it, but I do have some experience with 
Arnold. My opininion is that modo is not far behind the likes of v-Ray 
and Arnold. In fact depending on the scene, I have had modo outperform 
Arnold. It is definitely trickier to get photo-real believability out of 
modo than v-Ray, but it's not entirely impossible. Where it falls a bit 
short is not so much in the rendering ability but modo's performance 
with large scenes in general. On the other hand, Luxology is closing a 
lot of gaps with its releases these days, and the renderer is improving 
quite rapidly, as is managament of large scenes. Preview, in particular, 
always gets major improvements.


-Tim C.



On 3/5/2013 1:04 PM, Steven Caron wrote:
once modo has a proper api for it... probably. the amount of work 
jacobo is doing to make this work is staggering as is any renderer 
integration/plugin. i know, i tried to do it for thea render but 
realized how much time i put in was no where near what i was going to 
get back for it.


i couldn't find the moma to sitoa comparison, i saw a moma and mtoa 
(maya to arnold) comparison. i am surprised though, someone who has 
worked with arnold before (at zinkia on pocoyo) he should know mtoa 
integration might not represent arnold standalone in the best light. 
since he does have experience with arnold, i am also interested in his 
opinion of it versus arnold.


s


On Tue, Mar 5, 2013 at 5:08 AM, Paul Griswold 
> wrote:


This is pretty cool:

http://www.jacobobarreiro.com/jweb/moma/

Since there are plenty of Softimage to _ connections for
various render engines, would something like this be possible for
Soft?

Having Modo's preview window in Softimage would be pretty slick.

He's also got a version for Nuke and in one video compares MOMA to
SItoA, which is really interesting.

Paul




--
Signature

Re: MOMA - Modo for Maya

[Simon van de Lagemaat]

In a nutshell... Modo has a great renderer and Allen Hastings is the heart
and soul of Luxology.  That said it's not a great heavy lifter , it doesn't
handle large and complex scenes well and lacks a lot of the
refining/optimization tools that it should have at this point.

I tried to use it in production but it was difficult and not enjoyable when
time was of the essence and predictability and stability mattered.  As an
asset creation and lookdev tool it is brilliant and flexible, just not in
midsize to large pipelines.  It's a shame because the tech does so many
other things well but is being hampered by the tools surrounding it.

Maybe the Foundry will have a positive influence in this area, I hope so
because there a lot of great things about Modo and its renderer but it
hasn't yet realized its full potential.  Let's see how 7 turns out.


On Tue, Mar 5, 2013 at 11:04 AM, Steven Caron  wrote:

> once modo has a proper api for it... probably. the amount of work jacobo
> is doing to make this work is staggering as is any renderer
> integration/plugin. i know, i tried to do it for thea render but realized
> how much time i put in was no where near what i was going to get back for
> it.
>
> i couldn't find the moma to sitoa comparison, i saw a moma and mtoa (maya
> to arnold) comparison. i am surprised though, someone who has worked with
> arnold before (at zinkia on pocoyo) he should know mtoa integration might
> not represent arnold standalone in the best light. since he does have
> experience with arnold, i am also interested in his opinion of it versus
> arnold.
>
> s
>
>

Re: Emit particles from camera FOV

[peter_b]

factory compounds, now where is the fun in that?

From: Dan Yargici 
Sent: Tuesday, March 05, 2013 9:53 AM
To: softimage@listproc.autodesk.com 
Subject: Re: Emit particles from camera FOV

You all know there's a factory 'Test Visibility From Camera' node, right?  :) 

DAN



On Tue, Mar 5, 2013 at 8:13 AM,  wrote:

  Do check the recent “ICE test vector inside cone” thread here – that should 
provide the basis for solving camera frustrum, which you can use for anything, 
such as filter on emission.

  Also: simply model a frustrum box, constrained to camera, and use delete by 
volume.
  Wether or not deleting points plays nice with your pointcloud is a bit 
unpredictable. (see: all particles disappearing on random frames, bounding box 
of the cloud disappearing on random frames rendering the cloud unrenderable – 
shudders... ) 
  Other than that – I find delete by volume quite handy in optimising 
pointclouds – getting rid of stuff that’s not needed, not visible or just stray 
particles.


  From: Gene Crucean 
  Sent: Monday, March 04, 2013 10:58 PM
  To: softimage@listproc.autodesk.com 
  Subject: Re: Emit particles from camera FOV

  Sheesh. Didn't even get a chance to try myself yet lol. This list can be 
pretty fast at times. 

  Thanks Vincent I'll play with it in a bit.



  On Mon, Mar 4, 2013 at 10:36 AM, Vincent Ullmann 
 wrote:

maybe this could help:

a compound that creates a Grid of "Pixels" in front of your connected cam, 
and orients them properly...

now you just have to press "Strg+A" and "Strg+G" to create a Group of your 
scene.
then: do a raycast from each point along its orientation (rotate vector + 
particle ori). (do this on emit)
if you have all this on a simulated ice-tree it should add new particles 
each frame... so you clould "paint"

Am 04.03.2013 19:22, schrieb Gene Crucean:

  Well it's a little more complicated than that because I need to "paint" 
with the fov :) 

  So the accumulation of particles over time is required.



  On Mon, Mar 4, 2013 at 9:08 AM, Alok Gandhi  
wrote:

Hmmm, I think I have done it once for an effect. The workflow was 
really not that straight. I was emitting particles from a ground mesh. As a 
first pass, I was writing a weight map on the geo based on the camera move, 
setting value of 1.0 for all vertex in fov and 0 for non-visible. Then I froze 
the weight map. And in the sim, I was filtering the emission by this weight 
map. 

But there can be other simpler ways around it depending use case 
scenario. One way that I think of right off my head is to delete particles not 
in view. But this can be time consuming if you have high particle density and 
only a small part of it visible to fov.






  -- 

  Gene Crucean - Emmy winning - Oscar nominated CG Supervisor / iOS-OSX 
Developer / Filmmaker / Photographer

  ** Freelance for hire **
  www.genecrucean.com

  ~~ Please use my website's contact form on www.genecrucean.com for any 
personal emails. Thanks. I may not get them at this address. ~~






  -- 

  Gene Crucean - Emmy winning - Oscar nominated CG Supervisor / iOS-OSX 
Developer / Filmmaker / Photographer

  ** Freelance for hire **
  www.genecrucean.com

  ~~ Please use my website's contact form on www.genecrucean.com for any 
personal emails. Thanks. I may not get them at this address. ~~

Re: Orientation and vectors, foundations

[Bradley Gabe]

Based on what you just wrote here, it's clearer what you want to do with
this knowledge, and believe it or not, there's a simple answer.

Remember that an orientation vector gives you an offset from origin so you
can create an x-axis (1,0,0) y-axis (0,1,0) and z-axis vector (0,0,1), and
then set their visualization colors to red, green, blue.

Use 3 [Rotate Vector] nodes and whatever orientation input and you will be
able to visualize the orientation's resulting offset from origin. This is
literally converting your rotation to position reference vectors.

Of course, setting your rotation visualization to axis gives you the same
kind of visual info, but this way, at least the concept of how the
orientation is affecting position vectors gets illustrated.


Now something TD's might be initially confused with is direction to
rotation in ICE. When using a direction constraint for rigging, it's the
x-axis that points at the target, and the y-axis that's used to establish
the up-vector. With ICE, remember that particle systems often use sprites,
which we want to face the camera... so direction to rotation uses the
y-axis for point at, and the x (or z) axis to resolve the up vector.


On Tue, Mar 5, 2013 at 5:13 PM, Andy Moorer  wrote:

>
> *ah I see where your going with this Andy, so how can I get a particles
>> rotation into a current direction of rotation vector?   say its spinning or
>> 'tumbling' how to get the vector to rotate with it. I was thinking an 'up
>> vector' but particles dont have them*
>>
>
> Yeah kinda, but more generally. I had a situation where I had an array of
> vectors which I was using to represent a "direction", and had occasion to
> pull out a "rotate vector" node, and around that point I got irritated that
> there were "rotations" and "orientations" which are being treated as
> separate-but-interchangeable types and this made me realize that I clearly
> wasn't following someone's logic.
>
> But it's also stuff I've been wrapping my head around for some time. I
> remember once when I was fortunate enough to be working with Brad on a job
> he spent some time helping me out with visualizing matrices and warned me
> it would take about a year to get a feel for them. He was right, and having
> been told that I kept plugging away, comforted to know visualizing this
> sort of thing generally isn't intrinsic, but practiced.
>
> This is kind of a superset of that - I "get it" now with using matrices to
> swap around frames of reference and it's been a huge benefit and opened up
> a lot of fun things.
>
> But there are a lot of loose ends to getting a "complete" picture where I
> can translate in my mind what I'm doing into the several ways one can go
> about doing the same operations... As Grahame puts it the different
> "formats," or as in Brads answer the different "heuristics."
>
> As a in-the-trenches TD it's easy to maintain a "it just works" way of
> thinking without seeing a bigger picture (because you're busy!) and I
> realized that it's very easy to fall into this with rotations in ICE,
> because we have pretty good tools for getting things done practically in a
> series of defined workflows. And next thing you know, you're reaching for a
> node and realizing you've lost sight of what you're really doing under the
> hood. :P
>
> Your example is a good one, though, if I get what you're saying... an easy
> and common sense way to think would be that you could take a "get particle
> orientation" node and want to translate that orientation into a vector
> which you could then rotate with a "rotate vector" node and expect that to
> give you a local rotation.
>
> Which, of course, doesn't work - and if you look for some kind of "convert
> orientation to vector" you're going to come up empty, and for good reason.
> But it's not so silly to think that it *might* work that way, and I
> remember a time when I could have fallen into this kind of trap.
>
> But the reason *why* this seemingly simple operation doesn't make sense
> gets difficult to express, at least for me. I'm not at a point where, if an
> artist asked me to help them (having gone down this path) I could teach
> them how to look at it.
>
> And I figure if I can't teach something, I probably don't understand it
> well enough. :P
>
>
>

Re: Orientation and vectors, foundations

[Steven Caron]

the rotation was supposed to be a generic term/type or an abstraction from
needing to know about quaternions, matrices, etc. and i believe they didn't
use euler because of the potential confusion with rotation order.

you will find zero nodes in the 'rotation' category labeled with
'orientation'... a little bit confusing that the attribute is named
'orientation' for sure. but Brent Mcpherson, who is a rotation grand
master, gave us lots of flexibility in this area.

On Tue, Mar 5, 2013 at 3:13 PM, Andy Moorer  wrote:
>
>
> Yeah kinda, but more generally. I had a situation where I had an array of
> vectors which I was using to represent a "direction", and had occasion to
> pull out a "rotate vector" node, and around that point I got irritated that
> there were "rotations" and "orientations" which are being treated as
> separate-but-interchangeable types and this made me realize that I clearly
> wasn't following someone's logic.
>

RE: Orientation and vectors, foundations

[Grahame Fuller]

On the distinction between orientation and rotation, it's not hard and fast but 
I tend to use "orientation" when talking about a static pose, and "rotation" 
when talking about applying a transform (i.e.actively turning something). The 
final orientation is the product of the successive rotations that something 
took to get to that pose, but it's also the rotation that you would apply to 
get to that orientation from an unrotated pose in one step.

It's a bit like positions and translations. The final position is the sum of 
all the translations that have been performed, and it's also the translation 
that you woould apply to get there from (0, 0, 0).

Make sense?

gray

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe
Sent: Tuesday, March 05, 2013 06:34 PM
To: softimage@listproc.autodesk.com
Subject: Re: Orientation and vectors, foundations

Based on what you just wrote here, it's clearer what you want to do with this 
knowledge, and believe it or not, there's a simple answer.

Remember that an orientation vector gives you an offset from origin so you can 
create an x-axis (1,0,0) y-axis (0,1,0) and z-axis vector (0,0,1), and then set 
their visualization colors to red, green, blue.

Use 3 [Rotate Vector] nodes and whatever orientation input and you will be able 
to visualize the orientation's resulting offset from origin. This is literally 
converting your rotation to position reference vectors.

Of course, setting your rotation visualization to axis gives you the same kind 
of visual info, but this way, at least the concept of how the orientation is 
affecting position vectors gets illustrated.


Now something TD's might be initially confused with is direction to rotation in 
ICE. When using a direction constraint for rigging, it's the x-axis that points 
at the target, and the y-axis that's used to establish the up-vector. With ICE, 
remember that particle systems often use sprites, which we want to face the 
camera... so direction to rotation uses the y-axis for point at, and the x (or 
z) axis to resolve the up vector.

On Tue, Mar 5, 2013 at 5:13 PM, Andy Moorer 
mailto:andymoo...@gmail.com>> wrote:

ah I see where your going with this Andy, so how can I get a particles rotation 
into a current direction of rotation vector?   say its spinning or 'tumbling' 
how to get the vector to rotate with it. I was thinking an 'up vector' but 
particles dont have them

Yeah kinda, but more generally. I had a situation where I had an array of 
vectors which I was using to represent a "direction", and had occasion to pull 
out a "rotate vector" node, and around that point I got irritated that there 
were "rotations" and "orientations" which are being treated as 
separate-but-interchangeable types and this made me realize that I clearly 
wasn't following someone's logic.

But it's also stuff I've been wrapping my head around for some time. I remember 
once when I was fortunate enough to be working with Brad on a job he spent some 
time helping me out with visualizing matrices and warned me it would take about 
a year to get a feel for them. He was right, and having been told that I kept 
plugging away, comforted to know visualizing this sort of thing generally isn't 
intrinsic, but practiced.

This is kind of a superset of that - I "get it" now with using matrices to swap 
around frames of reference and it's been a huge benefit and opened up a lot of 
fun things.

But there are a lot of loose ends to getting a "complete" picture where I can 
translate in my mind what I'm doing into the several ways one can go about 
doing the same operations... As Grahame puts it the different "formats," or as 
in Brads answer the different "heuristics."

As a in-the-trenches TD it's easy to maintain a "it just works" way of thinking 
without seeing a bigger picture (because you're busy!) and I realized that it's 
very easy to fall into this with rotations in ICE, because we have pretty good 
tools for getting things done practically in a series of defined workflows. And 
next thing you know, you're reaching for a node and realizing you've lost sight 
of what you're really doing under the hood. :P

Your example is a good one, though, if I get what you're saying... an easy and 
common sense way to think would be that you could take a "get particle 
orientation" node and want to translate that orientation into a vector which 
you could then rotate with a "rotate vector" node and expect that to give you a 
local rotation.

Which, of course, doesn't work - and if you look for some kind of "convert 
orientation to vector" you're going to come up empty, and for good reason. But 
it's not so silly to think that it might work that way, and I remember a time 
when I could have fallen into this kind of trap.

But the reason why this seemingly simple operation doesn't make sense gets 
difficult to express, at least for me. I'm not at a point where, if an artist 
asked 

Re: Emit particles from camera FOV

[Andy Moorer]

A bit of a digression, but since it came up...

I did quite a bit of this kind of thing at StereoD, where understandably
relationships between positions and cameras is paramount.

The VFX team there has a pretty good toolset forming of custom ICE nodes to
deal with just this kind of thing, which started out with simple compounds
similar to the one Vincent has shared.

For instance, if you project a particle for each pixel of a stereo depth
map down the frustrum of a camera you have the beginnings of a 3d
visualization of the depth of a scene (though it's complicated by the fact
that StereoD has learned to use depth as a creative medium and therefore a
strict linear interpretation of a depth map doesn't reflect what their
stereo artists do to enhance a shot any more than color in a shot is a 1:1
interpretation after a shot is graded.)

Stereo and ICE present some cool challenges by the way: with stereo
information like a depth map brought into ICE it becomes possible to have
your ICE sims interact,collide, and be occluded with footage. We often talk
about the down sides of stereo but that extra depth information has some
huge implications for VFX and StereoD was a great place to explore some of
that.

Going back to 2d work I find I particularly miss not having a depth map
available to occlude particles as they go "behind" footage elements.

Re: Orientation and vectors, foundations

[Andy Moorer]

I hope he is. :)

Thanks guys, I found that very illuminating!

On Mar 5, 2013, at 7:17 PM, Steven Caron  wrote:

> makes good sense to me... you still writing docs at autodesk grahame?
> 
> 
> On Tue, Mar 5, 2013 at 3:59 PM, Grahame Fuller  
> wrote:
>> On the distinction between orientation and rotation, it's not hard and fast 
>> but I tend to use "orientation" when talking about a static pose, and 
>> "rotation" when talking about applying a transform (i.e.actively turning 
>> something). The final orientation is the product of the successive rotations 
>> that something took to get to that pose, but it's also the rotation that you 
>> would apply to get to that orientation from an unrotated pose in one step.
>> 
>> It's a bit like positions and translations. The final position is the sum of 
>> all the translations that have been performed, and it's also the translation 
>> that you woould apply to get there from (0, 0, 0).
>> 
>> Make sense?

Any way to distinguish between tangents and colors?

[Nicolas Burtnyk]

Hello list,

Does anyone know a way to tell whether a cluster contains tangents as
opposed to vertex colors?

Thanks!

-Nicolas

RE: Any way to distinguish between tangents and colors?

[Matt Lind]

Check the cluster property type.

Matt

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 5:53 PM
To: softimage@listproc.autodesk.com
Subject: Any way to distinguish between tangents and colors?

Hello list,

Does anyone know a way to tell whether a cluster contains tangents as opposed 
to vertex colors?

Thanks!

-Nicolas

Re: Any way to distinguish between tangents and colors?

[Nicolas Burtnyk]

Right, but both tangent and color clusters
return siClusterPropertyVertexColorType :(


On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind  wrote:

> Check the cluster property type.
>
> ** **
>
> Matt
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Nicolas Burtnyk
> *Sent:* Tuesday, March 05, 2013 5:53 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Any way to distinguish between tangents and colors?
>
> ** **
>
> Hello list,
>
> ** **
>
> Does anyone know a way to tell whether a cluster contains tangents as
> opposed to vertex colors?
>
> ** **
>
> Thanks!
>
> ** **
>
> -Nicolas
>

Re: Any way to distinguish between tangents and colors?

[Steven Caron]

i believe they are both still 'vertexcolor', hence nicolas' question...

i would say, by name or 'DataType' parameter on the property?

from siutils import si
si = si() # win32com.client.Dispatch('XSI.Application')
from siutils import log # LogMessage
from siutils import disp # win32com.client.Dispatch
from siutils import C # win32com.client.constants

for item in si.Selection:
sampleClusters =
item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
if sampleClusters.Count:
for cluster in sampleClusters:
for prop in cluster.LocalProperties:
if prop.Parameters("datatype"):
log("%s > %s > %s" % (prop.Name,prop.Type,
prop.Parameters("datatype").Value))

# INFO : Vertex_Color > vertexcolor > 0
# INFO : Tangents > vertexcolor > 1


On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind  wrote:

> Check the cluster property type.
>
> ** **
>
> Matt
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Nicolas Burtnyk
> *Sent:* Tuesday, March 05, 2013 5:53 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Any way to distinguish between tangents and colors?
>
> ** **
>
> Hello list,
>
> ** **
>
> Does anyone know a way to tell whether a cluster contains tangents as
> opposed to vertex colors?
>
> ** **
>
> Thanks!
>
> ** **
>
> -Nicolas
>

Re: Any way to distinguish between tangents and colors?

[Steven Caron]

this assumes no one goes out of there way to change the default datatype
for tangents and vertex colors. ;(


On Tue, Mar 5, 2013 at 6:01 PM, Steven Caron  wrote:

> i believe they are both still 'vertexcolor', hence nicolas' question...
>
> i would say, by name or 'DataType' parameter on the property?
>
> from siutils import si
> si = si() # win32com.client.Dispatch('XSI.Application')
> from siutils import log # LogMessage
> from siutils import disp # win32com.client.Dispatch
> from siutils import C # win32com.client.constants
>
> for item in si.Selection:
> sampleClusters =
> item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
> if sampleClusters.Count:
> for cluster in sampleClusters:
> for prop in cluster.LocalProperties:
> if prop.Parameters("datatype"):
> log("%s > %s > %s" % (prop.Name,prop.Type,
> prop.Parameters("datatype").Value))
>
> # INFO : Vertex_Color > vertexcolor > 0
> # INFO : Tangents > vertexcolor > 1
>
>
> On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind wrote:
>
>> Check the cluster property type.
>>
>> ** **
>>
>> Matt
>>
>> ** **
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Nicolas Burtnyk
>> *Sent:* Tuesday, March 05, 2013 5:53 PM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Any way to distinguish between tangents and colors?
>>
>> ** **
>>
>> Hello list,
>>
>> ** **
>>
>> Does anyone know a way to tell whether a cluster contains tangents as
>> opposed to vertex colors?
>>
>> ** **
>>
>> Thanks!
>>
>> ** **
>>
>> -Nicolas
>>
>
>

Re: Any way to distinguish between tangents and colors?

[Nicolas Burtnyk]

Thanks Steven -

Yeah, I'd like something a little more robust than relying on the default
DataType since this is easily changeable.
I thought of looking for the "Tangent" property or the TangentOp2 operator,
but these can be deleted/frozen away while still leaving behind valid
tangents.



On Tue, Mar 5, 2013 at 6:03 PM, Steven Caron  wrote:

> this assumes no one goes out of there way to change the default datatype
> for tangents and vertex colors. ;(
>
>
> On Tue, Mar 5, 2013 at 6:01 PM, Steven Caron  wrote:
>
>> i believe they are both still 'vertexcolor', hence nicolas' question...
>>
>> i would say, by name or 'DataType' parameter on the property?
>>
>> from siutils import si
>> si = si() # win32com.client.Dispatch('XSI.Application')
>> from siutils import log # LogMessage
>> from siutils import disp # win32com.client.Dispatch
>> from siutils import C # win32com.client.constants
>>
>> for item in si.Selection:
>> sampleClusters =
>> item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
>> if sampleClusters.Count:
>> for cluster in sampleClusters:
>> for prop in cluster.LocalProperties:
>> if prop.Parameters("datatype"):
>> log("%s > %s > %s" % (prop.Name,prop.Type,
>> prop.Parameters("datatype").Value))
>>
>> # INFO : Vertex_Color > vertexcolor > 0
>> # INFO : Tangents > vertexcolor > 1
>>
>>
>> On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind wrote:
>>
>>> Check the cluster property type.
>>>
>>> ** **
>>>
>>> Matt
>>>
>>> ** **
>>>
>>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Nicolas Burtnyk
>>> *Sent:* Tuesday, March 05, 2013 5:53 PM
>>> *To:* softimage@listproc.autodesk.com
>>> *Subject:* Any way to distinguish between tangents and colors?
>>>
>>> ** **
>>>
>>> Hello list,
>>>
>>> ** **
>>>
>>> Does anyone know a way to tell whether a cluster contains tangents as
>>> opposed to vertex colors?
>>>
>>> ** **
>>>
>>> Thanks!
>>>
>>> ** **
>>>
>>> -Nicolas
>>>
>>
>>
>

Re: Any way to distinguish between tangents and colors?

[Steven Caron]

right, which is why i went after the data type parameter, thats not going
to disappear. i know you say its 'easily changeable' but you would be hard
pressed to find anyone actually changing that parameter.


On Tue, Mar 5, 2013 at 6:11 PM, Nicolas Burtnyk wrote:

> Thanks Steven -
>
> Yeah, I'd like something a little more robust than relying on the default
> DataType since this is easily changeable.
> I thought of looking for the "Tangent" property or the TangentOp2
> operator, but these can be deleted/frozen away while still leaving behind
> valid tangents.
>

RE: Any way to distinguish between tangents and colors?

[Matt Lind]

I wouldn't worry about that.  We've been using tangents and vertex colors for 
years and never had that kind of problem.

The only (semi) reliable way we've been able to manage is from naming 
convention as Softimage insists on controlling everything else even if you try 
to change things.  For example, if you try to make your own clusters to put the 
cluster properties, Softimage will reuse or repurpose your clusters for other 
uses whether you like it or not.  I've complained quite a bit about this, but 
fell on deaf ears.



Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 6:11 PM
To: softimage@listproc.autodesk.com
Subject: Re: Any way to distinguish between tangents and colors?

Thanks Steven -

Yeah, I'd like something a little more robust than relying on the default 
DataType since this is easily changeable.
I thought of looking for the "Tangent" property or the TangentOp2 operator, but 
these can be deleted/frozen away while still leaving behind valid tangents.



On Tue, Mar 5, 2013 at 6:03 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
this assumes no one goes out of there way to change the default datatype for 
tangents and vertex colors. ;(

On Tue, Mar 5, 2013 at 6:01 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
i believe they are both still 'vertexcolor', hence nicolas' question...

i would say, by name or 'DataType' parameter on the property?

from siutils import si
si = si() # win32com.client.Dispatch('XSI.Application')
from siutils import log # LogMessage
from siutils import disp # win32com.client.Dispatch
from siutils import C # win32com.client.constants

for item in si.Selection:
sampleClusters = 
item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
if sampleClusters.Count:
for cluster in sampleClusters:
for prop in cluster.LocalProperties:
if prop.Parameters("datatype"):
log("%s > %s > %s" % (prop.Name,prop.Type, 
prop.Parameters("datatype").Value))

# INFO : Vertex_Color > vertexcolor > 0
# INFO : Tangents > vertexcolor > 1

On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Check the cluster property type.

Matt

From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 5:53 PM
To: softimage@listproc.autodesk.com
Subject: Any way to distinguish between tangents and colors?

Hello list,

Does anyone know a way to tell whether a cluster contains tangents as opposed 
to vertex colors?

Thanks!

-Nicolas

RE: Any way to distinguish between tangents and colors?

[Matt Lind]

I should also add that my tools insist on putting our vertex colors in a named 
sample cluster.  While Softimage will dump user normal, vertex colors, and 
texture projections into that sample cluster if it's the most recent used, for 
whatever reason Softimage will not put tangent vertex color properties in that 
cluster.

Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Tuesday, March 05, 2013 6:47 PM
To: softimage@listproc.autodesk.com
Subject: RE: Any way to distinguish between tangents and colors?

I wouldn't worry about that.  We've been using tangents and vertex colors for 
years and never had that kind of problem.

The only (semi) reliable way we've been able to manage is from naming 
convention as Softimage insists on controlling everything else even if you try 
to change things.  For example, if you try to make your own clusters to put the 
cluster properties, Softimage will reuse or repurpose your clusters for other 
uses whether you like it or not.  I've complained quite a bit about this, but 
fell on deaf ears.



Matt



From: 
softimage-boun...@listproc.autodesk.com
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 6:11 PM
To: softimage@listproc.autodesk.com
Subject: Re: Any way to distinguish between tangents and colors?

Thanks Steven -

Yeah, I'd like something a little more robust than relying on the default 
DataType since this is easily changeable.
I thought of looking for the "Tangent" property or the TangentOp2 operator, but 
these can be deleted/frozen away while still leaving behind valid tangents.



On Tue, Mar 5, 2013 at 6:03 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
this assumes no one goes out of there way to change the default datatype for 
tangents and vertex colors. ;(

On Tue, Mar 5, 2013 at 6:01 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
i believe they are both still 'vertexcolor', hence nicolas' question...

i would say, by name or 'DataType' parameter on the property?

from siutils import si
si = si() # win32com.client.Dispatch('XSI.Application')
from siutils import log # LogMessage
from siutils import disp # win32com.client.Dispatch
from siutils import C # win32com.client.constants

for item in si.Selection:
sampleClusters = 
item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
if sampleClusters.Count:
for cluster in sampleClusters:
for prop in cluster.LocalProperties:
if prop.Parameters("datatype"):
log("%s > %s > %s" % (prop.Name,prop.Type, 
prop.Parameters("datatype").Value))

# INFO : Vertex_Color > vertexcolor > 0
# INFO : Tangents > vertexcolor > 1

On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Check the cluster property type.

Matt

From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 5:53 PM
To: softimage@listproc.autodesk.com
Subject: Any way to distinguish between tangents and colors?

Hello list,

Does anyone know a way to tell whether a cluster contains tangents as opposed 
to vertex colors?

Thanks!

-Nicolas

Re: Any way to distinguish between tangents and colors?

[Nicolas Burtnyk]

I'm worried that someone wants to use a vertex color cluster to actually
store colors and they want the higher precision of float4 so they set the
type to float4.
My exporter compresses tangents as packed normals (32 bits) so assuming
clusters with data type float4 will pretty much destory that data.


On Tue, Mar 5, 2013 at 6:49 PM, Matt Lind  wrote:

> I should also add that my tools insist on putting our vertex colors in a
> named sample cluster.  While Softimage will dump user normal, vertex
> colors, and texture projections into that sample cluster if it’s the most
> recent used, for whatever reason Softimage will not put tangent vertex
> color properties in that cluster.
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Matt Lind
> *Sent:* Tuesday, March 05, 2013 6:47 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* RE: Any way to distinguish between tangents and colors?
>
> ** **
>
> I wouldn’t worry about that.  We’ve been using tangents and vertex colors
> for years and never had that kind of problem.
>
> ** **
>
> The only (semi) reliable way we’ve been able to manage is from naming
> convention as Softimage insists on controlling everything else even if you
> try to change things.  For example, if you try to make your own clusters to
> put the cluster properties, Softimage will reuse or repurpose your clusters
> for other uses whether you like it or not.  I’ve complained quite a bit
> about this, but fell on deaf ears.
>
> ** **
>
> ** **
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [
> mailto:softimage-boun...@listproc.autodesk.com]
> *On Behalf Of *Nicolas Burtnyk
> *Sent:* Tuesday, March 05, 2013 6:11 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Any way to distinguish between tangents and colors?
>
> ** **
>
> Thanks Steven -
>
> ** **
>
> Yeah, I'd like something a little more robust than relying on the default
> DataType since this is easily changeable.
>
> I thought of looking for the "Tangent" property or the TangentOp2
> operator, but these can be deleted/frozen away while still leaving behind
> valid tangents.
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Mar 5, 2013 at 6:03 PM, Steven Caron  wrote:
>
> this assumes no one goes out of there way to change the default datatype
> for tangents and vertex colors. ;(
>
> ** **
>
> On Tue, Mar 5, 2013 at 6:01 PM, Steven Caron  wrote:
>
> i believe they are both still 'vertexcolor', hence nicolas' question...***
> *
>
> ** **
>
> i would say, by name or 'DataType' parameter on the property?
>
> ** **
>
> from siutils import si
>
> si = si() # win32com.client.Dispatch('XSI.Application')
>
> from siutils import log # LogMessage
>
> from siutils import disp # win32com.client.Dispatch
>
> from siutils import C # win32com.client.constants
>
> ** **
>
> for item in si.Selection:
>
> sampleClusters =
> item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
>
> if sampleClusters.Count:
>
> for cluster in sampleClusters:
>
> for prop in cluster.LocalProperties:
>
> if prop.Parameters("datatype"):
>
> log("%s > %s > %s" % (prop.Name,prop.Type,
> prop.Parameters("datatype").Value))
>
> ** **
>
> # INFO : Vertex_Color > vertexcolor > 0
>
> # INFO : Tangents > vertexcolor > 1
>
> ** **
>
> On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind 
> wrote:
>
> Check the cluster property type.
>
>  
>
> Matt
>
>  
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Nicolas Burtnyk
> *Sent:* Tuesday, March 05, 2013 5:53 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Any way to distinguish between tangents and colors?
>
>  
>
> Hello list,
>
>  
>
> Does anyone know a way to tell whether a cluster contains tangents as
> opposed to vertex colors?
>
>  
>
> Thanks!
>
>  
>
> -Nicolas
>
> ** **
>
> ** **
>
> ** **
>

RE: Any way to distinguish between tangents and colors?

[Matt Lind]

Then educate the users of your exporter and slap hands when they don't follow 
the rules.  Otherwise you have to ban the use of certain tools, or create your 
own version of the specific tools for use in production that supply the 
identifications you need to export reliably.

That's basically what we do here.  for vertex colors and texture projections, 
we only allow certain names to be used if users expect their tools to work.  
Amazing how much better artists behave when they realize they can't hit their 
deadlines without following the rules.

Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 6:59 PM
To: softimage@listproc.autodesk.com
Subject: Re: Any way to distinguish between tangents and colors?

I'm worried that someone wants to use a vertex color cluster to actually store 
colors and they want the higher precision of float4 so they set the type to 
float4.
My exporter compresses tangents as packed normals (32 bits) so assuming 
clusters with data type float4 will pretty much destory that data.


On Tue, Mar 5, 2013 at 6:49 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
I should also add that my tools insist on putting our vertex colors in a named 
sample cluster.  While Softimage will dump user normal, vertex colors, and 
texture projections into that sample cluster if it's the most recent used, for 
whatever reason Softimage will not put tangent vertex color properties in that 
cluster.

Matt



From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Matt Lind
Sent: Tuesday, March 05, 2013 6:47 PM
To: softimage@listproc.autodesk.com
Subject: RE: Any way to distinguish between tangents and colors?

I wouldn't worry about that.  We've been using tangents and vertex colors for 
years and never had that kind of problem.

The only (semi) reliable way we've been able to manage is from naming 
convention as Softimage insists on controlling everything else even if you try 
to change things.  For example, if you try to make your own clusters to put the 
cluster properties, Softimage will reuse or repurpose your clusters for other 
uses whether you like it or not.  I've complained quite a bit about this, but 
fell on deaf ears.



Matt



From: 
softimage-boun...@listproc.autodesk.com
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 6:11 PM
To: softimage@listproc.autodesk.com
Subject: Re: Any way to distinguish between tangents and colors?

Thanks Steven -

Yeah, I'd like something a little more robust than relying on the default 
DataType since this is easily changeable.
I thought of looking for the "Tangent" property or the TangentOp2 operator, but 
these can be deleted/frozen away while still leaving behind valid tangents.



On Tue, Mar 5, 2013 at 6:03 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
this assumes no one goes out of there way to change the default datatype for 
tangents and vertex colors. ;(

On Tue, Mar 5, 2013 at 6:01 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
i believe they are both still 'vertexcolor', hence nicolas' question...

i would say, by name or 'DataType' parameter on the property?

from siutils import si
si = si() # win32com.client.Dispatch('XSI.Application')
from siutils import log # LogMessage
from siutils import disp # win32com.client.Dispatch
from siutils import C # win32com.client.constants

for item in si.Selection:
sampleClusters = 
item.ActivePrimitive.Geometry.Clusters.Filter(C.siSampledPointCluster)
if sampleClusters.Count:
for cluster in sampleClusters:
for prop in cluster.LocalProperties:
if prop.Parameters("datatype"):
log("%s > %s > %s" % (prop.Name,prop.Type, 
prop.Parameters("datatype").Value))

# INFO : Vertex_Color > vertexcolor > 0
# INFO : Tangents > vertexcolor > 1

On Tue, Mar 5, 2013 at 5:54 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Check the cluster property type.

Matt

From: 
softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Nicolas Burtnyk
Sent: Tuesday, March 05, 2013 5:53 PM
To: softimage@listproc.autodesk.com
Subject: Any way to distinguish between tangents and colors?

Hello list,

Does anyone know a way to tell whether a cluster contains tangents as opposed 
to vertex colors?

Thanks!

-Nicolas