Get Data (group) -> Get Data (Point Position) -> Select in Array (with the index of the geo you want to copy) -> Switch Context -> Set PointPosition
should work. That's all presuming that the point count is the same for all the geo in the group, that is - otherwise it won't do anything, which seems to be ICE's default behaviour with mis-matching per point counts. On 23 January 2013 16:07, Sebastian Kowalski <[email protected]> wrote: > hey list, > > i am asking myself what type of array i get when i am reading point > position from a group of geometries.. > when i try to plug that into an vector per object i am expecting a long > list of vectors. but ice won't allow that. > to my surprise it is giving me a context mismatch saying that point > position is per point of the first element in the group. > now thats new.. i always thought that reading a group is losing all > connection to the elements its holding. > > kine.global makes no such fuss, thats simply an ordinary array of 4x4 > matrices. > its obvious that this has to do with the context, point position is per > point. kine.global is per object. > > what i am doing is ice merging a group of equal characters to one mesh. > reading and writing topo is kinda slow, so i thought just passing some > vector arrays on a freezed merged mesh should be faster. in my > understanding the point order of the merged mesh is starting with the first > (generated) element > point order and that would be just an offset by nbpoints of the other > elements in the group. (just checked it on a simpler scene and thats > correct) > normally i would try to build an array from set, but that somehow is > fucking up the point order… > reading point location and than the position crashes without warning. > > still can go the setting topo way, but that problem is showing me a > fundamental misunderstanding on my side, of how ice handles stuff. > > what you guys think? > > sebastian > > > > > > > >
