• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

978 Good

About nmi

  • Rank
  1. Number of Posibilities

    Quote:Original post by alvaro I get 222. *** Source Snippet Removed *** EDIT: nmi's argument is correct, but 32+16+16+16+16+16 is 112, not 224. Hehe, you are right, I doubled it twice. :) I was a bit distracted today...
  2. Number of Posibilities

    Quote:Original post by Jethro_T I looked at your method but I'm failing to see how it works exactly. I derived something from it though that makes sense to me... perhaps you could explain to me why yours is the correct one (assuming it is)? If you consider the cases, where there are at least five 1s in the bitstring, then you have these choices: 11111yyyyy 011111yyyy x011111yyy xx011111yy xxx011111y xxxx011111 So either it starts with 11111 (first case), or it is prefixed by something not containing 11111 (other cases). The pattern of a lower line must not be included in the possible configurations created by all lines above, so that is why there is an additional 0. The free bits x and y can be used to form an arbitrary prefix/suffix. So in the first line we have five free bits, so 32 possible combinations. The other lines have four free bits, so 16 combinations each. No you also count the number of configurations created by 00000 instead of 11111. This number is the same, the bits are just inverted. And then there are 1111100000 and 0000011111, which are counted twice, so we subtract two. A more interesting task would be to find out that number of bitstrings if the total length were 20 instead of 10.
  3. Number of Posibilities

    Would you also like to share how you obtained that result ? From what I see we can calculate the number of possibilities like this: 11111yyyyy -> 32 011111yyyy -> 16 x011111yyy -> 16 xx011111yy -> 16 xxx011111y -> 16 xxxx011111 -> 16 gives 224 possibilities for five consecutive 1s invert and it gives another 224 possibilities for five consecutive 0s we counted those strings twice 1111100000 0000011111 so in the end there should be 2*224-2=446 possibilities
  4. Quote:Original post by Brodyaga p1i=pTri->m_vertexIndices[p1i]; p2i=pTri->m_vertexIndices[p2i]; p1j=pTrj->m_vertexIndices[p1j]; p2j=pTrj->m_vertexIndices[p2j]; P1i=((p1i+p2i)-abs((int)(p1i-p2i)))/2; P2i=((p1i+p2i)+abs((int)(p1i-p2i)))/2; P1j=((p1j+p2j)-abs((int)(p1j-p2j)))/2; P2j=((p1j+p2j)+abs((int)(p1j-p2j)))/2; if((P1i==P1j) && (P2i==P2j)){ //they are neighbours pTri->neigh[ki] = j+1; pTrj->neigh[kj] = i+1; } So p1i,p2i,p1j,p2j are the indices of the vertices from the two edges. Then you check if the edge is shared by calculating P1i,P2i,P1j,P2j and checking if those value are equal ?? Don't mind, but that looks a bit weird to me. If you have a triangle mesh where you cannot be sure that every location in space is represented by exactly one vertex and everything is properly indexed (for instance when the mesh was imported from an OBJ file), then you would need to compare the 3D-location of the vertices of each edge. If they are close enough together then you can conclude that the edges match and you found a neighbour relation between two triangles. In case you don't know that triangle order is correct (i.e. CCW for front-face/visible and CW for back-face/invisible), then you would also have to compare for both cases of edge orientation. If you have a triangle mesh that is properly indexed, then you can just compare indices directly, so the lines with the abs(..) should not be needed. Also your algorithm for finding neighbours has quadratic time requirement, which may be fast for meshes with less than 1000 triangles, but can become slow for meshes with 10k, 100k or more triangles. The search for neighbours can be accelerated by using some spatial hash data structure. For instance you could divide space into a grid of cells and sort all vertices into the correct grid cell together with an info to which triangle that vertex belongs. Then when searching for a neighbour triangle along a given edge, just consider the vertices from the correct grid cells (and their associated triangles).
  5. In the pictures you posted it looks like from each silhouette edge there are two triangles drawn having a common edge instead of a single quad. This is just because of the wrong vertex order, as explained above. The article I linked above is very good and self-explanatory. To draw the shadow volumes, stencils are not needed. Only if you want to show the shadows you need them. Extending the shadow volume by scaling with a factor of 100 is also fine, but extending to infinity is more robust. Besides this article there is another one: http://developer.nvidia.com/object/fast_shadow_volumes.html Here they explain how to use the algorithm for more practical purposes. But I would recommend fully working out the first article before you start with this one.
  6. Perhaps another approach can be to randomly place vertices on the sphere, then use some force based simulation let them move around until equilibrium is reached. Then perform Delaunay triangulation to get triangles. If the vertices are evenly distributed, then the triangles produced that way should be more or less similar I think.
  7. Your problem is here: Quote:Original post by Brodyaga glVertex3f(x1 + xl1, y1 + yl1, z1 + zl1); glVertex3f(x1, y1, z1); glVertex3f(x2 + xl2, y2 + yl2, z2 + zl2); glVertex3f(x2, y2, z2); Your vertices should be in the order ABCD, but you provide ABDC. So if you change the order it should work. BTW a very good reference for shadow volumes is the article from Everitt and Kilgard: http://developer.nvidia.com/object/robust_shadow_volumes.html
  8. Detecting hardware

    In OpenGL you can ask for the vendor of the card etc via glGetString(GL_VENDOR) and the result can be checked for nvidia or amd,ati.
  9. Just a thought, but what about a bisection method to find the intersection point. That should work well even for long lines. If the two endpoints of a line segment are on different sides of a line (for instance y=-x), the line segment must intersect the line somewhere. So just compute the point in the middle of the line segment (division by two is simple even for integer arithmetic) and check if it is inside. If so, repeat bisection with the line segment made up by that point and the endpoint that was outside, otherwise that point and the endpoint that was inside. Repeat this until converged. So for each condition you can find an intersection point. The intersection points found this way are the endpoints of the clipped line, unless one or both of the endpoints of the line segments were already inside the region. Also note that in your conditions y>0, y>+x and y>-x the y>0 implicitly holds because of y>+x and y>-x, so y>0 is not needed.
  10. Quote:Original post by diablos_blade Possibly the best solution would first test for intersection and if that fails, use projection? I do not want to sound picky, but consider the line as before, but slightly shifted out of the circle's plane. It will then not intersect the circle, but the closest points will remain the same as in the original example and not the center of the circle.
  11. Quote:Original post by diablos_blade Well, if I think about this the other way around, i.e., finding the point on the line closest to the circle, I think I can give you an answer because I can also safetly assume that this point is also the closest to the center of the circle. Really ? Take for instance a line in the plane of the circle passing through the center of the circle. The closest points of the circle to the line would be the intersection points, while your method would consider the center of the circle instead.
  12. Quote:Original post by AntiGuy For years I've been lumping the two together and it's become very clear that they're two very separate topics. Even so, I've yet to find a clear paper that really lays out the process in general. What about a book ? I found "Game Physics Engine Development" from Ian Millington very good to start with.
  13. So assuming you have an indexed mesh, which is recommended anyways, you can calculate neighbourship information (handy if you want to use geometry shaders). Just use the pair of the two vertex indices of an edge as key into a hash table and store as value the triangle that owns this edge. When you encounter a second triangle with that edge (look up in the hash table beforehand), you know the two triangles sharing this edge. This should be done once in a preprocessing step. If you delete the entry in the hash table when the second triangle was found, what remains when all triangles are done are the edges of the outer triangles.
  14. Search for "n body simulation" and read this paper from Barnes&Hut: http://www.nature.com/nature/journal/v324/n6096/abs/324446a0.html This should give you some ideas how to speed up calculation.
  15. Hodgman, how do you intend to allow dynamic addition/exchange of components, for instance when your unit/entity learned a new ability or when the EasyAI component is replaced by a DifficultAI component.
  • Advertisement