Lagoa inconsistency???

[Hirazi Blue]

While playing with Lagoa for not quite but almost the first time, I noticed something peculiar. Nothing show-stopping obviously, but slightly odd nonetheless. “Regular” ICE always seemed to (and still does) work with geometry dragged into the ICE Tree and connected by “Value”, where Lagoa seems to require the “Out Name” for similar operations – i.e. emitter and collision object. Is this inconsistency by design? Is it even truly an inconsistency or just something only Hirazi Blue thinks about for longer than two seconds?


And yes, I know it's technically an addon, but one that seems pretty well integrated into Softimage, so some constistency might be expected

[Mathaeus]

Sooo..... it seems you never even tried, for example, Kristinka Hair....
'In Name' as a counterpart inside the compound, allows to use geometry query, as well as some data that isn't easy to get with geometry queries. Let's say, number of points on mesh or point cloud, custom attributes at object context, so on.
I would like to imagine factory nodes as a basic system, where isn't so hard to keep the 'consistency'. But, when someone is trying to do something more specific, even believable effect, life become .... not so consistent

Cheers

[fabricio.chamon]

Hi Hirazi,

I don't think it's inconsistency. It's the only way one can get more than geometry data from an object.
Let's say your compound will have to deal with pointpositions and global transforms, how would you retrieve the global transforms if you pass only the geometry data?

Giving the name you can retrieve any attribute you want, and I think in fact that this should be the default behavior on all compounds...also it makes easier for you to modify your compound later on (meaning: retrieving more data other than than geometry) and don't break all your connections for this compound on your ice trees...

just my 2 cents..

[Hirazi Blue]

Yeah, the whole "In Name" method seems to make much more sense. Even I can see that! But looking at the way emitter objects and collision objects (among others) "introduce" themselves in the ICE Tree by "Value" it seemed somewhat of an inconsistency. One methodology to rule them all, and all that! ;)

@Mathaeus - I tend to judge 3rd party addons differently from apparent "factory" addons. Inconsistency between the application and a custom addon doesn't bother me as much. Inconsistency between parts of what is arguably one and the same software slightly more so... And I know, Lagoa technically is a 3rd party addon. But it's seem to be a little too well-integrated, for that to really be an argument, thus making the inconsistency noticable.

Again, no big deal. Just something I noticed...
;)

[grahamef]

In general, I think it's better to use "lowest" possible input for a port, e.g., "geometry" instead of "inname". That's because if the compound is being used where it's deeply nested inside another, you might not have access to "higher" values like inname without going back up and passing them down recursively. However if you do happen to have access to inname, then it's trivial to get geometry or anything else. Then later if you want you can wrap it all up in a separate user-friendly compound that uses higher-level inputs.

But that's just my personal philosophy.