world_->Step(dt, velocityIterations, positionIterations);
In update method, i do not know the functionality of the above code.
Can any one explain me?
Once you’ve added the bodies to your world, usually we use "Box2D can do its magic on simulation – as long as you call its “Step” function periodically so it has processing time. in your "update" method:
int velocityIterations = 8;
int positionIterations = 1;
Instruct the world to perform a single step of simulation. It is generally best to keep the time step and iterations fixed.
world->Step(dt, velocityIterations, positionIterations);
Once you have a world created as above, you can add bodies into it as we've been doing. To make anything interesting happen, we need to repeatedly call the Step function of the world to run the physics simulation.
check this one too. http://www.cocos2d-x.org/wiki/Box2D , http://www.iforce2d.net/b2dtut/worlds
Related
I am facing the following issue: In our project, we have a main class with a main method called "run". This method calls hundreds of other functions, classes etc.
We are now calling this run method in a test in a for loop multiple times, something like that:
for(float test_time = 0; test_time < 10.0; test_time += 0.005){
outputStruct = mainClass.run(inputStruct);
}
I now want to save all local variables of all functions and methods and all member variables of all included objects that are seen when this for loop is executed. And I want to have a snapshot of this for each loop iteration. So in this example, there should be like 2000 snapshots of all my variables.
Is this somehow possible? I see that GDB has some "trace" functionality, but it's not clear for me how I can tell GDB that it should save everything that was "seen" while executing the mainClass.run method. It should "only" remember the last state of each member and local variable. And when test_time increments, it can finalize the current snapshot and create a new one for the next time slot.
Is something like this possible? Since our usecase is some physics based scenario, it is every interesting to see how certain values change over time in a plot later. I don't mind what the format of the output file of GDB is, it will be parsed later anyway, as long as the information is somehow inside. Of course, the cleaner the file looks the better :).
Thank you for your support guys!
I am creating the demonstration of the algorithm. The issue I am facing is how to animate the algorithm step by step, so on timeout or on click the algorithm does one step and presents it on screen. I want the algorithm below to go one step (as indicated at the lines) at the time, so everytime the function is called it does just one step of the algorithm. The closest to the idea would be like debugging the algorithm - on every call it would go to the next "breakpoint" (step one, two, three in the code)
void MainWindow::animationStep()
{
// this as a whole goes all in one step - for now
QVector<QVector3D> mp = myView->points;
QVector2D p0(mp.back()); // in step one - highlight this point
mp.pop_back();
mp.pop_back();
while(!mp.empty()){
QVector2D pTemp(mp.back()); // in step two - highlight this point
mp.pop_back();
// in step three - draw this line
QGraphicsLineItem *line = myView->scene->addLine(p0.x(), p0.y(), pTemp.x(), pTemp.y(), QPen(Qt::blue, 3));
line->setZValue(-1);
// next step - continue
}
}
I have an idea to put every part in different function and execute them based on the global counter, but that seems to be unnecessarily complicated. Is there some easy way to do that?
I see two ways to accomplish an animated display of running your code.
The first option is to split the code up so that it is operated in steps on call backs. This will be pretty ugly. You may be able to use some sort of co-routine package to make it appear less ugly.
The second option is to no actually run the algorithm and display together. In this situation, when running the algorithm, you would record all the steps in a time based data structure, then have separate code that plays back that data structure to the display. The downside to this is that now the display code has no way to effect the algorithm as it runs.
I’m using Cocos2d v3 and want to change a body from dynamic to static after colliding with another body. At the moment I’ve got:
-(void)ccPhysicsCollisionPostSolve:(CCPhysicsCollisionPair *)pair static:(CCNode *)nodeA wildcard:(CCNode *)nodeB
{
_player.physicsBody.type = CCPhysicsBodyTypeStatic;
}
or
-(BOOL)ccPhysicsCollisionPreSolve:(CCPhysicsCollisionPair *)pair static:(CCNode *)nodeA wildcard:(CCNode *)nodeB
{
_player.physicsBody.type = CCPhysicsBodyTypeStatic;
return YES;
}
but neither works. I get the error:
Aborting due to Chipmunk error: This operation cannot be done safely during a call to cpSpaceStep() or during a query. Put these calls into a post-step callback.
Failed condition: !space->locked
I then tried to make a joint at the point of collision but it doesn’t work right.
Is there a way to change a body to dynamic as soon as it collides in v3? I can do it in later versions using Box2D. I want to stop gravity and other forces so it doesn’t move. I want to make it look like it stuck to a surface.
Read a little on post-step callbacks but i'm unfamiliar with how to use them.
Any help would be appreciated.
As the error message states, you need to implement a post-step callback.
To do this on Cocos2d 3.0 and with Objective Chipmunk you first need to import a new header file to access advanced chipmunk properties:
#import "CCPhysics+ObjectiveChipmunk.h"
Then add the callback in your collision handler:
-(void)ccPhysicsCollisionPostSolve:(CCPhysicsCollisionPair *)pair static:(CCNode *)nodeA wildcard:(CCNode *)nodeB
{
[[_physicsNode space] addPostStepBlock:^{
_player.physicsBody.type = CCPhysicsBodyTypeStatic;
} key:_player];
}
Note that I assume you have access to your CCPhysicsNode in _physicsNode.
The Chipmunk Space of CCPhysicsNodeis locked while the a physics step is calculated. During a calculation of a step collisions are resolved and objects are moved around - changing the body type during this calculation could result in unexpected behaviour.
Therefore you add the postStepBlockcallback. This is a place where a body type can be safely changed.
The key value you pass into the callback is used to ensure that the code is only called once (especially useful when removing objects, but it also makes sense in this case).
If also added an example implementation: https://www.makegameswith.us/gamernews/367/make-a-dynamic-body-static-in-cocos2d-30-with-chi
I am not sure how you are supposed to control a player character in Bullet. The methods that I read were to use the provided btKinematicCharacterController. I also saw methods that use btDynamicCharacterController from the demos. However, in the manual it is stated that kinematic controller has several outstanding issues. Is this still the preferred path? If so, are there any tutorials or documentations for this? All I found are snippets of code from the demo, and the usage of controllers with Ogre, which I do not use.
If this is not the path that should be tread, then someone point me to the correct solution. I am new to bullet and would like a straightforward, easy solution. What I currently have is hacked together bits of a btKinematicCharacterController.
This is the code I used to set up the controller:
playerShape = new btCapsuleShape(0.25, 1);
ghostObject= new btPairCachingGhostObject();
ghostObject->setWorldTransform(btTransform(btQuaternion(0,0,0,1),btVector3(0,20,0)));
physics.getWorld()->getPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
ghostObject->setCollisionShape(playerShape);
ghostObject->setCollisionFlags(btCollisionObject::CF_CHARACTER_OBJECT);
controller = new btKinematicCharacterController(ghostObject,playerShape,0.5);
physics.getWorld()->addCollisionObject(ghostObject,btBroadphaseProxy::CharacterFilter, btBroadphaseProxy::StaticFilter|btBroadphaseProxy::DefaultFilter);
physics.getWorld()->addAction(controller);
This is the code I use to access the controller's position:
trans = controller->getGhostObject()->getWorldTransform();
camPosition.z = trans.getOrigin().z();
camPosition.y = trans.getOrigin().y()+0.5;
camPosition.x = trans.getOrigin().x();
The way I control it is through setWalkDirection() and jump() (if canJump() is true).
The issue right now is that the character spazzes out a little, then drops through the static floor. Clearly this is not intended. Is this due to the lack of a rigid body? How does one integrate that?
Actually, now it just falls as it should, but then slowly sinks through the floor.
I have moved this line to be right after the dynamic world is created
physics.getWorld()->getPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
It is now this:
broadphase->getOverlappingPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
I am also using a .bullet file imported from blender, if that is relevant.
The issue was with the bullet file, which has since been fixed(the collision boxes weren't working). However, I still experience jitteryness, unable to step up occasionally, instant step down from to high a height, and other issues.
My answer to this question here tells you what worked well for me and apparently also for the person who asked.
Avoid ground collision with Bullet
The character controller implementations in bullet are very "basic" unfortunately.
To get good character controller, you'll need to invest this much.
for (int i = 0; i < Number_Of_queries; i++)
{
glBeginQueryARB(GL_SAMPLES_PASSED_ARB, queries[i]);
Box[i]
glEndQueryARB(GL_SAMPLES_PASSED_ARB);
}
I'm curious about the method suggested in GPU GEMS 1 for occlusion culling where a certain number of querys are performed. Using the method described you can't test individual boxes against each other so are you supposed to do the following?
Test Box A -> Render Box A
Test Box B -> Render Box B
Test Box C -> Render Box C
and so on...
I'm not sure if I understand you correctly, but isn't this one of the drawbacks of the naive implementation of first rendering all boxes (and not writing to depth buffer) and then using the query results to check every object? But your suggestion to use the query result of a single box immediately is an even more naive approach as this stalls the pipeline. If you read this chapter (assuming you refer to chapter 29) further, they present a simple technique to overcome the disadvantages of both naive approaches (that is, just render everything normally and use the query results of the previous frame).
I think (it would have been good to link the GPU gems article...) you are confused about somewhat asynchronous queries as described in extensions like this:
http://developer.download.nvidia.com/opengl/specs/GL_NV_conditional_render.txt
If I recall correctly there were other extensions to check for the availability of a result without blocking also.
As Christian Rau points out doing just "query, wait for result, do stuff based on result" might stall and might not be any gain because of that, depending on how much work is in "do stuff". In fact, doing the query, waiting for it to round trip just to save a single draw call is most likely not going to help at all.