As an operator apparently cannot have ICEAttribute output ports, I instead pass the polymesh and pointcloud primitives and add the operator to the pointclud.
CustomOperator customOperator =
> pickedObject.GetActivePrimitive().AddCustomOp( L"HairCommandsGenerate",
> inputs,L"HairCommandsGenerate",siConstructionModePrimaryShape ) ;
>
In the update callback I grab the create or grab the ICEAttribute from the
pointcloud and fetch its 2DArray.
ICEAttribute rootsAttribute = outputCloud.GetGeometry().AddICEAttribute(
> "hairCommandsRoots", XSI::siICENodeDataVector3,
> XSI::siICENodeStructureArray, XSI::siICENodeContextSingleton);
> CICEAttributeDataArray2D<MATH::CVector3f> rootsArray2D;
> rootsAttribute.GetDataArray2D(rootsArray2D);
>
After this a bunch of calculations are performed, and then we resize the
2DArray and memcpy over the new data
CICEAttributeDataArray< MATH::CVector3f > data;
>
if (rootIO.size()>0)
> {
> rootsArray2D.ResizeSubArray(0,0,data);
> rootsArray2D.ResizeSubArray(0,rootIO.size(),data);
> memcpy(&data[0],&rootIO[0],sizeof(MATH::CVector3f)*rootIO.size());
> }
>
I just remembered why I resize the array to 0 before setting it to the
correct size.
Earlier on, only resizing the array to the correct size would randomly
result in half the array being zeroed out.
Doing the above without first resizing the array to 0 now just gives me
this:
[image: Inline image 1]
Only resizing the array once (on creation, first to 0 then to the correct
size) crashes on successive evaluations.
On Tue, Nov 5, 2013 at 1:48 AM, Alok Gandhi <alok.gandhi2...@gmail.com>wrote:
> Ok, I get it. Can you share how you are pushing the data from the
> operator to ice tree ?
>
> Sent from my iPhone
>
> On Nov 4, 2013, at 7:23 PM, Mathias N <mdawn...@gmail.com> wrote:
>
> To be more specific, in addition to reading the point positions I also
> grab a myriad of custom properties (userdatamaps and userdatablobs) which
> are combined to generate the attribute data.
>
> Seeing as the operator itself is evaluating correctly, I felt it best to
> use a simplified example.
>
>
> On Tue, Nov 5, 2013 at 1:15 AM, Alok Gandhi <alok.gandhi2...@gmail.com>wrote:
>
>> Is there a particular reason you are reading the pointposition from a
>> custom operator and not from the ice tree which is supposed to have the
>> data ?
>>
>>
>> On Mon, Nov 4, 2013 at 6:48 PM, Mathias N <mdawn...@gmail.com> wrote:
>>
>>> I have set up a custom operator that reads the point positions of a mesh
>>> and spits an array into a per-object ICEAttribute.
>>>
>>> For the most part this setup is working flawlessly, but it appears to be
>>> updating on a 1-frame delay.
>>>
>>> The custom operator is in the modeling stack, with the ICE tree that
>>> reads the attribute it creates in the animation stack.
>>>
>>> The operator itself is being evaluated, and logging to console confirms
>>> that it is generating the expected output, but when reading the same
>>> attribute in the ICE tree the values are from the previous evaluation
>>> rather than the current one.
>>>
>>> I had a go at deleting and re-creating the attribute on each update,
>>> hoping that it would counteract any caching that might be occurring, but it
>>> had no effect.
>>>
>>> Any Ideas? Is using a customer operator to write to ICEAttributes a
>>> no-no?
>>>
>>> Using Softimage 2013 SP1
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>
>
<<arrayerr.png>>
