additional: now i understand how the build array from set works and why i get a different point order. first it gets all values of every first element of all the sets in the group than the second … that is making sense. so i need to rearrange that array. problem is that the every character consist of several geomtries with different point counts… so there goes my rearranging
Am 23.01.2013 um 17:07 schrieb Sebastian Kowalski <[email protected]>: > 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 > > > > > > >
