Aspects of .allowcameracontrol are perfect for my use. I'm currently rotating a camera node (child of a sphere) around a cube. I'd like to have the spinning gradually come to a halt (like allowscameracontrol).
Can anyone assist in direction of how to slowly stop spinning based on velocity of the gesture? Add friction to the camera?
I spent a lot of time working on this, and it's actually a tricky subject. The best approach I found is to:
Save the past 10 or so drag events every frame
On release, calculate a velocity for X and Y axis based on these frames
Keep moving the camera using these velocity values
Every frame, dampen the velocity. Looking at spring equations will help you make it more realistic
When the velocity is under a small threshold, stop moving to avoid endless drifting
Related
So I have my game, made with SpriteKit and Obj-C. I want to know a couple things.
1) What is the best way to make scroll-views in SpriteKit?
2) How do I get this special kind of scroll-view to work?
The kind of scroll-view I'd like to use is one that, without prior knowledge, seems like it could be pretty complicated. You're scrolling through the objects in it, and when they get close to the center of the screen, they get larger. When they're being scrolled away from the center of the screen, they get smaller and smaller until, when their limit is met, they stop minimizing. That limitation goes for getting bigger when getting closer to the center of the screen, too.
Also, I should probably note that I have tried a few different solutions for cheap remakes of scroll views, like merely adding the objects to a SKNode and moving the SKNode's position relative to the finger's, and its movement . . . but that is not what I want. Now, if there is no real way to add a scroll-view to my game, this is what I'm asking. Will I simply have to do some sort of formula? Make the images bigger when they get closer to a certain spot, and maybe run that formula each time -touchesMoved is called? If so, what sort of formula would that be? Some complicated Math equation subtracting the node's position from the center of the screen, and sizing it accordingly? Something like that? If that's the case, will you please give me some smart Math formula to do that, and give it to me in code (possibly a full-out function) format?
If ALL else fails, and there is no good way to do this, what would some other way be?
It is possible to use UIScrollViews with your SpriteKit scenes, but there's a bit of a workaround involved there. My recommendation is to take a look at this github project, that is what I based my UIScrollView off of in my own projects. From the looks of it, most of the stuff you'd want has actually been converted to Swift now, rather than Objective-C when I first looked at the project, so I don't know how that'll fare with you.
The project linked above would result in your SKScene being larger than the screen (I assume that is why it would need to be scrolled), so determining what is and is not close to the center of the scene won't be difficult. One thing you can do is use the update loop in SpriteKit to constantly update the size of Sprites (Perhaps just those on-screen) based on their distance from a fixed, known center point. For instance, if you have a screen of width and height 10, then the midpoint would be x,y = 5,5. You could then say that size = 1.0 - (2 * distance_from_midpoint). Given you are at the midpoint, the size will be 1.0 (1.0 - (2 * 0)), the farther away you get, the smaller your scale will be. This is a crude example that does not account for a max or min fixed size, and so you will need to work with it.
Good luck with your project.
Edit:
Alright, I'll go a bit out of my way here and help you out with the equation, although mine still isn't perfect.
Now, this doesn't really give you a minimum scale, but it will give you a maximum one (Basically at the midpoint). This equation here does have some flaws though. For one, you might use this to find the x and y scale of your objects based on their distance from a midpoint. However, you don't really want two different components to your scale. What if your Sprite is right next to the x midpoint, and the x_scale spits out 0.95? Well, that's almost full-sized. But if it is far away from the midpoint on the y axis, and it gives you a y scale of, say 0.20, then you have a problem.
To solve that, I just take the magnitude or hypotenuse of the vector between the current coordinate and the coordinate of the current sprite. That hypotenuse gives me an number that represents the true distance, which eliminates the problem with clashing scale values.
I've made an example of how to calculate this inside Google's Go-Playground, so you can run the code and see what different scales you get based on what coordinate you plug in. Also, the equation used in there is slightly modified, It's basically the same thing as above but without the maxscale - part of the front part of the equation.
Hope this helps out!
Embedding Attempt:
see this code in play.golang.org
How can I make a camera that I can move around and rotate around its own axis in processing 2+?
I have a camera that I can move around in the world space and have some kind of rotation:
frustum(-10,10,-10,10,10,2000);
translate(camX,camY,camZ);//I move around by adding to these values when a button is pressed
rotate(angleX,1,0,0);//same here...
rotate(angleY,0,1,0);
rotate(angleZ,0,0,1);
Bu the problem with this is that the rotation is centered in the scene, meaning that I get very strange rotations when moving further away from the scene's center coordinates. Why does that happen when I have translated before rotating?
Thanks to Nicolás Carlo and his suggestion to watch This Youtube playlist made by Jorge Rodriguez I was able to fix what I almost made right the first time.
All I had to do was really just to do some simple trigonometric calculations to get the forward-vector from the angles I got, and then just add the camera position to that for the centerX,centerY,centerZ values in camera();
Ex. where camPos is the current position 3D-Vector and vecForward is the calculated 3D-forward vector that I needed.
vecForward.x = cos(yaw)*cos(pitch);
vecForward.y = sin(pitch);
vecForward.z = sin(yaw)*cos(pitch);
camera(camPos.x,camPos.y,camPos.z, camPos.x+vecForward.x,camPos.y+vecForward.y,camPos.z+vecForward.z, 0,1,0);
If some of you do not know, Pitch is the up-down angle and Yaw is left-right angle of the camera.
And as a last note here,I highly suggest watching Rodriguez "Math for game developers" that Carlo suggested since every video explains at least one of the most important/oftenly used mathematical solutions at a time to different problems and then giving an example in the end.
Let's say I have a solid, irregularly shaped (but enclosed) shape on screen in iOS (one colour). I then want to "erase" portions of that shape by dragging my finger around like you would in a typical kids colouring app, erasing with a fixed brush size where I touch the screen.
I could easily accomplish all this with something like an image mask and touch detection however, as a requirement, I also need to determine the rough percentage of the shape that remains.
For example I need to know when 50% of the random enclosed shape has been "erased".
What's the best way of approaching this problem? Are there any existing iOS compatible libraries that can handle it? I'm thinking that I would need to keep track of a ton of polygons and calculate all the overlaps but it seems like there must be a solution to this problem.
EDIT: I have done research into this problem however tracking all the polygons manually and calculating all their positions and area overlaps seems overly complicated. I was simply wondering if anyone else has run into a similar issue and found a better solution.
you will need to first know the fixed space of the image view. then you will need to know the percentage of blank space when the new image is loaded. pixel
double percentageFilledIn = ((double)nonBlankPixelCount/totalpixels);
After you get that value you will need to use that percentage as your baseline for the existing percentage
your new calculation will look like this.
double percentageOfImageLeft = ((double)nonBlankPixelCount/totalpixels/percentageFilledIn);
this calculation will likely be processor intensive. I would only calculate sparingly.
Since this post is not about code and more about login I will let you determine your logic for detecting non blank pixels.
here is how to find a pixel color.
How to get Coordinates and PixelColor of TouchPoint in iOS/ObjectiveC
Good luck.
What is the best way to make sand particles animate in a view?
Essentially, I would like to half fill the iOS device's screen with small sand-like particles, then allow a user to rotate and shake the device to dictate the sand's position.
Assuming I have never done any physics programming before, can anyone recommend a tutorial or show me how it's done?
Thank you,
Query.
UPDATE:
I have now come across this (mine should be 2D though) - how can I bring something similar into my app?
Using spatial indexing for finding the nearest-particles to check for collision and using an integration technique for the transition between force(acceleration)-velocity-position and using only gravity force as an outer-fource would give you your sand-box.
You will need to select a good exclusion-force derived from a particle-potential if you use post-collision detection.
I advise you to use the Truncated Lennar-Jones potential and Verlet-Integrator. Easier than Runge-Kutta's and more precise than Euler's. Because it is used in molecular-dynamics. You dont need to use other forces . Just use exclusion force, gravity and wall forces.
If you have bullets in your simulator, you can use Euler-Integration for them. I think this is acceptable for free-falling but not colliding sand particles. After they close each-other, it would be good to use Verlet or Runge-Kutta.
All i mentioned above assumes your integration step is so big that energy is not conserved and even decreased. If your integration is good enough to conserve energy, you will need to give your particles friction force to make sands slow or you will get your particles exploding everwhere.
If you like to make it on iphone then you have to think of certain optimizations and tricks as iPhone can't really simulate water or sand.
Your trick is that most of your work is to draw scene.
Create scene in Box2D with balls at size 10-20 times bigger then sand particle.
iPhone would be able to simulate it.
Then you should draw 10-20 sand particle per ball.
Every frame you may check if ball collides with other balls or not.
If balls is not colliding then these sand particles are in the air and you should draw them on certain distance one from each other.
If ball collides with other balls then particles should be rendered together
You may also detect margin and render glider sand border on top.
I'm making a basic simulation of moving planets and gravitational pull between them, and displaying the gravity with a big field of green vectors pointing in the direction gravity is pulling them and magnitude of the strength of the pull.
This means I have 400 + lines, which are really rectangles with a rotation, being redrawn each frame, and this is killing my frame-rate. Is there anyway to optimize this with other than making less lines? How do 2d OpenGL games today achieve such high frame-rates even with many complex polygons/colors?
EDIT:
SFML does the actual rendering each frame, but the way I create my lines is by making a rectangle-like sf::Shape. The generation function takes a width, and sets point 1 as (0, width), point 2 as (0, -width), point 3 as (LineLength, -width), and point 4 (LineLength, width). This forms a rectangle which extends along the positive x-axis. Finally I rotate the rectangle around (0,0) to get it to the right orientation, and set the shapes position to be wherever the start of the line is supposed to be.
How do 2d OpenGL games today achieve such high frame-rates even with many complex polygons/colors?
I imagine by not drawing 400+ 4-vertex objects that are each rotated and scaled with a matrix.
If you want to draw a lot of these things, you're going to have to stop relying on SFML's drawing classes. That introduces a lot of overhead. You're going to have to do it the right way: by drawing lines.
If you insist on each line having a separate width, then you can't use GL_LINES. You must instead compute the four positions of the "line" and stick them in a buffer object. Then, you draw them with a single GL_QUADS call. You will need to use proper buffer object streaming techniques to make this work reasonably fast.
Large batches and VBOs. Also double-check how much time you're spending in your simulation update code.
Quick check: If you have a glBegin() anywhere near your main render loop you are probably Doing It Wrong.
Calculate all your vertex positions, then stream them into the GPU via GL_STREAM_DRAW. If you can tolerate some latency use two VBOs and double-buffer.