They all look like static.
Don't move by the force.
And can be set position by program.
Though moving static actor is allowed, it is a bad idea since engine must rebuild spacial partitioning structures used for collision detection. Kinematic bodies are not static, so they can be moved "for free".
Related
My question is about design and possible suggestions for the following scenario:
I am writing a 3d visualizer. For my renderable objects I would like to store the minimum data possible (so quaternions are naturally nice for rotation).
At some point I must extract a Matrix for rendering which requires computation and temporary storage on every frame update (even for objects that do not change spatially).
Given that many objects remain static and don't need to be rotated locally would it make sense to store the matrix instead and thereby avoid the computation for each object each frame? Is there any best practice approach to this perhaps from a game engine design point of view?
I am currently a bit torn between storing the two extremes of either position+quaternion or 4x3/4x4 matrix. Looking at openframeworks (not necessarily trying to achieve the same goal as me), they seem to do a hybrid where they store a quaternion AND a matrix (matrix always reflects the quaternion) so its always ready when needed but needs to be updated along with every change to the quaternion.
More compact storage require 3 scalars, so Euler Angels or Exponential Maps (Rodrigues) can be used. Quaternions is good compromise between conversion to matrix speed and compactness.
From design point of view , there is a good rule "make all design decisions as LATE as possible". In your case, just incapsulate (isolate) the rotation (transformation) representation, to be able in the future, to change the physical storage of data in different states (file, memory, rendering and more). Also it enables different platform optimization, keep data in GPU or CPU and more.
Been there.
First: keep in mind the omnipresent struggle of time against space (in computer science processing time against memory requirements)
You said that want to keep minimum information possible at first (space), and next talked about some temporary matrix reflecting the quartenions, which is more of a time worry.
If you accept a tip, I would go for the matrices. They are generally performance wise standard for 3D graphics and it's size becomes easily irrelevant next to the object data itself.
Just to have and idea: in most GPUs transforming an vector for the identity (no change) is actually faster then checking if it needs transformation and then doing nothing.
As for engines, I can't think of one that does not apply the transformations for every vertex every frame. Even if the objects keep in place, they position has to go through projection and view matrices.
(does this answer? Maybe I got you wrong)
I'm trying to use quadtrees for collision detection in a game I'm making, but I'm not sure how to handle objects that might be moving between different quads?
The only way I can think of it is by clearing out the whole tree each frame, and then adding everything back in there, but that seems like that can get cpu intensive and not very efficient. Do you check each object every frame to see if it has moved outside the boundry of it's current quad, and if so then remove it and readd it? That again seems like it can be pretty inefficient because you'd be performing collision checks on every moving object every frame.
Also, regarding quadtrees but unrelated to objects moving around in them, how do you handle multiple objects in the same quad? Most sites that I've read about them on say that you should only have one, maybe two, objects in a quad, and if you get more than that then push them down in the tree. What if you had a situation like this? You have three circles and they are all on the edges of the level below them so they can't go any further down, but there is three all in the same level, which people say you shouldn't have.
I don't think it's particularly inefficient to implement your suggestion: check to see if an object has moved outside its quadtree, and if so then remove and re-add it. Any object which moves from one frame to the next will need to have some collision detection performed on it, surely? And the quadtree operations are only performed if it moves quadtrees, and the CPU time spent there are probably overshadowed by the CPU time doing the more precise "Does object A touch object B?" computations. So I don't know that you can do better.
On your 2nd question: I don't know how other people implement quadtrees, but I allow objects to occupy more than one quadtree, precisely for the reason you've given in your diagram (when an object straddles a boundary). So an object has a "current list of quads" instead of a "current quad".
Removing/re-adding can be optimized by moving up the quad tree instead of removing the item from the tree completely and then re-adding, i.e. move to the "parent" quad, and then have the "parent" add it - if it doesn't fit in the "parent", go to the "grandparent", etc.
As for your second concern, you will need some flexibility - if all 3 are on an edge, then you can't lower them - but that should be (pardon the pun) an edge case.
I am looking to implement a 2D top-down collision system, and was hoping for some input as to the likely performance between a few different ideas. For reference I expect the number of moving collision objects to be in the dozens, and the static collision objects to be in the hundreds.
The first idea is border-line brute force (or maybe not so border-line). I would store two lists of collision objects in a collision system. One list would be dynamic objects, the other would include both dynamic and static objects (each dynamic would be in both lists). Each frame I would loop through the dynamic list and pass each object the larger list, so it could find anything it may run into. This will involve a lot of unnecessary calculations for any reasonably sized loaded area but I am using it as a sort of baseline because it would be very easy to implement.
The second idea is to have a single list of all collision objects, and a 2D array of either ints or floats representing the loaded area. Each element in the array would represent a physical location, and each object would have a size value. Each time an object moved, it would subtract its size value from its old location and add it to its new location. The objects would have to access elements in the array before they moved to make sure there was room in their new location, but that would be fairly simple to do. Besides the fact that I have a very public, very large array, I think it would perform fairly well. I could also implement with a boolean array, simply storing if a location is full or not, but I don't see any advantage to this over the numeric storage.
The third I idea I had was less well formed. A month or two ago I read about a two dimensional, rectangle based data structure (may have been a tree, i don't remember) that would be able to keep elements sorted by position. Then I would only have to pass the dynamic objects their small neighborhood of objects for update. I was wondering if anyone had any idea what this data structure might be, so I could look more into it, and if so, how the per-frame sorting of it would affect performance relative to the other methods.
Really I am just looking for ideas on how these would perform, and any pitfalls I am likely overlooking in any of these. I am not so much worried about the actual detection, as the most efficient way to make the objects talk to one another.
You're not talking about a lot of objects in this case. Honestly, you could probably brute force it and probably be fine for your application, even in mobile game development. With that in mind, I'd recommend you keep it simple but throw a bit of optimization on top for gravy. Spatial hashing with a reasonable cell size is the way I'd go here -- relatively reasonable memory use, decent speedup, and not that bad as far as complexity of implementation goes. More on that in a moment!
You haven't said what the representation of your objects is, but in any case you're likely going to end up with a typical "broad phase" and "narrow phase" (like a physics engine) -- the "broad phase" consisting of a false-positives "what could be intersecting?" query and the "narrow phase" brute forcing out the resulting potential intersections. Unless you're using things like binary space partitioning trees for polygonal shapes, you're not going to end up with a one-phase solution.
As mentioned above, for the broad phase I'd use spatial hashing. Basically, you establish a grid and mark down what's in touch with each grid. (It doesn't have to be perfect -- it could be what axis-aligned bounding boxes are in each grid, even.) Then, later you go through the relevant cells of the grid and check if everything in each relevant cell is actually intersecting with anything else in the cell.
Trick is, instead of having an array, either have a hash table for every cell grid. That way you're only taking up space for grids that actually have something in them. (This is not a substitution for badly sized grids -- you want your grid to be coarse enough to not have an object in a ridiculous amount of cells because that takes memory, but you want it to be fine enough to not have all objects in a few cells because that doesn't save much time.) Chances are by visual inspection, you'll be able to figure out what a good grid size is.
One additional step to spatial hashing... if you want to save memory, throw away the indices that you'd normally verify in a hash table. False positives only cost CPU time, and if you're hashing correctly, it's not going to turn out to be much, but it can save you a lot of memory.
So:
When you update objects, update which grids they're probably in. (Again, it's good enough to just use a bounding box -- e.g. a square or rectangle around the object.) Add the object to the hash table for each cell it's in. (E.g. If you're in cell 5,4, that hashes to the 17th entry of the hash table. Add it to that entry of the hash table and throw away the 5,4 data.) Then, to test collisions, go through the relevant cells in the hash table (e.g. the entire screen's worth of cells if that's what you're interested in) and see what objects inside of each cell collide with other objects inside of each cell.
Compared to the solutions above:
Note brute forcing, takes less time.
This has some commonality with the "2D array" method mentioned because, after all, we're imposing a "grid" (or 2D array) over the represented space, however we're doing it in a way less prone to accuracy errors (since it's only used for a broad-phase that is conservative). Additionally, the memory requirements are lessened by the zealous data reduction in hash tables.
kd, sphere, X, BSP, R, and other "TLA"-trees are almost always quite nontrivial to implement correctly and test and, even after all that effort, can end up being much slower that you'd expect. You don't need that sort of complexity for a few hundreds of objects normally.
Implementation note:
Each node in the spatial hash table will ultimately be a linked list. I recommend writing your own linked list with careful allocations. Each node need take up more than 8 bytes (if you're using C/C++) and should a pooled allocation scheme so you're almost never allocating or freeing memory. Relying on the built-in allocator will likely cripple performance.
First thing, I am but a noob, I am working my way through the 3dbuzz xna extreme 101 videos, and we are just now covering a system that uses static lists of each different type of object, when updating an object you only check against the list/s of things it is supposed to collide with.
So you only check enemy collisions against the player or the players bullets, not other enemys etc.
So there is a static list of each type of game object, then each gamenode has its own collision list(edit:a list of nodes) , that are only the types it can hit.
sorry if its not clear what i mean, i'm still finding my feet
I am simulating a NAO robot that has published physical properties for its links and joints (such as dimensions, link mass, center of mass, mass moment of inertia about that COM, etc).
The upper torso will be static, and I would like to get the lumped physical properties for the static upper torso. I have the math lined out (inertia tensors with rotation and parallel axis theorem), but I am wondering what the best method is to structure the data.
Currently, I am just defining everything as rules, a method I got from looking at data Import[]'d from struct's in a MAT file. I refer to attributes / properties with strings so that I don't have to worry about symbols being defined. Additionally, it makes it easier to generate the names for the different degrees of freedom.
Here is an example of how I am defining this:
http://pastebin.com/VNBwAVbX
I am also considering using some OOP package for Mathematica, but I am unsure of how to easily define it.
For this task, I had taken a look at Lichtblau's slides but could not figure out a simple way to apply it towards defining my data structure. I ended up using MathOO which got the job accomplished since efficiency was not too much of a concern and it was more or less of a one-time deal.
Hey guys! My physics engine is coming along quite nicely (thanks for asking!) and I'm ready to start working on some even more advanced junk. Case in point, I'm trying to set up my collision engine so that an arbitrary delegate can be notified when a collision occurs. Let me set up a scenario for you:
Say we have object A, object B, and object C in the physics simulation. I want to be able to inform a delegate about a collision between A and B, AND inform a potentially DIFFERENT delegate about a collision between A and C.
A little background information: I have a known interface for the delegate, I have the potential of storing state for my collision detector (but don't atm), and have the ability to store state in the objects themselves. Similarly, I use this delegate model to handle collision resolution, simply setting the physics engine as the delegate for all objects by default, allowing the user to change the delegate if desired.
Now, I already tried having each object store it's own collision delegate that would be informed when a collision occurred. This didn't work because when the objects had the same collision delegate, the same collision was handled twice. When I switched to only using the delegate of the first object (however that was decided), the order of simulation became an issue. I want to use a dictionary, but that introduces a significant amount of overhead. However, that seems like the direction I need to be heading.
So here's the question: fight to the death over a suitable solution. How would YOU solve this problem?
I must say that it's a bit odd that two objects can have different delegates (at a collision) and still it would be bad if two identical delegates fired at a collision. I seems like they should both fire all the time or only one of them should. Consistency is what bothers me here.
Explaining that would help some more.
Second, if you use the naive version of holding a delegate for each object and then conditioning activating its functionality ("if (!some boolean indicating this delegate was fired already) {do something}"), this could be solved with a very small overhead.
It works, but I don't like this kind of code.
My suggestion (a bit complex, so think about it before working on it) is to try to focus on a manager object which would go over all the delegates and invoke the two that where relevant to the collision.
For instance, A and B collide, and the manager is invoked with them as parameters. You now can cycle through all the delegates known to the system (assuming they are few) and fire the ones that match "delegate == a.del or delegate == b.del".
This comes at a greater overhead, but if we are talking about a small number of delegates, if will make very little difference. On the other side this will allow you to expend your collision detection engine in this area further more in the future (like the existence of more then one delegate per object).