I am using embree to perform collision detection between two meshes. This two meshes belong to different RTCScenes, and I would like to know if the order of the RTCCollision::geomID0 and RTCCollision::geomID1 is fixed; the geomID0 always refers to a geometry in the first scene and the RTCCollision::geomID1 always refers to a geometry in the second scene.
Related
I am writing a simple GUI library and am using quadtrees to determine which, if any, objects are interacted with during a mouse event. I was looking through a number of quadtree libraries on github and they all contained a method for adding a rectangular object to a quadtree.
The method, in all cases, simply checked to see if the rectangle intersected with the given quadtree:
return quadtree.x2 >= rect.x1
and quadtree.x1 <= rect.x2
and quadtree.y2 >= rect.y1
and quadtree.y1 <= rect.y2
However, this gives an unwanted result in one of the simplest cases: Imagine a 100x100 square area. I place four 50x50 square objects into the area with coordinates (0,0), (0,50), (50,0), and (50,50). If these objects had been placed into a 100x100 quadtree with a maximum capacity of one object, I would (visually) expect that the first layer of the quadtree would split and that the four resulting trees would each exactly contain one of the squares.
If I use the above method to determine which tree the squares are placed into, though, I find that each object intersects with all four trees. This would cause each of the trees to rapidly split until the maximum depth is reached.
The only way I see to avoid this is to use two checks:
return (quadtree.x2 > rect.x1
and quadtree.x1 < rect.x2
and quadtree.y2 > rect.y1
and quadtree.y1 < rect.y2)
or (quadtree.x2 == rect.x1
and quadtree.x1 == rect.x2
and quadtree.y2 == rect.y1
and quadtree.y1 == rect.y2)
(in the simplest case. Larger objects would have to be viewed within a bounding box since, for example, an object with coordinates (0,0), w=100, h=100 would belong in the upper-left quadtree as well.)
I could also calculate the overlap between the rectangles and the quadtrees to see if it's non-zero.
Am I missing something? It seems like this should be an ideal situation for a quadtree, yet, in most implementations, it's a huge mess.
I wouldn't call this an ideal situation, because the four rectangles overlap by a fractional amount. For example, if we assume a (fictional) floating precision of 10^(-10), every 'point' is actually a small rectangle with 10^(-10) length, and thus the rectangles overlap by 10^(-10). This is why you get the deep tree.
But I also think the tree could be improved with a slightly modified overlap checking. With your code, the sub-nodes all overlap by a tiny amount. It would work better with excluding the minimum (or maximum values), for example:
return quadtree.x2 >= rect.x1
and quadtree.x1 < rect.x2
and quadtree.y2 >= rect.y1
and quadtree.y1 < rect.y2
So the lower left coordinate of a node is actually outside of that node. This would at least avoid points turning up in several nodes (such as the point (50,50)), and the lower left rectangle would be stored in only one node.
So I am making a physics engine that only uses rectangles (axis-aligned bounding boxes) as shapes. I have implemented a method from christer ericsons book that returns the collision time and normal of two moving aabbs. I also have made another method that takes two aabbs velocities, positions and a normal that responds to the collision and give the aabbs new velocities.
The actual problem now is is that I don't know how the loop, that checks the collisions between all aabbs and responds to them, should look like. Simply I don't understand how to order the collisions by the time of impact, and which collision I should respond to.
A loop written in pseudo code that shows how to order all collisions would be really helpful.
Another thing I've mentioned is that it's possible thata moving box could bounce between two static boxes hundreds of times in a single frame if it's velocity is really high, how do you handle that?
You should let a simple priority queue take care of the right order of execution. Conceptually, this would end up looking something like this:
queue<CollisionEvent> q = new empty queue
while (!q.isEmpty) {
nextCollision = q.dequeueMinimum
/* run animation until nextCollision.time
...
*/
newMovingParticles = nextCollision.movingParticles
newCollisions = computeCollisionEvents(newMovingParticles, allOtherParticles);
for each event in newCollisions {
q.enqueue(event, event.time);
}
}
What about boxes that move with large velocities: I don't know. Physically, it would make sense to just accept that it can happen that there is a sequence of very frequent collision events. I can not explain why, but for some reason I do not expect any infinite loops or zeno-type-problems. I would rather expect that even frontal collisions of very heavy boxes with very light boxes, where the light box is trapped between the heavy box and the wall, end in finitely many steps. This is what makes the rigid bodies rigid, I think one should just accept this as a feature.
I am creating a fighting game. I've got a spritesheet for the hero and a spritesheet for a monster. Since both will be able to do multiple attacks I would like to avoid to merge them in a single spritesheet. And I am intending to create more characters.
Now I am creating a SpriteBatchNode for each spritesheet and add them to layer.
CCLayer* stage = CCLayer::create();
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile("character_hero.plist");
this->characterHeroBatchNode = CCSpriteBatchNode::create("character_hero.pvr.ccz");
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile("character_monster.plist");
this->characterMonsterBatchNode = CCSpriteBatchNode::create("character_monster.pvr.ccz");
stage->addChild(characterHeroBatchNode);
stage->addChild(characterMonsterBatchNode);
Now I have one sprite in characterHeroBatchNode and multiple in characterMonsterBatchNode.
How can I reorder the monsters and the heros z-Order based on their PositionY attribute.
For example>
monster1->setPositionY(10); // In monster batch node
hero->setPositionY(24); // In hero batch node
monster2->setPositionY(43); // In monster batch node
I want the monster 1 behind the hero. And the hero behind monster2.
In the past, I've had to create games where I wanted some sprites in the foreground and others in the background. The sprites were in different sheets, like you have them.
To get them in the order I wanted, I put the "front" sprites into one CCLayer and the "back" sprites into another CCLayer. I added the layers to the scene in the order I wanted them to appear. I also manipulated each the respective layers to make them fade in/out as needed. So you could have the hero in the scene and then have the enemies appear behind him.
If you want to mix and match, you can have 3 layers, one for the "middle ground", one for "front", and one for "back", and dynamically move the sprites between the layers.
Was this what you were looking for?
If I understand what you're asking, the answer is, you can't. Consider each CCSpriteBatchNode to be its own container. You can adjust the Z order of the sprites inside the CCSpriteBatchNode, but when you add the batch to the CCLayer the whole CCSpriteBatchNode is applied to the CCLayer in whatever Z order you added it at. So in order to do what you want you would need another batch of monsters. Or use CCSprites and add/adjust them on the CCLayer in the way you want, but then you obviously lose the CCSpriteBatchNode benefits.
Good evening (at the time of writing)
The research I've done on this topic has turned up numerous fruitful code blocks regarding various situations similar to mine, but not quite identical. If one exists which I have not uncovered, I would be grateful for a link!
I have a few pertinent criteria, all on a 2d plane, and the question is related to 2d projectile pathing:
1) Object A: position ax,ay
2) Object B: position bx, by
3) Object P: (projectile) origin position bx,by
Object P leaves object B's X/Y position at a static velocity, traveling toward object A's X/Y position.
Objects A and B continue to move along their paths, irrespective of object P's trajectory. Object P continues to move from ax,ay to bx,by and beyond. I think I just need the angle and velocity, and don't need to continue to track beyond that (just increment movement steps accordingly till off-stage, where the object is disposed).
I'm working in Actionscript 3, any help would be greatly appreciated. Thanks!
In most case in 2D x-y plane, it is usually easier to handle movement and momentum in planar(separate in x-axis and y-axis) fashion than polar(angle+distance) fashion. I couldn't get the exact behaviour of projectile you want, so I assume you want a simple, dumbfire-rocket style projectile (which keeps initial direction).
:: 1. Projectile initiation ("Firing" of projectile)
var duration:int //(duration of flight(until getting to (ax,ay) described in number of frames)
var spdX:Number //(x-axis part of speed, described in pixels per frame)
var spdY:Number //(y-axis part of speed, described in pixels per frame)
spdX=(bx-ax)/duration;
spdY=(by-ay)/duration;
:: 2. Projectile movement (listen to ENTER_FRAME Event, executed once per frame)
projectile.x+=spdX;
projectile.y+=spdY;
:: if you want to change velocity of projectile, simple multiplication will handle it.
public function adjustSpeed(ratio:Number):void
{
spdX*=ratio;
spdY*=ratio;
}
What is AABB? A king of preview-collision before the real collision detection (I mean, the accurate one)?
I displayed the debug shapes and set up b2DebugDraw.e_aabbBit flag in order to see it in action. I put a simple box falling, and when the box hit the ground, the AABB frame is completely different.
I think the other respondent already addressed what an AABB is. This response adds to their answer by explaining why the AABB you've drawn could be bigger and of different shape.
The AABB that's being displayed here looks like an AABB calculated for a square that's been dropped onto the green surface. That would at least explain why the AABB is bigger and why the AABB isn't the same shape.
Here's why...
While an AABB can serve as a minimally enclosing axis-aligned bounding box for any shape, Box2D also uses AABBs that encompass some movement and some additional wiggle room for future movement.
Take void b2Fixture::CreateProxies(b2BroadPhase* broadPhase, const b2Transform& xf) for example. Here Box2D calculates AABBs using the shape's ComputeAABB method which basically just calculates the minimal enclosure. This method is called for every "child" shape when first creating a new fixture (where any shape may be composed of 1 or more sub-shapes that are called "child" shapes).
OTOH, take a look at void b2Fixture::Synchronize(b2BroadPhase* broadPhase, const b2Transform& transform1, const b2Transform& transform2). This method is invoked from calling the world step method which calls it for all bodies that may have moved. When it calculates AABBs, it:
computes an AABB for where every child shape has been,
computes an AABB for where every child shape has gone to (in that step),
combines the two AABBs for every child shape into the "proxy" AABB (see void b2AABB::Combine(const b2AABB& aabb1, const b2AABB& aabb2)), and finally
calls broadPhase->MoveProxy(proxy->proxyId, proxy->aabb, displacement) which adds some predictive room to each AABB.
So as to why specifically the AABB drawn could be bigger and of different shape: step 3 often results in an AABB enlarged to hold most of the entire sweep of the child shape, and step 4 results in an AABB that's further extended on all sides by b2_aabbExtension and additionally extended in the direction of travel (by b2_aabbMultiplier * displacement).
Hope this helps!
Well, axis-aligned bounding box is a... simple box :) You didn't give me any fundamentals regarding your project though. Anyway, the bounding box is just a math box, that is able to describe any physical body in three dimensions.
Just try to wrap your body with many boxes and you'll find out that it's sufficient to cover all the physics. It is used in games heavily because of its simplicity. You may do the same things on sphere-models, but with more complicated shapes you get more complicated math, then you get more overload which is too much for current CPU (including gpu).
But totally, there is nothing to explaing, concerning you won't need some maths. It's a simple box that is used to compare collision with another AABB, including help of triangle "normals" and "matrix" transformations.