Can some one please explain what the workflow is … I have had a day of utter frustration.
a ducati bike = 185k points. 12 objects. 1 model.
Using ice to generate a point at each vertex.
Here’s what i have done,
empty point cloud
via get data (per object) then > get data point position > add point > icetree. all ok.
Want to do this using groups or some such but I can not get it to work.
12 objects manually not too bad, but what happens when i have 300 objects !!
Thanks for helping.
It’s working fine here (7.01).
Are you using a group geometry node in the ICE tree or a group at the scene level (that’s the one that works - drag and drop it into the ICE tree)? Is each individual object under the model a member of the group? Make sure to freeze your transforms on the objects or transform the point positions to global space in the ICE tree
Hi,
I made a group in the scene, then as you said dropped it onto the ice tree, exactly what i did. transforms were frozen.
But ( too many points in model?) when i do group vs the individual object, it does not create the ice vertex points for every geometry vertex, it seems as if its limited in the number of items in the group??? Its been very confusing… and when i add items it sometimes removes vertex’s that prev did make. !!!
Thats why i thought i double check the work flow thing, plus how many geo vertexs does in your testing have? 185k geo vertex’s? objects in model?
When I do a simple sphere and torus group yes then it works.
Strange I just tested this… if i merge the mesh and connect just the one item polymesh, then it works, just the one layer, but the same model as layers with group then no.
Totally confused. !!
Is there a limit on geo vertex’s? or objects?
CiaranM … and everyone else.
I get this message from Stephen ( what would we do without him ) Blair
“its a bit of a hack, but you can plug Group Geometry into Get Closest Points to get all the points. Then plug them into Add Point and voila.”
So i guess that the scene group > get group.pointposition > add point, is somewhat problematic.
I did also ask that there be a set of pages containing know problems and workarounds, in one location. Save us all.
Add your voice to that call.
Hmm, I don’t know that there is any problem with this:
scene group > get group.pointposition > add point
I’ll check it out.
It sounds better than my suggestion.
I experimented a bit
(XSI ModTool 7.5-ish)
The method works, but it seems to add as many points per object as the lowest number of vertices on the grouped objects. This seems like an array size issue, rather than a bug.
IE if you have a cube (8 vertices) & a sphere (58? vertices), the cube will be populated with 8 points, but the sphere will ALSO receive 8 points.
I offseted the points with the group members WS position, that worked fine too.
I didnt get further than that, or try to fix the array size issue.
Lunch time was over 
Yes, thats why i mentioned that it had 185k, if you use the get group add point method, you get very strange results. But with simple small prims, you dont see the problem.
If you add one object (any 1) to the group it’s works, add another it removes some particles from the first object, and by the time you add all 12, well you get the point
But the method by Stephen did work for the all object in the group, and it did create a particle at each and every vertex.
What the issue is, or resolution is, or why, I dont know, maybe Stephen/AD can look into it sometime, can send you the scene/model if you need it Stephen. Mail if required.
Well, all that messing with arrays for nothing.
Get Data: Group. ->
output “Value” to Geometry input of a “Generate Sample Set” node. ->
-Set Emission Type to “Points”
-Set Rate Type to “All Points”
output “Samples” to input positions of “Add Point” node->
execute.
It is simple after all! You don’t even need to transform the positions.
and i was going node happy trying to build new arrays per object…
Hi Zen,
congratulations on getting it working, and you saved me from having to explain the post on si-community, which reached the same conclusion as you did, your both smarter than i.
But I would like to say while a solution has been found, (thankyou) I dont think it’s "solved’, there is something strange with going on with scene group > get group.pointposition > add point.
I hope Stephen looks into it, because it may cause other problems later.
Again thank you zen for taking the time and effort to help, appreciate it.
your both smarter than i.
I actually felt a bit dumb when i found the answer
I dont think it’s "solved’, there is something strange with going on with scene group > get group.pointposition > add point.
Maybe you’re seeing another issue i am not, but:
I’m not sure, when you think about it, it makes sense this method would not work. A group doesn’t have point positions, so it passes the get data to the group members. These members don’t necessarily have the same number of points, and therefor require multiple array sizes. Get data outputs a single array, and subsequently a single array size.
Right now it seems to output the minimum array size - which is why you are missing points on the meshes with more points. If it output the maximum array size, you would be seeing many points at coords 0,0,0; unused array elements.
I could imagine it would be problematic for the get data to return multiple array sizes per group member. I guess get data could be made to output a single array of “merged” data of all the group members, but that would also be problematic as you’ll then never be able to access individual group members.
Generate sample set takes the output array of geometries, and considers it as a whole - allowing you to access each individual point location.
The added benefit is you do not need to transform the locations - which is easy with simple SRT tranforms but would otherwise be difficult with deformed mesh.
Exactly, if the group didn’t have pointpositions when exploring (picking), then I’d say ‘no problem’ your absolutely right, a group does not have them. Absolutely fine, makes logical sense, move on.
But since it does have pointpositions when picking with explorer, what should it return? The only logical conclusion that one can come to is ALL the point positions for the group’ed geometry.
so when I use ice to get Group.pointpositions, i can only logically see/read it as… the point positions of the items that comprise the group, to me is the only reasonable answer, as only the geometry can have point positions, as we both agree.
by extension it makes no sense to say, or for it to return, the minimum number of points, or the first object’s, or the etc, because like none of that is the manual. And it makes no logical sense nor sense interms of consistent workflow and usage with other ‘group’ operations inside softimage.
Thats pretty much why I thought Stephen should look at it, because AD might want to look at it from a change the manual perspective or do they keep it as is or do they look at the logic of what it does or remove it or is it something they need to change.
But zen, i really want to thank you for all your help, but I think this one now in AD’s court to take a look at this and decide what/if there is anything to do.
But since it does have pointpositions when picking with explorer, what should it return? The only logical conclusion that one can come to is ALL the point positions for the group’ed geometry.
What if you then want to access the points or attributes of only one of the grouped objects? Now that your group has merged the data, this is impossible. What is happening in ICE is just as you would do it in code; You create an array, or group, of objects. This is the get_data:Group. You then generate point positions from this; the generate_sample_set.
But zen, i really want to thank you for all your help, but I think this one now in AD’s court to take a look at this and decide what/if there is anything to do.
No problem Terry. I just wanted to explain that despite that it might not make sense to you “intuitively”, that it does make a lot of logical sense from a structure and data flow perspective, as i tried to show in my last post. I know ICE is supposed to be visual and artist friendly, but it still functions like code (and it should!). Even though no programming skills are required, i think a basic knowledge of coding/scripting is very beneficial to using ICE, if only to understand how the data is handled “behind the scenes”. ICE is, in fact, a visual programming interface.
Even though your solution seems logical to you, if the method were changed in your favor, it would cease to make logical sense for other people.
I think we are seeing it from different perspectives, and the reasoning i gave is that it should be consistent with other operations on groups. IE the you work on the group, not on the item.
a) If you only wanted to work on one item, then you can always pick it from the explorer. Not the group. Or create a group of that one item.
Example, if you have three items in a group, a sphere, a torus, a cube, then you deform by lattice, you dont deform only a subset of the items in the group, you deform the whole group. And thats exactly the correct logic. And all other operations on groups work the same. Exactly the same thing is true if your using physx, cloth etc.
Now, if you want to deform only one item eg a subset of the group see a)
That’s why if you take the point position from a group, it (if we are logically assuming the same workflow as other group operations) only makes sense to return all the points. (just like that lattice does when deforming !?)
Further to that, different operation of different things, depending on operation chosen means the integration of items with each other eg ice with lattices with dynamics with envelopes with cloth with deformers with physx etc become a convoluted problem, because you have inconsistent data selection, that’s not only a workflow problem for the user, but for the developers.
I think the most important thing is to look at it context of all the other operations that can be done on group, and their workflow, reasonably they should all operate in the same manner, this means users don’t get frustrated. From the development point of view, knowing that, means that at any point you ‘know’ what to expect from a function call to a group (development wise), wrt what data you were getting back, irrespective of ice/lattices etc, which would make the integration of all (and any new) items on the list above one hell of a lot easier, because you know what to expect in return irrespective of what was operating on the group and less prone to bugs, or limiting them to the new operations that your creating, not core system functionality. This way it becomes a case of making the new operation fit the existing system, not the other way around, which then will and does inevitably lead to bugs cropping up in new versions, that didn’t happen in older ones.
Either way Zen, but I dont think SI will make any change, any time soon, so in some ways both of our comments are moot. But its been a interesting conversation.
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.