I've been suffering from an issue regarding the implementation of orienting characters in a game I'm implementing using Ogre3D and Bullet physics.
What I have: A Direction Vector that the character is moving in, along with its current orientation.
What I need: To set the orientation of the character to face the way it is moving.
I have a snippet of code that sort of does what I want:
btTransform src = body->getCenterOfMassTransform();
btVector3 up = BtOgre::Convert::toBullet(Ogre::Vector3::UNIT_X);
btVector3 normDirection = mDirection.normalized();
btScalar angle = acos(up.dot(normDirection));
btVector3 axis = up.cross(normDirection);
src.setRotation(btQuaternion(axis, angle));
body->setCenterOfMassTransform(src);
Where 'body' is the rigidbody I'm trying to orient.
This snippet has a couple of problems however:
1) When changing direction, it tends to 'jitter' i.e. it rapidly faces one way, then the opposite for a second or so before correcting itself to the orientation it is supposed to be at.
2) Most times that the code is run I get an assertion error from Bullet's btQuaternion on
assert(d != btScalar(0.0));
Can anyone help?
Thanks!
I think you shouldn't use functions like 'acos' for such things, as it may cause some inconsistencies in border-cases as the 180 vs 0 rotation mentioned above. You can also get high numerical error for such data.
The second thing is that - in general - you should avoid setting explicit position and rotation in physics engines, but rather apply forces and torques to make your body moving as you want. Your current approach may work perfectly now, but when you add another object and force you character to occupy the same space, your simulation will explode. And at this stage it's very hard to fix it, so it's better to do it right from start :) .
I know that finding correct force/torque can be tricky but it's the best way to make your simulation consistent.
Related
Note: I have tried this answer: Gap between SKSpriteNodes in SpriteKit collision detection
I am getting gaps in between my SKSpriteNodes, after 5 minutes of letting my game run. Here is my code to make the node:
let tileNode = SKSpriteNode(imageNamed: "world1Tile\(tileNumber).png")
tileNode.position.x = x
tileNode.position.y = y
tileNode.size.width = 128
tileNode.size.height = 128
tileNode.zPosition = 10
tileNode.physicsBody = SKPhysicsBody(rectangleOf: tileNode.size)
tileNode.physicsBody!.isDynamic = false
tileNode.physicsBody!.restitution = 0
tileNode.physicsBody!.allowsRotation = false
tileNode.name = "Tile"
row.append(tileNode)
When I remove the physics body, it is running fine. Here is are some images to show you what I mean:
This image has a physics body, and was taken after immediately after running the app.
This image was taken 5 minutes after running the app.
Why is this happening? I assume it has something to do with the physics body, because my app looks exactly like the first picture, even an hour after running the app if there is no physics body. What physics body property should I change to stop this from happening? Any help would be appreciated.
I had a similar issue not too long ago, where gaps were appearing between nodes that were tiled (although I didn't use physics). Based on this answer, I found that if you want perfect alignment between nodes, it is best to ensure that the positions of nodes as well as the nodes' width and height are whole numbers.
I would suggest to round-off the x and y values of the position of tileNode and see if it will make any difference .
I'm guessing there is no gap. you probably have 'showPhysics' to true in your gameviewcontroller, and the line appears as a gap to me.
compare position with and without the pb to verify.
I had similar problem where gaps between sprites started appearing after around 5 minutes of scrolling with constant speed (game with infinite scroll). I did not use physics and I even had all positions, widths, heights rounded to integer value. I was scrolling the camera and adding new sprites one right after another and everything was working fine except after around 5 minutes of that infinite scrolling gaps begin to appear just as in your case. I spent some time in looking for a solution and it turned out that the problem was that when positions of my objects were becoming big that is in my case X position in the scene was around 150000 then those gaps started to appear and also I noticed that this problem occurred only on devices which had to scale the scene. I was using aspect fill with default scene size for iPhone 6 resolution and those gaps only appeared on iPhone 5 but on iPhone 6 I did not notice them. I was able to fix that issue by subtracting some constant value from X position of all objects (including camera position) from time to time so that everything on the scene relatively did not change position to the camera and look the same but actually absolute positions were changed to keep them low. I guess that larger position values like 150000 and scene scaling cause some floating point rounding issue in SpriteKit and that is why gaps are then becoming visible.
So based on my experience if you have similar gaps I recommend using integer values for all positions, widths, heights and additionally keep values of objects positions of all objects low.
For future reference in case someone is still searching for this, here are my experiences:
If tiles have PhysicsBodies, they are prone to making gaps. A solution for me was making a blank SKNode as a child of the tile, and assigning the PhysicsBody to that.
If possible, make sure bit masks are set in a way that tiles can't collide with each other.
As stated in a previous answer, make sure all measurements are integers and rounded in a way that doesn't leave a one unit gap between them.
A related problem is also SpriteKit's PhysicsBody drifting. There are some threads about this (e.g. https://forums.developer.apple.com/thread/27057 ), and it seems to be abug. In my case, the problem was a combination of PhysicsBodies causing random small gaps, and the drifting making some of them larger. The steps above removed the small gaps. Unfortunately the only workaround for the drifting problem in my case was to only generate PhysicsBodies for nodes that are within a certain distance from the player and destroying them after they are left behind.
For future reference for anyone who needs, I found an different answer specific to my problem. As JohnV said, I may need to round of values when setting the position, but when running the code, I found out that I also need to do that when running SKActions.
My game is based on two screens (A & B) side by side, but the device screen can only display one of them at a time.
A is for example at position (0, 0) and B is at (320, 0)
I tried two solutions to switch from A to B:
First, I place the whole scene into one node, the MainNode. To switch
from A to B, simply set MainNode position to (0, -320).
Other solution, more elegant IMHO (but not for LearnCoco2D who uses the Coco2D library), is to move the scene anchorPoint to (0, -1)
Now, if I want to go from A to B with an animation, these two solutions must be adapted:
By using a SKAction
[Main runAction:[SKAction moveToY:-320 duration:0.1]];
By animating anchorPoint in the update method
if(anchorY > -1) anchorY -= 0.1;
These two solutions works (despite a linear SKAction::timingMode does not render a linear translation properly), but I wonder which is the best in term of optimization, and elegance. Documentation is welcomed ;)
EDIT:
Apparently, my question is not clear (maybe due to my english level).
In few words, my question is: What exactly are the best practices for scrolling a scene?
I am surprised (0, -1) doesn't throw a huge exception. According to the docs you get a range from 0 to 1. This could cause issues in the future. See the docs here
Changing your position sounds like a more elegant way of handling it. however changing it to negative -320 in a span of 1/10th of a second is rather quick and could explain why it looks funny. Also if you aren't making sure you are only calling that once it will look really odd. I would make sure that it is only getting called once and maybe using a bool to toggle if it should be moved instead of checking a position.
If you are going back and forth a lot from one screen to another this might be an ok solution. However if you are looking to scale this to a much larger map where you are going to transition several times to new screens I would recommend a different approach all together. Like creating a new node off screen when you need it and transition a parent node then pop the old node off.
I hope that helps.
Edit
Now that the question is "what exactly are the best practices for scrolling a scene".
I would recommend what LearnCoco2D mentioned in the comment and what I eluded to in my original answer.
Add a sub node to your scene that will handle positioning (lets call it mapNode)
Add any sprites that represent the scene to the mapNode
Move just the MapNode position on update
In the past I have built my Scenes in a similar fashion and have handled the scene position based on the player position in the update loop. I was able to keep the player in the center of the screen as he walked around the map. Might be getting off subject, but that is what I found the best practice for handling scrolling a scene from my experience. The project I am working on can be viewed here
I hope that answers your question.
I'm new to this so pardon me if I'm not quite giving enough detail about something, but... I'm trying to make a sort of curving stream, like water coming out of a fountain, only with more distinct particles than a continuous stream. I admit, I have no idea where to start as the documentation on threejs.org seems incomplete. Basically I want to have particles shoot out of one point and curve down into another. I figure I can use CurvePath or some such thing, as (as far as I know) I can specify a curve with a ridiculous number of points (is there a way to do a curve perhaps by specifying start and end points, rotation, and distance from the center to the apex?) and then I assume there's a straightforwardish way to make something move along a Path.
If you have a limited amount of objects to want to move along a path, the way I would do it is
as you said, create a Curve (look at the Curve subclasses to find one that suits you)
use something like Tween.js or jQuery to execute an easing function from 0 to 1
pass the easing value to Curve.getPoint(distance) to get a position along the path
add some randomness on this point to make a stream effect
Or, using a kind-of-physical particle engine, like http://stemkoski.github.io/Three.js/Particle-Engine.html
I have tried many different techniques of applying a realistic looking gravity feature in my game but have had no luck so far. I plan on offering a 100 point bounty on this for someone who can show me or (share) some code that applies gravity to a CCSprite in Cocos2D.
What I have done so far has just been ugly or unrealistic and I have asked in many different places on what the best approach is but I just have not found any good looking gravity techniques yet.
Anyway, can anyone offer some tips/ideas or their approach only applying gravity to a CCSprite in Cocos2D without using a physics engine?
Thanks!
A effective approach without having to explicitly use any physics engine is to step the velocity and position of your sprite manually in your update loop. This is essentially Euler Integration.
// define your gravity value
#define GRAVITY -0.1
// define a velocity variable in the header of your Game class/CCSprite Subclass (neater)
float velocity_y;
-(void) update: (ccTime) dt
{
// Step the y-velocity by your acceleration value (gravity value in this case)
velocity_y += GRAVITY *dt; // drop the dt if you don't want to use it
// Step the position values and update the sprite position accordingly
sprite.position.y += velocity_y* dt; // same here
}
In the code snippet above, I defined a velocity_y variable to keep track of my sprite's current velocity along the y-direction. Remember to initialize this value to 0 in your init method.
Next comes the crux of Euler. At every time step:
Advance your velocity by your acceleration (which is your gravity) multiplied by dt to find your new velocity.
Advance your position by your newly computed velocity value multiplied by dt to find your new position.
You can experiment whether using delta-time or not (see LearnCocos2D's excellent comment on the cons of using it) works for your game. While multiplying by delta-time allows your object motion to more accurately take into account varying framerates, as LearnCocos2d pointed out, it might be wise to avoid using it in a real-time game where system interrupts (new mail, low battery, ads pop-out) can occur and subsequently cause the game simulation to jump forward in an attempt to make up.
So if you are dropping the dt, remember to tweak (scale down) your GRAVITY value accordingly to retain the right feel, since this value is no longer multiplied by the value of delta-time (which is ~ 1/60).
Aditional Tip: To apply an impulse to move the sprite (say via a swipe), you can affect the velocities directly by changing the values of velocity_x (if you have this) and velocity_y.
I have used this approach in my games, and it works very well. hope it helps.
This isn't trivial matter, you should try to see other posts. I'm sure other poeple already had this issue. Try to look at :
How to simulate a gravity for one sprite in cocos2d without a physics engine?
Cocos2D Gravity?
Or try our good friend google :
http://www.gamedev.net/page/resources/ -> got to Math and Physics and then A Verlet based approach for 2D game physics
http://www.rodedev.com/tutorials/gamephysics/
In any case here are some tips :
Step 1, calculate the effective direction vectors
Step 2, calculate velocity
Step 3, project this velocity onto the two effective directions.
Step 4, generate an equal and opposite force for the two direction and call this the “response force”.
I feel stupid asking this question, but I can not find a clear answer anywhere (or much of an answer at all) so I feel I must ask. Is there anyone out there who can explain clearly how the parallaxRatio of CCParallaxNode works?
I have checked the source of CCParallaxNode and it does not explain it at all. I have searched the internet and stackOverflow extensively. I have tried to do good old trial and error. I'm still confused.
[parallaxLayer addChild:backgroundEffect_subtleRed z:100 parallaxRatio:ccp(0.5, 0.5) positionOffset:backgroundEffect_subtleRed.position];
In this piece of code I am trying to add a particle emitter to a parallaxLayer and have it move somewhat like you would expect an object on a parallax layer to move. Unfortunately I do not see the particles at all. I have had this problem anytime I try to add anything to a parallaxNode when I want it to move. I have been using CCParallaxNode to create static UI layers, but have not been able to use them for what they were built to do.
In summary:
parallaxRatio takes a CGPoint. What do the floats in the CGPoint apply to? Are they ratios of x and y in relation to the window? Are they (parallaxLayerMovementInRelationTo, parentNode)? A working piece of example code would be very helpful.
Thank you.
To quote from a cocos2d book I own:
[paraNode addChild:para1 z:1 parallaxRatio:CGPointMake(0.5f, 0) positionOffset:topOffset];
[paraNode addChild:para2 z:2 parallaxRatio:CGPointMake(1, 0) positionOffset:topOffset];
[paraNode addChild:para3 z:4 parallaxRatio:CGPointMake(2, 0) positionOffset:midOffset];
[paraNode addChild:para4 z:3 parallaxRatio:CGPointMake(3, 0) positionOffset:downOffset];
"The CCParallaxNode is created like any other node, but its children are added using a special initializer. With it you specify the parallax ratio, which is a CGPoint used as a multiplier for any movement of the CCParallaxNode In this case, para1 would move at half the speed, para2 at the normal speed, para3 at double the speed of the CCParallaxNode, and so on"
So basically, its the ratio that the individual layers are moved in the relation to the movement of the whole CCParallaxNode.