How to get data in an array in a pattern? - c++
I am trying to get the x and y values out of a PointCloud2 data. This data is stored in an array in bytes of float32's. My question is, how can I get only the x and y data?
I will add a snippet of what the PointCloud2 data looks like, but for now I'd like to just be able to get the x - data. So for every 16 values, I only want the first 4 (I want the first 4 as this is how it is ordered and because the float32's are decomposed into 4 bytes each).
My original thought process was just to use a loop, but I am worried this may be too slow. This is as my array has more than 2000 values and I am getting 15 of these arrays per second. Is there any other way of doing this?
seq: 296
stamp:
secs: 1553456947
nsecs: 421859979
frame_id: "cloud"
height: 1
width: 811
fields:
-
name: "x"
offset: 0
datatype: 7
count: 1
-
name: "y"
offset: 4
datatype: 7
count: 1
-
name: "z"
offset: 8
datatype: 7
count: 1
-
name: "intensity"
offset: 12
datatype: 7
count: 1
is_bigendian: False
point_step: 16
row_step: 12976
data: [108, 171, 8, 191, 107, 171, 8, 191, 0, 0, 0, 0, 0, 0, 113, 70, 167,
197, 8, 191, 103, 95, 10, 191, 0, 0, 0, 0, 0, 240, 115, 70, 99, 101, 9, 191,
127, 161, 12, 191, 0, 0, 0, 0, 0, 200, 106, 70, 99, 50, 5, 191, 202, 237, 9,
191, 0, 0, 0, 0, 0, 76, 82, 70, 200, 22, 235, 190, 200, 74, 246, 190, 0, 0,
0, 0, 0, 132, 52, 70, 186, 111, 255, 190, 99, 95, 7, 191, 0, 0, 0, 0, 0, 24,
60, 70, 227, 1, 8, 191, 89, 217, 17, 191, 0, 0, 0, 0, 0, 64, 93, 70, 216,
183, 8, 191, 245, 84, 20, 191, 0, 0, 0, 0, 0, 236, 112, 70, 195, 94, 8, 191,
64, 177, 21, 191, 0, 0, 0, 0 ...
I would also like to add that I am a beginner at this sort of thing. I spoke with my friend and he said using mutex threading for this, but that seems way over my head.
Thanks!
I suspect that you'll be surprised how fast modern hardware can loop through 30000 points.
You should start off with your loop and some basic considerations. For example, for storage of our X/Y coordinates in a vector, reserve the required space in the vector before you enter your loop to avoid extra memory allocations. Once you have your loop working, evaluate the performance and maybe post another question if you think that your code is too slow.
A helpful quote by Donald E. Knuth that may apply:
Premature optimization is the root of all evil.
Edit; to provide some context: We had an application running on a low end i5 processor collecting 76,800 3D points at 15 fps via the Kinect SDK or via OpenNI (different sensor). We'd loop through the points and apply a basic transformation before storing each point into a pcl::PointCloud. We'd then loop through the point cloud points again for some analysis. The analysis portion far outweighed the cost of any basic loop. You will probably end up worrying about optimizing whatever evaluation logic you want apply to your data rather than basic things such as looping over the points.
Related
Faster tetrahedron-tetrahedron intersection
For one project of mine I require reliable detection of intersection between two tetrahedrons in 3D space. I do not need the points/lines/faces just to know if intersection is present or not. Touching is considered intersection too but common triangle face is not considered as intersection. After quite a struggle to achieve this as fast as possible my solution boiled to this horribility: let have tetrahedrons v0,v1 each tetrahedron has 4 triangles t[4] where each triangle has 3 points p0,p1,p2 and normal vector n. compute planes of all 4 sides of both tetrahedrons so any point p on plane is given by equation dot(p,n) + d = 0 where n is normal of the plane. As that is known this boils to computing d D0[i] = -dot(v0.t[i].p0,v0.t[i].n) D1[i] = -dot(v1.t[i].p0,v1.t[i].n) i = { 0,1,2,3 } for each triangle of each tetrahedron test any combination of triangle vs triangle intersection between v0,v1 so just loop between all 16 combinations and use triangle vs triangle intersection. The triangle v0.t[i] vs triangle v1.t[j] intersection boils down to this: compute intersection between planes this is obviously ray (for non parallel planes) so simple cross product of the plane normals will give the ray direction dir = cross(v0.t[i].n,v1.t[j].n) now it is just matter of finding intersection point belonging to both planes. Exploiting determinant computation directly from the cross product of the normals the ray computation is like this: // determinants det=vector_len2(dir); d0=D0[i]/det; d1=D1[j]/det; // position pos = d0*cross(dir,v1.t[j].n) + d1*cross(v0.t[i].n,dir); for more info see: SO/SE: Line of intersection between two planes Wolfram: Plane-Plane Intersection compile signed distance intervals of triangle ray intersection for each triangle so simply compute intersection between ray and each edge line of triangle remembering min and max distance from pos. We do not need the actual point just the scalar distance from pos which is the parameter returned by line/ray intersection. check if ranges of both triangles overlaps or not if overlaps than v0,v1 intersect ... if no overlap occurs for all of the 16 tests than v0,v1 does not intersect. As you can see it is a lot of stuff to compute. My linear algebra and vector math knowledge is very limited to things I use so there is a high chance there might be much better approach for this. I tried a lot of things to ease up this without any luck (like using bbox,bsphere, using more simple test exploiting that both ray and triangle edges are on the same plane etc) but the result was either slower or even wrong (not counting edge cases correctly). Here my actual C++ implementation: //--------------------------------------------------------------------------- bool tetrahedrons::intersect_lin_ray(double *a0,double *a1,double *b0,double *db,double &tb) { int i0,i1; double da[3],ta,q; vector_sub(da,a1,a0); ta=0.0; tb=0.0; i0=0; i1=1; if (fabs(da[i0])+fabs(db[i0])<=_zero) i0=2; else if (fabs(da[i1])+fabs(db[i1])<=_zero) i1=2; q=(da[i0]*db[i1])-(db[i0]*da[i1]); if (fabs(q)<=_zero) return 0; // no intersection // intersection ta,tb parameters ta=divide(db[i0]*(a0[i1]-b0[i1])+db[i1]*(b0[i0]-a0[i0]),q); tb=divide(da[i0]*(a0[i1]-b0[i1])+da[i1]*(b0[i0]-a0[i0]),q); if ((ta<0.0)||(ta>1.0)) return 0; // inside line check return 1; } //--------------------------------------------------------------------------- bool tetrahedrons::intersect_vol_vol(_vol4 &v0,_vol4 &v1) // tetrahedron v0 intersect tetrahedron v1 ? { int i,j,_ti,_tj; _fac3 *f0,*f1; double pos[3],dir[3],p[3],det,D0[4],D1[4],d0,d1,t,ti0,ti1,tj0,tj1; // planes offset: dot(p,v0.t[i].n)+D0[i] = 0 , dot(p,v1.t[j].n)+D1[j] = 0 for (i=0;i<4;i++) { D0[i]=-vector_mul(pnt.pnt.dat+fac.dat[v0.t[i]].p0,fac.dat[v0.t[i]].n); D1[i]=-vector_mul(pnt.pnt.dat+fac.dat[v1.t[i]].p0,fac.dat[v1.t[i]].n); } // plane plane intersection -> ray for (i=0;i<4;i++) for (j=0;j<4;j++) { f0=fac.dat+v0.t[i]; f1=fac.dat+v1.t[j]; // no common vertex if ((f0->p0==f1->p0)||(f0->p0==f1->p1)||(f0->p0==f1->p2)) continue; if ((f0->p1==f1->p0)||(f0->p1==f1->p1)||(f0->p1==f1->p2)) continue; if ((f0->p2==f1->p0)||(f0->p2==f1->p1)||(f0->p2==f1->p2)) continue; // direction vector_mul(dir,f0->n,f1->n); det=vector_len2(dir); if (fabs(det)<=_zero) continue; // parallel planes? d0=D0[i]/det; d1=D1[j]/det; // position vector_mul(p,dir,f1->n); vector_mul(pos,p,d0); vector_mul(p,f0->n,dir); vector_mul(p,p,d1); vector_add(pos,pos,p); // compute intersection edge points _ti=1; _tj=1; if (intersect_lin_ray(pnt.pnt.dat+f0->p0,pnt.pnt.dat+f0->p1,pos,dir,t)){ if (_ti) { _ti=0; ti0=t; ti1=t; } if (ti0>t) ti0=t; if (ti1<t) ti1=t; } if (intersect_lin_ray(pnt.pnt.dat+f0->p1,pnt.pnt.dat+f0->p2,pos,dir,t)){ if (_ti) { _ti=0; ti0=t; ti1=t; } if (ti0>t) ti0=t; if (ti1<t) ti1=t; } if (intersect_lin_ray(pnt.pnt.dat+f0->p2,pnt.pnt.dat+f0->p0,pos,dir,t)){ if (_ti) { _ti=0; ti0=t; ti1=t; } if (ti0>t) ti0=t; if (ti1<t) ti1=t; } if (intersect_lin_ray(pnt.pnt.dat+f1->p0,pnt.pnt.dat+f1->p1,pos,dir,t)){ if (_tj) { _tj=0; tj0=t; tj1=t; } if (tj0>t) tj0=t; if (tj1<t) tj1=t; } if (intersect_lin_ray(pnt.pnt.dat+f1->p1,pnt.pnt.dat+f1->p2,pos,dir,t)){ if (_tj) { _tj=0; tj0=t; tj1=t; } if (tj0>t) tj0=t; if (tj1<t) tj1=t; } if (intersect_lin_ray(pnt.pnt.dat+f1->p2,pnt.pnt.dat+f1->p0,pos,dir,t)){ if (_tj) { _tj=0; tj0=t; tj1=t; } if (tj0>t) tj0=t; if (tj1<t) tj1=t; } if ((_ti)||(_tj)) continue; if ((ti0>=tj0)&&(ti0<=tj1)) return 1; if ((ti1>=tj0)&&(ti1<=tj1)) return 1; if ((tj0>=ti0)&&(tj0<=ti1)) return 1; if ((tj1>=ti0)&&(tj1<=ti1)) return 1; } return 0; }; //--------------------------------------------------------------------------- It is a part of a much larger program. The _zero is just threshold for zero based on min detail size. _fac3 is triangle and _vol4 is tetrahedron. Both points and triangles are indexed from pnt.pnt.dat[] and fac.dat[] dynamic lists. I know is weird but there is a lot going on behind it (like spatial subdivision to segments and more to speed up the processes which is this used for). the vector_mul(a,b,c) is a=cross(b,c) and a=dot(b,c) product (which depends on c if it is vector or not). I would rather avoid any precomputed values for each triangle/tetrahedron as even now the classes holds quite a lot of info already (like parent-ship, usage count etc). And as I am bound to Win32 the memory is limited to only around 1.2 GB so any additional stuff will limit the max size of mesh usable. So what I am looking for is any of these: some math or coding trick to speed current approach if possible different faster approach for this I am bound to BDS2006 Win32 C++ and would rather avoid using 3th party libs. [Edit1] sample data Here is tetrahedronized pointcloud as a sample data for testing: double pnt[192]= // pnt.pnt.dat[pnt.n*3] = { x,y,z, ... } { -0.227,0.108,-0.386, -0.227,0.153,-0.386, 0.227,0.108,-0.386, 0.227,0.153,-0.386, 0.227,0.108,-0.431, 0.227,0.153,-0.431, -0.227,0.108,-0.431, -0.227,0.153,-0.431, -0.227,0.108,0.429, -0.227,0.153,0.429, 0.227,0.108,0.429, 0.227,0.153,0.429, 0.227,0.108,0.384, 0.227,0.153,0.384, -0.227,0.108,0.384, -0.227,0.153,0.384, -0.023,0.108,0.409, -0.023,0.153,0.409, 0.023,0.108,0.409, 0.023,0.153,0.409, 0.023,0.108,-0.409, 0.023,0.153,-0.409, -0.023,0.108,-0.409, -0.023,0.153,-0.409, -0.318,0.210,0.500, -0.318,0.233,0.500, 0.318,0.210,0.500, 0.318,0.233,0.500, 0.318,0.210,-0.500, 0.318,0.233,-0.500, -0.318,0.210,-0.500, -0.318,0.233,-0.500, -0.273,-0.233,0.432, -0.273,0.222,0.432, -0.227,-0.233,0.432, -0.227,0.222,0.432, -0.227,-0.233,0.386, -0.227,0.222,0.386, -0.273,-0.233,0.386, -0.273,0.222,0.386, 0.227,-0.233,0.432, 0.227,0.222,0.432, 0.273,-0.233,0.432, 0.273,0.222,0.432, 0.273,-0.233,0.386, 0.273,0.222,0.386, 0.227,-0.233,0.386, 0.227,0.222,0.386, -0.273,-0.233,-0.386, -0.273,0.222,-0.386, -0.227,-0.233,-0.386, -0.227,0.222,-0.386, -0.227,-0.233,-0.432, -0.227,0.222,-0.432, -0.273,-0.233,-0.432, -0.273,0.222,-0.432, 0.227,-0.233,-0.386, 0.227,0.222,-0.386, 0.273,-0.233,-0.386, 0.273,0.222,-0.386, 0.273,-0.233,-0.432, 0.273,0.222,-0.432, 0.227,-0.233,-0.432, 0.227,0.222,-0.432, }; struct _fac3 { int p0,p1,p2; double n[3]; }; _fac3 fac[140]= // fac.dat[fac.num] = { p0,p1,p2,n(x,y,z), ... } { 78, 84, 96, 0.600,-0.800,-0.000, 72, 84, 96, -0.844,-0.003,-0.537, 72, 78, 84, -0.000,1.000,-0.000, 72, 78, 96, -0.000,-0.152,0.988, 6, 84, 96, -0.859,0.336,-0.385, 6, 78, 96, 0.597,-0.801,0.031, 6, 78, 84, 0.746,-0.666,0.000, 6, 72, 96, -0.852,-0.006,-0.523, 6, 72, 84, -0.834,0.151,-0.530, 78, 84,147, 0.020,1.000,-0.000, 72, 84,147, -0.023,-1.000,-0.015, 72, 78,147, -0.000,1.000,0.014, 78, 96,186, 0.546,-0.776,0.316, 6, 96,186, -0.864,0.067,-0.500, 6, 78,186, 0.995,0.014,-0.104, 78, 84,186, 0.980,-0.201,0.000, 6, 84,186, -0.812,0.078,-0.578, 72, 96,186, -0.865,-0.011,-0.501, 6, 72,186, -0.846,0.071,-0.529, 6, 84,147, -0.153,-0.672,-0.724, 6, 72,147, -0.222,-0.975,-0.024, 84,135,147, 0.018,1.000,-0.013, 78,135,147, -0.311,0.924,0.220, 78, 84,135, 0.258,0.966,-0.000, 72,135,147, -0.018,1.000,0.013, 72, 78,135, -0.000,0.995,0.105, 96,132,186, -0.000,-1.000,-0.000, 78,132,186, 0.995,-0.087,-0.056, 78, 96,132, 0.081,-0.256,0.963, 84,132,186, 0.976,-0.209,-0.055, 78, 84,132, 0.995,-0.101,0.000, 84,147,186, -0.190,-0.111,-0.975, 6,147,186, -0.030,-0.134,0.991, 0, 96,186, -0.587,-0.735,-0.339, 0, 72,186, 0.598,0.801,-0.031, 0, 72, 96, -0.992,-0.087,-0.092, 72,147,186, -0.675,-0.737,-0.044, 135,147,189, 0.000,1.000,-0.000, 84,147,189, -0.018,0.980,-0.197, 84,135,189, 0.126,0.992,-0.007, 81, 84,135, -0.183,0.983,-0.023, 78, 81,135, -0.930,-0.000,0.367, 78, 81, 84, 1.000,-0.000,0.000, 105,135,147, -0.000,1.000,0.000, 72,105,147, -0.126,0.992,0.007, 72,105,135, 0.018,0.980,0.197, 72, 81,135, -0.036,0.996,-0.082, 72, 78, 81, -0.000,-0.000,1.000, 96,120,132, -0.000,-1.000,-0.000, 78,120,132, 0.685,-0.246,0.685, 78, 96,120, -0.000,-0.152,0.988, 132,180,186, -0.000,-1.000,0.000, 84,180,186, 0.000,-0.152,-0.988, 84,132,180, 0.995,-0.101,-0.000, 147,150,186, 0.101,0.010,0.995, 84,150,186, -0.100,-0.131,-0.986, 84,147,150, -0.190,-0.019,-0.982, 96,114,186, 0.000,-1.000,0.000, 0,114,186, -0.584,-0.729,-0.357, 0, 96,114, -0.991,0.134,0.000, 0,147,186, -0.144,-0.058,-0.988, 0, 72,147, -0.926,-0.374,-0.052, 72, 96,114, -0.995,-0.101,0.000, 0, 72,114, -0.993,-0.077,-0.093, 75,147,189, -0.001,1.000,-0.012, 75,135,189, 0.018,1.000,-0.001, 75,135,147, -0.016,-1.000,0.012, 147,159,189, -0.000,1.000,-0.000, 84,159,189, -0.000,0.985,-0.174, 84,147,159, -0.025,-0.999,-0.025, 81,135,189, -0.274,0.962,0.015, 81, 84,189, 0.114,0.993,-0.023, 75,105,147, -0.115,-0.993,0.006, 75,105,135, 0.017,-0.983,0.181, 72, 75,147, -0.999,-0.000,-0.051, 72, 75,105, 0.599,-0.000,0.801, 81,105,135, -0.009,0.996,-0.093, 72, 81,105, -0.036,0.991,0.127, 120,126,132, -0.000,-1.000,-0.000, 78,126,132, 0.995,-0.101,-0.000, 78,120,126, -0.000,-0.152,0.988, 0,150,186, 0.101,-0.000,0.995, 0,147,150, -0.000,-0.000,1.000, 144,150,186, 0.000,-1.000,0.000, 84,144,186, -0.091,-0.133,-0.987, 84,144,150, -0.000,0.249,0.968, 147,150,159, -0.705,-0.071,-0.705, 84,150,159, -0.125,-0.100,-0.987, 114,150,186, 0.000,-1.000,0.000, 0,114,150, -0.998,-0.000,-0.059, 72,114,147, -0.995,-0.088,-0.052, 0,114,147, -0.906,-0.365,-0.215, 93,147,189, -0.009,-0.996,-0.093, 75, 93,189, 0.020,1.000,0.000, 75, 93,147, -0.237,-0.971,-0.000, 75, 81,189, -0.000,1.000,-0.012, 75, 81,135, -0.000,-0.995,0.096, 93,159,189, -0.000,-0.987,-0.160, 93,147,159, -0.069,-0.995,-0.069, 84, 93,189, 0.036,0.991,-0.127, 84, 93,159, -0.036,-0.993,-0.113, 84, 87,189, -0.599,-0.000,-0.801, 81, 87,189, -0.120,0.993,-0.000, 81, 84, 87, 1.000,0.000,0.000, 75, 81,105, -0.000,-0.987,0.160, 72, 93,147, -0.183,-0.983,-0.023, 72, 75, 93, -1.000,0.000,-0.000, 72, 75, 81, 0.000,-0.000,1.000, 114,147,150, -0.993,-0.100,-0.059, 144,162,186, 0.000,-1.000,0.000, 84,162,186, -0.000,-0.152,-0.988, 84,144,162, -0.600,0.800,0.000, 144,150,159, 0.000,0.101,0.995, 84,144,159, -0.125,-0.087,-0.988, 144,147,159, -0.707,0.000,-0.707, 144,147,150, -0.000,0.000,1.000, 93,114,147, 0.732,-0.587,-0.346, 72, 93,114, -0.995,-0.100,-0.002, 81, 93,189, 0.022,1.000,-0.014, 75, 81, 93, -0.000,1.000,0.000, 93,144,159, 0.582,-0.140,-0.801, 93,144,147, -0.930,0.000,0.367, 87, 93,189, -0.000,0.987,0.160, 84, 87, 93, -0.000,0.000,-1.000, 84, 93,144, -0.009,-0.238,-0.971, 81, 87, 93, -0.000,1.000,0.000, 114,144,150, -0.000,-1.000,-0.000, 114,144,147, -1.000,0.000,-0.000, 93,144,162, -0.995,-0.096,0.000, 84, 93,162, -0.005,-0.145,-0.989, 93,114,144, -0.995,-0.096,0.000, 72,114,144, -0.995,-0.101,-0.000, 72, 93,144, -0.995,-0.097,-0.002, 90,144,162, -0.995,-0.101,0.000, 90, 93,162, 0.834,0.000,-0.552, 90, 93,144, -0.930,0.000,0.367, 84, 90,162, 0.000,-0.152,-0.988, 84, 90, 93, 0.000,0.000,-1.000, 72, 90,144, -0.995,-0.101,-0.000, 72, 90, 93, -1.000,0.000,-0.000, }; struct _vol4 { int p0,p1,p2,p3,t[4]; double s[4]; }; _vol4 vol[62]= // vol.dat[vol.num] = { p0,p1,p2,p3,t[0],t[1],t[2],t[3],s[0],s[1],s[2],s[3], ... } { 72, 78, 96, 84, 0, 1, 2, 3, 1,1,1,1, 78, 84, 96, 6, 4, 5, 6, 0, 1,1,1,-1, 72, 84, 96, 6, 4, 7, 8, 1, -1,1,1,-1, 72, 78, 84,147, 9, 10, 11, 2, 1,1,1,-1, 6, 78, 96,186, 12, 13, 14, 5, 1,1,1,-1, 6, 78, 84,186, 15, 16, 14, 6, 1,1,-1,-1, 6, 72, 96,186, 17, 13, 18, 7, 1,-1,1,-1, 6, 72, 84,147, 10, 19, 20, 8, -1,1,1,-1, 78, 84,147,135, 21, 22, 23, 9, 1,1,1,-1, 72, 78,147,135, 22, 24, 25, 11, -1,1,1,-1, 78, 96,186,132, 26, 27, 28, 12, 1,1,1,-1, 78, 84,186,132, 29, 27, 30, 15, 1,-1,1,-1, 6, 84,186,147, 31, 32, 19, 16, 1,1,-1,-1, 72, 96,186, 0, 33, 34, 35, 17, 1,1,1,-1, 6, 72,186,147, 36, 32, 20, 18, 1,-1,-1,-1, 84,135,147,189, 37, 38, 39, 21, 1,1,1,-1, 78, 84,135, 81, 40, 41, 42, 23, 1,1,1,-1, 72,135,147,105, 43, 44, 45, 24, 1,1,1,-1, 72, 78,135, 81, 41, 46, 47, 25, -1,1,1,-1, 78, 96,132,120, 48, 49, 50, 28, 1,1,1,-1, 84,132,186,180, 51, 52, 53, 29, 1,1,1,-1, 84,147,186,150, 54, 55, 56, 31, 1,1,1,-1, 0, 96,186,114, 57, 58, 59, 33, 1,1,1,-1, 0, 72,186,147, 36, 60, 61, 34, -1,1,1,-1, 0, 72, 96,114, 62, 59, 63, 35, 1,-1,1,-1, 135,147,189, 75, 64, 65, 66, 37, 1,1,1,-1, 84,147,189,159, 67, 68, 69, 38, 1,1,1,-1, 84,135,189, 81, 70, 71, 40, 39, 1,1,-1,-1, 105,135,147, 75, 66, 72, 73, 43, -1,1,1,-1, 72,105,147, 75, 72, 74, 75, 44, -1,1,1,-1, 72,105,135, 81, 76, 46, 77, 45, 1,-1,1,-1, 78,120,132,126, 78, 79, 80, 49, 1,1,1,-1, 147,150,186, 0, 81, 60, 82, 54, 1,-1,1,-1, 84,150,186,144, 83, 84, 85, 55, 1,1,1,-1, 84,147,150,159, 86, 87, 69, 56, 1,1,-1,-1, 0,114,186,150, 88, 81, 89, 58, 1,-1,1,-1, 0, 72,147,114, 90, 91, 63, 61, 1,1,-1,-1, 75,147,189, 93, 92, 93, 94, 64, 1,1,1,-1, 75,135,189, 81, 70, 95, 96, 65, -1,1,1,-1, 147,159,189, 93, 97, 92, 98, 67, 1,-1,1,-1, 84,159,189, 93, 97, 99,100, 68, -1,1,1,-1, 81, 84,189, 87, 101,102,103, 71, 1,1,1,-1, 75,105,135, 81, 76, 96,104, 73, -1,-1,1,-1, 72, 75,147, 93, 94,105,106, 74, -1,1,1,-1, 72, 75,105, 81, 104, 77,107, 75, -1,-1,1,-1, 0,147,150,114, 108, 89, 91, 82, 1,-1,-1,-1, 84,144,186,162, 109,110,111, 84, 1,1,1,-1, 84,144,150,159, 112, 87,113, 85, 1,-1,1,-1, 147,150,159,144, 112,114,115, 86, -1,1,1,-1, 72,114,147, 93, 116,105,117, 90, 1,-1,1,-1, 75, 93,189, 81, 118, 95,119, 93, 1,-1,1,-1, 93,147,159,144, 114,120,121, 98, -1,1,1,-1, 84, 93,189, 87, 122,101,123, 99, 1,-1,1,-1, 84, 93,159,144, 120,113,124,100, -1,-1,1,-1, 81, 87,189, 93, 122,118,125,102, -1,-1,1,-1, 114,147,150,144, 115,126,127,108, -1,1,1,-1, 84,144,162, 93, 128,129,124,111, 1,1,-1,-1, 93,114,147,144, 127,121,130,116, -1,-1,1,-1, 72, 93,114,144, 130,131,132,117, -1,1,1,-1, 93,144,162, 90, 133,134,135,128, 1,1,1,-1, 84, 93,162, 90, 134,136,137,129, -1,1,1,-1, 72, 93,144, 90, 135,138,139,132, -1,1,1,-1, }; the p? are point indexes 0,3,6,9... from pnt the n is normal s is sign of normal (in case triangle is shared so normals point the same way) and t[4] are indexes of triangles 0,1,2,3,... from fac. And here a sample test: bool tetrahedrons::vols_intersect() // test if vol[] intersects each other { int i,j; for (i=0;i<vol.num;i++) for (j=i+1;j<vol.num;j++,dbg_cnt++) if (intersect_vol_vol(vol.dat[i],vol.dat[j])) { linc=0x800000FF; if (intersect_vol_vol(vol.dat[j],vol.dat[i])) linc=0x8000FFFF; lin_add_vol(vol.dat[i]); lin_add_vol(vol.dat[j]); return 1; } return 0; } where dbg_cnt is counter of intersection tests. For this mesh I got this results: tests | time ------+------------- 18910 | 190-215 [ms] I called the vols_intersect test 10 times to make the measurements long enough. Of coarse none of placed tetrahedrons in this dataset will intersect (leading to highest time). In the real process (too big to post) which lead to this mesh are the count like this: intersecting 5 non intersecting 1766 all tests 1771
How are tripled sequence in IBO working?
I'm analyzing an obfuscated OpenGL application. I want to generate a .obj file that describes the multi-polygon model which is displayed in the application. So I froze the app and dig out the values set in VBO and IBO. But the values set in IBO was far more mysterious than what I've expected. The value was 0, 0, 1, 2, 3, 4, 5, 6, 7, 7, 5, 8, 3, 3, 9, 9, 10, 11, 12, 12, 10, 13, 14, 14, 10, 15, 16, 16, 17, 17, 7, 8, 8, 18, 18, 19, 20, 21, 21, 22, 22, 23, 24, 25, 25, 26, 26, 27, 28, 29, 29, 30, 30, 31, 32, 32, 33, 33, 34, 35, 36, 37, 38, 38, 36, 39, 34, 34, 40, 40, 40, 41, 42, 43, 44, 44, 45, 45, 46, 47, 48, 49, 49, 50, 50, 51, 52, 52, 53, 53, 54, 55, 55, 56, 56, 57, 58, 58, 59, 59, 60, 61, 62, 62, 63, 63, 63, 64, 65, 66, 67, 64, 68, 68, 69, 69, 70, 71, 72, 73, 74, 75, 76, 76, 77, 77, 78, 79, 80, 81, 82, 82, 80, 83, 83, 84, 84, 85, 86, 87, 88, 88, 89, 89, 90, 91, 91, 92, 92, 92, 93, 94, 95, 96, 96, 97, 97, 97, 98, 99, 100, 101, 102, 102, 100, 103, 103, 104, 104, 105, 106, 107, 107, 108, 108, 108, 109, 110, 111, 112, 112, 100, 100, 101, 113, 114, 114, ... (length=10495) As you can see indices like 40, 63, 92 and 108 are tripled, so setting neither GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUADS, GL_QUAD_STRIP nor GL_POLYGON to glDrawElements won't work correctly. Are there some kind of advanced techniques to use triple sequenced indices in IBO? What does it mean? For what reason is it used for?
Repeated indices like that are indicative of aggressive optimization of triangle strips. A repeated index creates degenerate triangles: triangles with zero area. Since they have no visible area, they are not rendered. They exist so that you can jump from one triangle strip to the next without having to issue another draw command. So a double-index is often used to stitch two strips together. The two triangles it generates will not be rendered. However, because of the way strips work with the winding order, the facing for the triangles can work out incorrectly. That is, if you stitched two strips together with a double-index, the second strip would start out with the reverse winding order than it desires. That's where triple indices come in. The third index fixes the winding order for the triangles in the destination strip. The three extra triangles it generates will not be rendered. The more modern way to handle multiple strips in the same draw call is to use primitive restart indices. But the index list as it currently stands is adequate for use with GL_TRIANGLE_STRIP. You can read this strip list and process it into a series of separate triangles (as appropriate for GL_TRIANGLES) easily enough. Simply look at each sequence of 3 vertices, and output that to your triangle buffer, so long as it is not a degenerate triangle. And you'll have to reverse the order of two of the indices for every odd-numbered triangle. The code would look something like this: const int num_faces = indices.size() - 2; faces.reserve(num_faces); for(auto i = 0; i < num_faces; ++i) { Face f(indices[i], indices[i + 1], indices[i + 2]); //Don't add any degenerate faces. if(!(f[0] == f[1] || f[0] == f[2] || f[1] == f[2])) { if(i % 2 == 1) //Every odd-numbered face. std::swap(f[1], f[2]); faces.push_back(f); } }
C++ Reading a string from socket that contains null character before the end
I have a socket server (written in c++) that receives tcp messages, these messages are data that have been deflated. Due to the deflation(compression) method these messages may contain "null" (0) character. An example repersentation of the data (with chars converted to int and seperated by comma): 141, 208, 59, 10, 128, 80, 12, 68, 209, 222, 197, 72, 94, 94, 190, 100, 55, 246, 86, 238, 31, 212, 82, 81, 50, 76, 49, 205, 169, 238, 182, 31, 75, 114, 13, 73, 37, 158, 162, 90, 170, 171, 120, 90, 197, 117, 164, 81, 116, 239, 97, 162, 55, 54, 0, 35, 128, 241, 222, 56, 1, 102, 2, 198, 0, 147, 189, 9, 6, 12, 208, 57, 128, 206, 249, 238, 236, 31, 70, 0, 227, 173, 81, 34, 192, 76, 192, 24, 96, 178, 55, 131, 127, 204, 9, 0 As you can see in the above example "null" (0) is represented before the actual end. So when using: message_size = read( client, buffer, 4096 ) The read is returned at the first "null" (0). Is it possible to continue reading so that i receive the whole message? Or is there some kind of magic trick to be done here? EDIT: Using Linux Centos (2.6.32-642.6.2.el6.x86_64)
Given that the read() function doesn't care about NUL characters, it seems likely to me that you're passing the buffer into one of the original C standard string functions, which use NUL terminated strings. The C++ std::string does not have this limitation.
Is it possible to continue reading so that i receive the whole message? Yes. Use Unformatted Input functions. An Unformatted Input function will not stop at the termination character. Edit: It appears that you are using the POSIX read function rather than a C++ API. As it happens, POSIX read doesn't stop on the terminator either.
AS mentioned by #Alnitak i was using a C family of string functions, this is what caused the odd behaviour. I used strncat(). I have now resolved the issue by looping through my buffer received by read, and then appending it to a std::string with push_back().
copy list items in python
Having a list as pbRecvBuffer=[112, 1, 0, 32, 225, 1, 0, 15, 55, 56, 52, 49, 57, 54, 57, 57, 56, 51, 55, 57, 56, 53, 49, 225, 2, 0, 9, 48, 54, 55, 51, 54, 50, 48, 54, 52, 0, 0, 0, 144, 0] in hexadecimal. how can we copy the above items from index 8 to 0xf in to another list. My work on the above question. iDataTagLength = ( pbRecvBuffer[index + 2] << 8 ) | pbRecvBuffer[index + 3] where index = 4 and the resulting "iDataTagLength" i get is 0xf which is 15 in decimal. PublicData['IDNumber']= pbRecvBuffer[(index + 4 ): iDataTagLength] copying the above to public data results till "pbRecvBuffer[0Xf]" rather than copying 0XF items. any help is appreciated and thankful in advance
You need to iterate over the items to copy them to your desired variable. What you're getting here is a list reference. Printing the class will be helpful in future: print (pbRecvBuffer[(index + 4 ): iDataTagLength]).__class__ This results in <type 'list'> as output. Try iterating over the content of the list by using (pbRecvBuffer[(index + 4 ): iDataTagLength][x] where x is the index and populate the desired variable.
What does cast do exactly?
I was playing with integer array hashing and the different ways to go from a representation to the other. I ended up with the following: void main(string[] args) { import std.algorithm, std.array, std.conv, std.stdio, std.digest.md; union hashU { ubyte[] hashA; int[] hashN; }; hashU a; auto md5 = new MD5Digest(); a.hashN = [1, 2, 3, 4, 5]; /* Using an union, no actual data conversion */ md5.put( a.hashA ); auto hash = md5.finish(); writeln(hash); // [253, 255, 63, 4, 193, 99, 182, 232, 28, 231, 57, 107, 18, 254, 75, 175] /* Using a cast... Doesn't match any of the other representations */ md5.put( cast(ubyte[])(a.hashN) ); hash = md5.finish(); writeln(hash); // [254, 5, 74, 210, 231, 185, 139, 238, 103, 63, 159, 242, 45, 80, 240, 12] /* Using .to! to convert from array to array */ md5.put( a.hashN.to!(ubyte[]) ); hash = md5.finish(); writeln(hash); // [124, 253, 208, 120, 137, 179, 41, 93, 106, 85, 9, 20, 171, 53, 224, 104] /* This matches the previous transformation */ md5.put( a.hashN.map!(x => x.to!ubyte).array ); hash = md5.finish(); writeln(hash); // [124, 253, 208, 120, 137, 179, 41, 93, 106, 85, 9, 20, 171, 53, 224, 104] } My question is the following: what does the cast do? I'd have expected it to do either the same as .to! or the union trick, but it doesn't seem so.
I think Colin Grogan has it right, but his wording is a little confusing. Using the union, the array is simply reinterpreted, no calculation/computation happens at all. The pointer and length of the int[] are reinterpreted to refer to ubyte elements. Before: 5 ints, after: 5 ubytes. The cast is a little smarter than that: It adjusts the length of the array so that it refers to the same memory as before. Before: 5 ints, after: 20 ubytes (5*int.sizeof/ubyte.sizeof = 5*4/1 = 20). Both the union and the cast reinterpret the bytes of the ints as ubytes. That is, an int value 1 will result in 4 ubytes: 0,0,0,1, or 1,0,0,0 depending on endianess. The to variants convert every single element to the new element type. Before: 5 ints, after: 5 ubytes with the same values as the ints. If one of the ints couldn't be converted to a ubyte, to would throw an exception. Printing the elements after the various conversions might help clarifying what happens where: void main() { import std.algorithm, std.array, std.conv, std.stdio; union hashU { ubyte[] hashA; int[] hashN; } hashU a; a.hashN = [1, 2, 3, 4, 5]; writeln( a.hashA ); /* union -> [1, 0, 0, 0, 2] (depends on endianess) */ writeln( cast(ubyte[])(a.hashN) ); /* cast -> [1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 4, 0, 0, 0, 5, 0, 0, 0] (depends on endianess) */ writeln( a.hashN.to!(ubyte[]) ); /* `to` -> [1, 2, 3, 4, 5] */ }
As far as I know, cast simply tells the compiler to start talking to the chunk of memory that you've cast as the type you've cast it to. The last two options in your example actually convert the numbers to the new type, and so do some actual work. Which is why they end up being the same values. The issue in your first two examples is that the int[] is larger in memory than the ubyte[]. (4 bytes per element vs 1 byte per element) I've edited your first two methods: /* Using an union, no actual data conversion */ md5.put( a.hashA ); auto hash = md5.finish(); writefln("Hash of: %s -> %s", a.hashA, hash); // Hash of: [1, 0, 0, 0, 2] -> [253, 255, 63, 4, 193, 99, 182, 232, 28, 231, 57, 107, 18, 254, 75, 175] // notice 5 bytes in first array /* Using a cast... Doesn't match any of the other representations */ md5.put( cast(ubyte[])(a.hashN) ); hash = md5.finish(); writefln("Hash of: %s -> %s", cast(ubyte[])(a.hashN), hash); // Hash of: [1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 4, 0, 0, 0, 5, 0, 0, 0] -> [254, 5, 74, 210, 231, 185, 139, 238, 103, 63, 159, 242, 45, 80, 240, 12] // notice 20 bytes (4 x 5 bytes) in first array So in the first, you're reading the length of ubyte[]'s bytes. In the second your casting the length of int[]'s length to ubyte[]. Edit: Prob wasn't clear. A union is pretty dumb, it simply stores all the values in the same memory. When you go to read any of them out, it will only read X bits of that memory, depending on the length of the type you're reading. So because you're reading the int[] THEN casting it, it reads all 20 of the bytes and casts them to a ubyte[]. Which is of course different than just reading the 5 bytes of the ubyte[] variable. I think I made sense there :)
cast is a D operator used when developer needs to perform an explicit type conversion.