
Advertisement
lucadeltodesco
Member
Content Count
468 
Joined

Last visited
Community Reputation
638 GoodAbout lucadeltodesco

Rank
Member
Personal Information
 Website
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.

Confused on Big Oh
lucadeltodesco replied to Nicholas Kong's topic in General and Gameplay Programming
I think the best example of that is triangulation: Triangulating a polygon 'can' be done in O(n) time, but the algorithm to do this is so incredibly complex that unless you have a polygon with 100000000000000 (*number pulled out of my arse) vertices, an O(n.log(n)) or O(n^2) algorithm is going to do it faster. 
the right way to represent inverse inertia tensor
lucadeltodesco replied to Irlan Robson's topic in Math and Physics
inverse_inertia = inertia.inverse(); Anyways, if it aids: By choosing the correct coordinate system for the object (For basic objects, the obvious one), you can always diagonalise the inertia tensor, and so it, and its inverse can be stored in a vector instead of a matrix, and then the inverse is just the component wise inverse: (Ix, Iy, Iz)^1 = (1/Ix, 1/Iy, 1/Iz) 
It is not that there is less trig involved when using xy vectors, but that there is NO trig involved. I already showed you earlier how to do bouncing.

What reason do you have to say that using x/y vectors would not permit you to have anything but rightangle ramps? Using angle/magnitude for vectors is almost NEVER the good way of doing things, it quite simply makes everything more complicated.

That you say you have done bouncing, but cannot figure out this, plus that you talk about the 'angle' of the slope tells me you are using trigonometry to do the bouncing... *sigh* :) The solution is incredibly simple, using simple vector operations. You have the slope normal vector (As opposed to its angle) You have the incident velocity. The outgoing velocity is then: newVelocity = velocity  normal*(1+e)*dot(velocity, normal) where e is the coefficient of restitution. For a perfectly elastic bounce e = 1, for a perfectly inelastic bounce (your 'slide') e = 0. If you're struggling to compute the normal vector. Assuming you have two positions for the slope 'a' and 'b' that you're using to compute your angle like atan2(b.ya.y, b.xa.x), then the normal for this slope is instead: unit(a.yb.y, b.xa.x). The normal is a unitlength vector that points 'out' (or 'in' for these purposes, makes no difference to the result) of the surface, so the left side of a box will have normal (1, 0) etc.

How do I create a vector tangent to each point in a nonfunction defined surface/model?
lucadeltodesco replied to JoryRFerrell's topic in Math and Physics
sounds like an XY situation: http://www.perlmonks.org/index.pl?node_id=542341 Why don't you describe what your actually trying to do? You want to write a shader, a shader to do what? You mention lighting, you mean that you want to write a shader to emulate how opengl would do its lighting? You're talking about 'vector tangent to a point', do you mean the surface normal? You need to specify those for opengl lighting in the first place, so lighting is not really the question here, it seems to me you have a mesh, and you want to find the normals for each vertex of the mesh's triangles. 
OK, theres something wrong with my math here. (Rotation of x/y axis)
lucadeltodesco replied to MylesEvans's topic in Math and Physics
When you say: x' = x*cos(A)  y*sin(A) y' = y*cos(A) + x*sin(A) Does your code happen to 'actually' do: x = x*cos(A)  y*sin(A) y = y*cos(A) + x*sin(a) aka, you update the value for x, then you are using the new value for x in the computation for y isntead of the old one? 
I need to remove these interior lines.
lucadeltodesco replied to Ghost Clock's topic in Math and Physics
Well in that case (Having a triangulation) then you can just use paradigm's solution of removing all lines that are shared between 2 triangles. My solution is for the general case of having a set of points and lines that are connected (Or can be used on disconnected components also with some extension). 
It seems to simply mean that, given the triangle of a model which is specular, it casts a caustic; the caustic it casts when projected onto the plane is also a triangle (the caustic triangle) and the volume that the original specular triangle, and the projected caustic make is the caustic volume.

Well if you think about what is actually happening: In the first case, it is in the worst scenario doing a loop that has nothing to do; the local int is going to have been assigned to a register and at worst a space on the stack. In either case setting it to 0 is like nothing at all. Most likely your compiler is not even bothering to set it since it's unused, and may even be removing the loop altogether as it's not doing any work. In the second case, each time you call 'new int' it's calling the operating system to ask it for space and performing lots of computations to choose the best place to allocate the int, with perhaps further logic to maintain the heap, same with delete in reverse.

I need to remove these interior lines.
lucadeltodesco replied to Ghost Clock's topic in Math and Physics
Further examples shown with results in red (additional number being number of times in total that vertex appears in output) http://www.zimagez.com/zimage/screenshot031212021000.php 
I need to remove these interior lines.
lucadeltodesco replied to Ghost Clock's topic in Math and Physics
For fun, I implemented my solution in Haxe and checked it worked with a somewhat degenerate case as well of having a dangling vertex connected outside the main exterior set http://pastebin.com/uyu2ZehA 
I need to remove these interior lines.
lucadeltodesco replied to Ghost Clock's topic in Math and Physics
Your step doesn't really need a triangulation. Eitherway given purely a set of lines you need to determine what the triangles are in the first place; and that same step can be used to simply determine the subpolygons which would then lead to the same rule of an internal line has more than one subpolygon using it and the triangulation step is pointless. Eitherway, I don't see how you could determine those internal subpolygons any faster than just traversing the exterior directly. 
I need to remove these interior lines.
lucadeltodesco replied to Ghost Clock's topic in Math and Physics
Paradigm shifter, that only works if the lines always form triangles.. eg: http://www.zimagez.com/zimage/screenshot021212225045.php here, your solution would choose to remove the crossedout red line. My algorithm would give us the green polygon. 
I need to remove these interior lines.
lucadeltodesco replied to Ghost Clock's topic in Math and Physics
One way to identify the exterior shell of your set of points (so we're assuming there are not any 'holes' that should be considered exterior to the volume). a) Identify a point on the exterior of the line set. b) Walk around the exterior of the line set till you get back to start. This identifies all the lines required to define the exterior; and then ones that you can remove are all those not belonging to the exterior. For a) you can choose the lexicographically minimal point (a, b) < (c, d) iff a < c  (a == c &amp;&amp; b < d) For b) you need to be able to; from any given point of the exterior identify the next point of the exterior. This comes in two cases; the initial case where you have 2 exterior lines to choose and you have to pick one of them (for this, abuse that your start point is lexicographically minimal), and in the other case you can make use of the point of the exterior you have just came from to order the outgoing edges. Presume that we choose, as a result of the first case of b) the point that is clockwise around the exterior (We'll come back to this after). If you label the previous point 'p' and the current point 'c'; then you can order the outgoing edges based on their relative rotation from the vector (c  p) http://www.zimagez.com/zimage/screenshot021212223758.php here, we want to pick vertex v0. We can do this by computing the perpdot products of (v  c) with (c  p) normalised by the length of (v  c); and choosing the minimal (or maximal depending on coordinate system); since the perpdot of two vectors u,v is uvsin(theta). We can also avoid any division if sorting of the outgoing edges uses a comparison function instead of a key. Back to the first case of b); choosing the second vertex of exterior we can use the same technique, and use the vector (1, 0) instead of (c  p) above. This is valid given that our first vertex was lexicographically minimal since the clockwise direction of the next vertex can in the worst case be in the direction (1, 0) and there cannot exist any vertex of the set that would give us a 'negative' perpdot since that point would need to have a lower ycoordinate and would have been chosen as the lexicographically minimal one. ^^ this is very similar to gift wrapping algorithm for computing a convex hull and is exactly equivalent if we join every vertex to every other one using this algorithm.

Advertisement