Same Nodes outputing different data? o_O

[probiner]

Finished the code for my python bend deformer plugin and, since I built an ICE tree in the process, heck, lets close this baby and release a compound. One of the things I prefer compounds over isolated plugins is that they can pass data to subsequent operations or have their parameters driven by other trees. So in this case I did not just wanted to output the bend positions result but also Rotation at each point, the Bottom/Top gradient, the Offsets Matrix, etc. But.... When inspecting the data that was getting put out there was a mismatch with the data being used in the bend processing o_O

Data Display for the Bend: http://prntscr.com/8b1q51
Data Display for an ouput port: http://prntscr.com/8b1qed

So the second one looks wrong to me as I want to output the bend rotation to used it on polygon islands or instances like I did in LightWave: https://www.youtube.com/v/Fd-ZeiNAmUY?start=172&end=178

Also, to my suprise when I tested the old WIP compound and output the data to actually bend some polygon islands... It worked just fine (gif below)... Is it because it's all being used to the same execution port (Set Point Position) ?


I'm a bit confused. Maybe in the end on a practical application this ends up not being a problem like it happened on my test, but I'm wondering why is this...

Thanks

[Mathaeus]

Well, obviously you need to match the data somehow. ICE don't know where is an polygon island, in advance. If goal is, to have a generic bending of an array of elements, ICE way could be, to store the result in array - or, to use point cloud. Later, in another ICE tree on object that bends, you localize the input, somehow. Or, just to save the 'bend generator' as an compound, then to use it later in specialized compounds, directly on bending object.
According to Lightwave screenshots, probably there's some under hood mechanism in LW, for applying these bends. Afaik, once you're in ICE, it's your part of job, to make an connection.

[probiner]

Hi Matheus
Thanks for chiming in.
Did you see the screenshots? No Polygon Island involved, just a single mesh block. It's showing the rotation per point.
As long I use those outputs in the same flow as the first output, the data looks correct though.

Cheers

[Mathaeus]

Hi Matheus
Thanks for chiming in.
Did you see the screenshots?
Cheers

To admit honestly, only partially. Nodes were too small to read, so I switched to second part of question. My fault.
As far as I know, there are cases, when ICE just omits (optimize...) to deliver some data, let's say if you just set some factory attribute, for use in another ICE tree for another purpose (like self.orientation in point context, to drive something else on mesh, or like), while this attribute is not actualized in original context. Does not happen with custom attribute.
But, according to ICE visualization in viewport, data seems to be there, but wrong data. I'd checkout ICE tree. Perhaps it wouldn't hurt to replace the 'axis and angle' by something else, like 'direction to rotation'. Afaik, 'axis and angle' likes to go weird, if there are two or more of them one after another. Is there some too small angle between axes. Significantly, error became different exactly in 'up' pole.

[FXDude]

Hi,

So what is more precisely the difference between the different results?

The connections that you point to are exactly the same, so its parameters that change?

Or it's after doing what that gives incorrect results?

[Mathaeus]

Hi,

So what is more precisely the difference between the different results?

I think it's ICE visualizer in view port, showing completely different result of 'rotate vector' vs 'orientation'. To make it worse, wrong result does not look like 'no data' - as 'no data' should be displayed as uniform, nice row of default values. It's looking more like inability of ICE to get the desired result - for any reason. Like too small angle between some axes, or who knows what else.

[probiner]

So when I change the order.... magic... looks good... o_O

self.rot set after bend


self.rot set before bend



One's got to be careful, but I don't know why? That data itself it's the same... I just changed the point position meanwhile, really strange.


Here's a gif showing the different order data being applied to the points after the bend. The operations on the point have the same exact order (Bend , then add up Up Vector) the only thing it changed is the order of when I've set the rotation data. I can't make sense of this...


self.rot set after bend


self.rot set before bend



Thanks for any enlightenment.
Cheers

[probiner]

Ok, I get what's going on now. Since there's use of Point Position to generate the angle, when the parameter is set the PP is already changed so, different values. I would have to have an execute port to guarantee that those ports work as expected regardless.

Thanks

[FXDude]

Hum! Could you perhaps store PP's before they are processed in an attribute, to then reffer to them further down the chain?

(hopefully not needing another tree for ini?)

[probiner]

Hum! Could you perhaps store PP's before they are processed in an attribute, to then reffer to them further down the chain?

(hopefully not needing another tree for ini?)

Need an execute port, which is ok I just don't cherish much as I try to keep things like a pure function and never liked much the need to have to store values and having a red node having the demand to be connected just to turn it valid.