What new attributes ICE should have?

[Bullit]

For me name and partial name, suffix, prefix of anything that can be named but priority for objects and groups.

[EricTRocks]

You can already get the object reference to string then split there using whatever character you are using as a separator using the split string node. You can always add these attributes yourself using scripting or in the ice tree and freezing the ice tree on the object which should bake the attributes in.

Any particular situation where you'd need this?

[Bullit]

Name is one of the most important data because it means we can designate that particular(s) object(s).
Make sense we get particle ID isn't it? Name is the ID for objects, groups...
If we want ICE to be a comprehensive language , not just particle tool, then it should also have a name(partial) name attribute, specially useful when dealing with massive quantities of objects.

I wasn't thinking about me specially, but about City Generation by Chris_TC https://www.si-community.com/forum/v ... 7&start=50 I had a case , i linked it , but i can circumvent it.


Btw like the title says this also for others to say what other attributes they think deserve to be in ICE.

[Chris_TC]

I'm not really missing ICE attributes, but there are a few other things ICE needs badly in my opinion:

1) A way to visualize partial ICE trees and the attribute values at that point. Houdini does this, and ICE really needs the same option. Having to unplug ports just to see what happens up until a certain point is awful.

2) Good access to text. ICE would be great at motion graphics, but right now doing text animation in ICE is no fun.

3) Access to image and video clips on a pixel level, for both writing and reading. Come on now: ICE is already multithreaded, pixels can practically be treated like particles. Who's to stop us from building all sorts of awesome image manipulation compounds? This leads me to:

4) Using attribute shaders to interconnect ICE with the render tree is silly. Merge the two already. Drop redundant nodes (e.g. Rescale in ICE vs. Change Range in the Render Tree)

5) Access to curve generation / modification.

6) All modeling operations in Softimage must have ICE equivalents. So much so that any given modeling stack could be rebuilt entirely in ICE. Maybe even so much so that the modeling stack is replaced by an automatically built ICE tree.

7) An easy way to set up compound interaction. I can already do this with scripting, but that's more hassle than it should be. Imagine you have a compound that needs you to chose a base mesh for instancing and another mesh for reading a texture. Exposing the compound to the menu is quick and easy (even though we still can't chose the menu freely). However, launching picking sessions requires scripting, when most compounds actually need object or component inputs.

I could go on (let us drag and drop compound port order, PLEASE) and on, but I'll stop it there.

[Pooby]

The Geometry input should be able to be filtered. At the moment, you can 'get closest location' to the whole thing, and that's it.
Often I want to get closest location of a part of the input geometry, not the entire geometry and there is no direct way to do that.

[Pooby]

Properly working arrays within arrays would be another big one for me.

[EricTRocks]

Properly working arrays within arrays would be another big one for me.

For clarity's sake, what isn't working in the current implementation? If any devs look at this thread for what needs fixing having detailed info would be helpful.

[rray]

Direct access to fcurves that are existing in the scene would be pretty useful.

And maybe something to build an fcurve out of an array of control points.

Arrays as valid elements of arrays with full support in all other nodes gets my vote too, this would be even more useful (There's 2D arrays but not "native" and very limited you can't plug anything into anything else)

And a render tree support for ICE arrays.. I have to stop here

[vrMan]

i think a script node will be cool to use python inside ice tree ,something like thinking particle script node (maxscript) .

[EricTRocks]

i think a script node will be cool to use python inside ice tree ,something like thinking particle script node (maxscript) .

Python isn't multi-threaded unless you're talking Python 3 from what I hear. Even still, industry wide, Python 3 hasn't been adopted yet. If there is another scripting language that is and can work well with ICE I'm up for it. However even the way python is built in is not efficient enough for this. Thus why you never write a SCOP in Python unless it's intended to be frozen off. Otherwise you use jscript. It's been discussed before on this forum in other threads though.

The idea of a script node is good IMHO. Implementation is what would need to get worked out.

[Pooby]

To clarify my earlier request of array improvements, I'd like to be able to find array attributes of the neighbouring or nearby points, for example. But you can't, because that would deliver an array of an array, and ICE won't allow that.

Being able to write to groups would be hugely useful too.

[Letterbox]

I could go on and on, but I'll stop it there.

Why?
There were some good ones in there... the others maybe too. You never know you might get want you want, if you post it.

[Chris_TC]

Why?
There were some good ones in there...

I wanted to stick to what I consider most important instead of flooding the thread entirely. I think that way there's a better chance we may see some of it in a future version.

The idea of a script node is awesome by the way, I totally want one.

[iamVFX]

To clarify my earlier request of array improvements, I'd like to be able to find array attributes of the neighbouring or nearby points, for example. But you can't, because that would deliver an array of an array, and ICE won't allow that.

Isn't it per point array?

[Pooby]

It is per point, but finding neighbours single values delivers an array, so if the value you need is an array then ICE can't handle it, as it would have to deliver an array of arrays.

[iamVFX]

It is per point, but finding neighbours single values delivers an array, so if the value you need is an array then ICE can't handle it, as it would have to deliver an array of arrays.

You can calculate what you need with use of "virtual points" of generate sample set node which iterates over each location of the array. It's weird at first, but you can get used to it if you really need it