I'm trying to make the balls falling at a random speed but the speed is changing only when I reload the page/script, I would like to get a random speed dynamically, one ball comes at 5, the next one 1.4, next 2.6 and so on...
https://codepen.io/Le-future/pen/gKNoEE
I tried to use the following :
// set how fast the objects will fall
var spawnRateOfDescent = Math.random() * (5 - 0.5) + 0.5;
Each ball should have its own unique speed property. You can add it as follows:
First adjustment (lines 72-73):
image: images[Math.floor(Math.random()*images.length)], // add a comma here
speed: Math.random() * 10 + 3 // add this line and tweak the numbers to taste
Second adjustment in your animate function (line 107 [or 108 if you added a line]):
object.y += object.speed; // instead of: object.y += spawnRateOfDescent;
Related
Let’s say I want to make 100 objects - for example cars, like the one you see here:
This car is currently comprised of 5 meshes: one yellow Cube and four blue Spheres
What I’d like to know is what would be the most efficient/correct way to make 100 of these cars - or maybe 500 - in terms of memory management/ CPU performance, etc.
The way I’m currently going about doing this is as follows:
Make an empty THREE.Group called “newCarGroup” -
Create the yellow rectangular Mesh for the body of the car - called “carBodyMesh”
Create four blue Sphere Meshes for the Tires called “tire1Mesh”, “tire2Mesh”, “tire3Mesh”, and “tire4Mesh”
Add the Body and the four Tires to the “newCarGroup”
And finally, in a FOR loop, create/instantiate 100 “newCarGroup” objects, adding each one to the SCENE at a random position
The code is below.
It's working perfectly well right now, but I’d like to know if this is the “proper”/best way to do this?
Consider it’s possible I might end up needing 1,000 cars - or 5,000 cars. So will this scale properly?
Also, I need to add more objects to the car: like 4 windows - actually make that 6 windows, to also include the front and back windshields, then four headlights, etc.
So the final Car Object alone may end up being comprised of 20 meshes - or more.
Being that I’m kinda new to THREE.JS I wanna make sure I develop good habits and go about this sort of thing the right way.
Here’s my code:
function makeOneCar() {
var newCarGroup = new THREE.Group();
// 1. CAR-Body:
const bodyGeometry = new THREE.BoxGeometry(30, 10, 10);
const bodyMaterial = new THREE.MeshPhongMaterial({ color: "yellow" } );
const carBodyMesh = new THREE.Mesh(bodyGeometry, bodyMaterial);
// 2. TIRES:
const tireGeometry = new THREE.SphereGeometry(2, 16, 16);;
const tireMaterial = new THREE.MeshPhongMaterial( { color: "blue" } );
const tire1Mesh = new THREE.Mesh(tireGeometry, tireMaterial);
const tire2Mesh = new THREE.Mesh(tireGeometry, tireMaterial);
const tire3Mesh = new THREE.Mesh(tireGeometry, tireMaterial);
const tire4Mesh = new THREE.Mesh(tireGeometry, tireMaterial);
// TIRE 1 Position:
tire1Mesh.position.x = carBodyMesh.position.x - 11;
tire1Mesh.position.y = carBodyMesh.position.y - 4.15;
tire1Mesh.position.z = carBodyMesh.position.z + 4.5;
// TIRE 2 Position:
tire2Mesh.position.x = carBodyMesh.position.x + 11;
tire2Mesh.position.y = carBodyMesh.position.y - 4.15;
tire2Mesh.position.z = carBodyMesh.position.z + 4.5;
// TIRE 3 Position:
tire3Mesh.position.x = carBodyMesh.position.x - 11;
tire3Mesh.position.y = carBodyMesh.position.y - 4.15;
tire3Mesh.position.z = carBodyMesh.position.z - 4.5;
// TIRE 4 Position:
tire4Mesh.position.x = carBodyMesh.position.x + 11;
tire4Mesh.position.y = carBodyMesh.position.y - 4.15;
tire4Mesh.position.z = carBodyMesh.position.z - 4.5;
// Putting it all together:
newCarGroup.add(carBodyMesh);
newCarGroup.add(tire1Mesh);
newCarGroup.add(tire2Mesh);
newCarGroup.add(tire3Mesh);
newCarGroup.add(tire4Mesh);
// Setting (x, y, z) Coordinates - RANDOMLY
let randy = Math.floor(Math.random() * 10);
let newCarGroupX = randy % 2 == 0 ? Math.random() * 250 : Math.random() * -250;
let newCarGroupY = 0.0;
let newCarGroupZ = randy % 2 == 0 ? Math.random() * 250 : Math.random() * -250;
newCarGroup.position.set(newCarGroupX, newCarGroupY, newCarGroupZ)
scene.add(newCarGroup);
}
function makeCars() {
for(var carCount = 0; carCount < 100; carCount ++) {
makeOneCar();
}
}
I’d like to know if this is the “proper”/best way to do this?
This is subjective. You say the method works great for your current use-case, so for that use-case, it is fine.
So will this scale properly?
The simple answer is: No. The more complex answer is: ...not really.
You're re-using the geometry and materials, which is good. But every Mesh you create has meta information surrounding it, which adds to your overall memory footprint.
Also, every standard Mesh you add incurs what is known as a "draw call", which is the GPU drawing that particular shape. Instead, take a look at InstancedMesh. This allows the GPU to be given instructions on how to draw the shape throughout the scene once. Yes, rather than drawing each cube individually, the GPU can draw all the cubes at the same time, and they can even have different colors and transformations. There are limitations to this class, but it's a good starting point to understanding how instancing works.
I'm making an appointments app.
I have this gradient structure (created in Pixelmator), with which I want to mark the times of day:
In the intended scheme, 8am would be solid green, 12 noon would be solid yellow, and 8pm would be solid blue.
I need an algorithm to take the times of day and turn them into those colors, but I can't figure it out, particularly from noon to evening.
These colors are composed using the HSB value system: all colors have S and B at 100%, and from left to right the hue values are 121 (green), 60 (yellow), and 229 (blue).
The progression from the green to yellow is (morning to noon) is straightforward, because it's just a linear scaling from 121 to 60, but from yellow to blue (noon to evening), is not; this is clear if you think about the fact that going from 60 to 229 in a linear fashion would first duplicate the green-to-yellow gradient, just in reverse order, and then would go to from green to blue. In other words, a strictly linear progression would make the gradient look more like this:
Can anyone point me in the right direction to understanding how to make the algorithm I need here? Do I have to use a different color value system, like RGB?
Thanks in advance for any and all help!
Pablo-No gives a reasonable answer if it's OK for the yellow->blue transition to go through red. But the OP's original picture doesn't go through red, it goes through some kind of grey. Perhaps the saturation S should be used to try to achieve this:
// Assume time is a real value between 8 (8am) and 20 (8pm)
// H is between 0 and 360
// S and B are between 0 and 100
B = 255;
if (time < 12)
{
// Before noon, linearly go from H=121 (green) to H=60 (yellow)
H = (time - 8) * (60-121)/4.0 + 121;
S = 100;
}
else
{
// After noon, linearly go from H=60 (green) to H=229 (blue)
// But in the middle, where the color goes green, linearly scale
// Saturation down to zero and back to 100.
H = (time - 12) * (229-60)/8.0 + 60;
auto secondGreenTime = (121-60)*8.0/(229-60) + 12;
if (time < secondGreenTime)
S = (time - 12) * (-100.0)/(secondGreenTime-12) + 100;
else
S = (time - secondGreenTime) * 100.0/(20-secondGreenTime);
}
Pixelmator looks like it's using RGB gradients. Demo:
const canvas = document.getElementById("gradient");
const ctx = canvas.getContext("2d");
for (let i = 0; i < canvas.width; i++) {
const alpha = (i + 0.5) / canvas.width;
const r = 2 * Math.min(alpha, 1 - alpha);
const g = Math.min(1, 2 * (1 - alpha));
const b = Math.max(0, 2 * alpha - 1);
ctx.fillStyle = `rgba(${255*r},${255*g},${255*b})`
ctx.fillRect(i, 0, 1, canvas.height);
}
<canvas id="gradient" width="240" height="40">
Here is an algorithm for that:
Convert the hour to 24 hour and pass minutes and seconds to a fraction or a decimal number (i.e 8:30 -> 8.5, 8:20 -> 25/3)
Substract 8 to the hour (now we have a number from 0 to 12)
If the hour, h, is between 0 and 4 we will do ((-h+4)*(61/4))+60
else we will do ((-h+12)*(191/8))-131
If the value is negative we'll add 360
The value we obtain will be the hue value of the color
The subject comes from an old challenge on codingame.com.
The play area was a rectangle of 10000 x 8000 units.
I have an object with a position (objectX, objectY) and a velocity vector (speedX, speedY).
I have an object with a position (objectX, objectY) and a velocity vector (speedX, speedY).
To move this object, I have to display the coordinates (thrustX, thrustY) of the thrust destination followed by a thrust value (ranging from -100 to 100).
Friction: Each steps (ticks), previous speed vector is multiplied by 0.9 before applying thrust
I want to move and stop this objet at a point with coordinates targetX, targetY (with a given error rate).
How to calculate the list of targetX, targetY and thrustValue ?
Following example use these data:
initial objectX and objectY = 1000, 2500
initial speedX and speedY = -500, 1000
targetX, targetY = 8000, 3000
thrustX, thrustX = targetX, targetY
This table use these formulas:
objectX(step) = objectX(step-1) + speedX(step)
objectY(step) = objectY(step-1) + speedY(step)
speedX(step) = speedX(step-1)*0.9 + thrustX(step-1)
speedY(step) = speedY(step-1)*0.9 + thrustY(step-1)
angle(step) = degrees(atan2(targetX(step) - objectX(step); targetY(step) - objectY(step)))
thrustX(step) = cos(radians(angle(step))) * thrust(step)
thrustY(step) = sin(radians(angle(step))) * thrust(step)
I want to find the algorithm that would make me get directly to the target rather than turn around
I'm working on a 3D scene viewer with the HOOPS Engine
I want to implement support for a 3D mouse. Everything is working fine but there is one remaining problem I don't know how to solve:
I move my camera with following formula:
HC_Dolly_Camera(-(factor.x * this->m_speed), factor.y * this->m_speed, factor.z * this->m_speed);
this->m_speed is dependent on scene extents. But if the scene is really big (e.g. a airport) the camera speed is on a deep zoom level ridiculous fast.
My first attempt was to implement a kind of damping factor which is dependent on the distance from objects to my camera. It works ... somehow. Sometimes I noticed ugly "bouncing effects" which I can avoid with smooth acceleration and a modified cosine function.
But my question is: Is there a best practice to reduce camera speed in closeup situations in a 3D scene? My approach is working, but I think it is not a good solution due it uses many raycasts.
Best regards,
peekaboo777
P.S.:
My code
if(!this->smooth_damping)
{
if(int res = HC_Compute_Selection_By_Area(this->view->GetDriverPath(), ".", "v", -0.5, 0.5, -0.5, 0.5) > 0)
{
float window_x, window_y, window_z, camera_x, camera_y, camera_z;
double dist_length = 0;
double shortest_dist = this->max_world_extent;
while(HC_Find_Related_Selection())
{
HC_Show_Selection_Position(&window_x, &window_y, &window_z, &camera_x, &camera_y, &camera_z);
this->view->GetCamera(&this->cam);
// Compute distance vector
this->dist.Set(cam.position.x - camera_x, cam.position.y - camera_y, cam.position.z - camera_z);
dist_length = sqrt(pow((cam.position.x - camera_x), 2) + pow((cam.position.y - camera_y), 2) + pow((cam.position.z - camera_z), 2));
if(dist_length < shortest_dist)
shortest_dist = dist_length;
}
// Reduced computation
// Compute damping factor
damping_factor = ((1 - 8) / (this->max_world_extent - 1)) * (shortest_dist - 1) + 8;
// Difference to big? (Gap)
if(qFabs(damping_factor - damping_factor * 0.7) < qFabs(damping_factor - this->last_damping_factor))
{
this->smooth_damping = true;
this->damping_factor_to_reach = damping_factor; // this is the new damping factor we have to reach
this->freezed_damping_factor = this->last_damping_factor; // damping factor before gap.
if(this->last_damping_factor > damping_factor) // Negative acceleration
{
this->acceleration = false;
}
else // Acceleration
{
this->acceleration = true;
}
}
else
{
this->last_damping_factor = damping_factor;
}
}
}
else
{
if(this->acceleration)
{
if(this->freezed_damping_factor -= 0.2 >= 1);
damping_factor = this->freezed_damping_factor +
(((this->damping_factor_to_reach - this->freezed_damping_factor) / 2) -
((this->damping_factor_to_reach - this->freezed_damping_factor) / 2) *
qCos(M_PI * this->damping_step)); // cosine function between freezed and to reach
this->last_damping_factor = damping_factor;
if(damping_factor >= this->damping_factor_to_reach)
{
this->smooth_damping = false;
this->damping_step = 0;
this->freezed_damping_factor = 0;
} // Reset
}
else
{
if(this->freezed_damping_factor += 0.2 >= 1);
damping_factor = this->damping_factor_to_reach +
((this->freezed_damping_factor - this->damping_factor_to_reach) -
(((this->freezed_damping_factor - this->damping_factor_to_reach) / 2) -
((this->freezed_damping_factor - this->damping_factor_to_reach) / 2) *
qCos(M_PI * this->damping_step))); // cosine functio between to reach and freezed
this->last_damping_factor = damping_factor;
if(damping_factor <= this->damping_factor_to_reach)
{
this->smooth_damping = false;
this->damping_step = 0;
this->freezed_damping_factor = 0;
} // Reset
}
this->damping_step += 0.01; // Increase the "X"
}
I've never used the HOOPS engine, but do you have any way to get the closest object to the camera? You could scale your speed with this value, so your camera gets slower close to objects.
Even better would be to take the closest point on bounding-box instead of center of object. This would improve the behaviour close to big objects like long walls/floor.
Another solution I'd try would be to raycast through the view center to look for the first object and use the distance the same way. In this approach you'll not be slowed down by objects behind you. You may also add additional raycast points, like in 1/4 of screen and blend resulting values, so you have more constant speed scale.
What I understand from your question is that you want a way to steer camera through large scenes, like an airport and still be able to move slowly close to the objects. I don't think there's some 'universal' way of doing it. All will depend on your Engine/API features and specific needs. If all those solutions doesn't work, maybe you should try with paper and pen ;) .
You said that m_speed is dependent on scene extent, I guess this dependency is linear (by linear I mean if you are measuring the scene extend with something called sExtent, m_speed equals c*sExtent that c is some constant coefficient).
So to make m_speed dependent on scene extent but avoid huge m_speed for large scale scenes , I suggest to make dependency of m_speed to sExtent non-linear, like logarithmic dependency:
m_speed = c*log(sExtent+1)
This way your m_speed will be bigger if scene is bigger, but not in the same ratio. you also can use radical to create non-linear dependency. below you can compare these functions:
I am a fairly intelligent person, but when I see a certain kind of math I might as well be a gigantic moron. I could really use some help here.
I have been researching a ton of things as I learn iOS game development and I came across a formula while doing some searches. Here is the formula:
x(t) = x(0) + v(0)*t + .5 (F/m) * t^2
Also stated was solving for x and y:
Fx = (x(t) - x(0) - vx(0)*t) * 2m/t^2
Fy = (y(t) - y(0) - vy(0)*t) * 2m/t^2
Source: Box2D.org forums
Now for my actual question, what does that mean? Keep in mind that in this situation I am an idiot. It would be great if someone could explain the variables in simple terms and how they relate to box2d. How would I apply this formula? Here is an example of my code (firing projectiles):
- (void)spawnProjectile:(CGPoint)from direction:(CGPoint)direction inParent:(CCNode*)parentNode
{
double curTime = CACurrentMediaTime();
double timeTillShotDies = curTime + SHOT_TYPE1_EXIST_TIME;
b2Body *shotBody = projectileBodyTracker[nextShot];
b2Vec2 moveToPosition = b2Vec2(from.x/PTM_RATIO, from.y/PTM_RATIO);
shotBody->SetTransform(moveToPosition, 0.0);
shotBody->SetActive(true);
CCSprite *shot = [projectiles objectAtIndex:nextShot];
shot.position = ccp(from.x/PTM_RATIO, from.y/PTM_RATIO);
shot.visible = YES;
[projectilesTracker replaceObjectAtIndex:nextShot withObject:[NSNumber numberWithDouble:timeTillShotDies]];
CCParticleSystemQuad *particle = [projectileParticleTracker objectAtIndex:nextShot];
[particle resetSystem];
nextShot++;
if(nextShot >= projectiles.count) nextShot = 0;
// dx2 and dy2 are analog stick values (see below code)
b2Vec2 force = b2Vec2(dx2, dy2);
shotBody->SetLinearVelocity(force);
[AudioController playLaserShot];
}
In this particular chunk of code I am firing from the player at the angle the analog is at. I also would need to use the formula to fire from the enemy to the player. This is a top down space shooter.
So to summarize, how do I solve constant force over time for x and y, in terms of box2d code?
Extra info:
dx2 = (float)joypadBG2.position.x - (float)convertedPoint.x;
dy2 = (float)joypadBG2.position.y - (float)convertedPoint.y;
All objects are preloaded and kept that way. Bodies are set inactive and sprites set invisible. Particle systems are stopped. The opposite is true for using a projectile again.
Thank you very much for any help you may be able to provide. I hope I haven't forgotten anything.
The first equation describes the movement of an object that is subject to a constant force.
The object starts at position x(0) and has speed v(0). Both x and v are vectors, so in a 2d shooter, x(0) would be (x0,y0), or the xy-position, and v(0) would be (vx0, vy0).
If there is no gravity then F=0 on unpropelled projectiles (projectiles without thrusters),
so the velocity will be constant.
x(t1) = x(t0) + vx * (t1-t0)
y(t1) = y(t0) + vy * (t1-t0)
t1-t0 or dt (delta-t) is the time elapsed since the last time you updated the position of the projectile.
If thusters or gravity are excerting force on an object then the velocity will change over time.
vx(t1) = vx(t0) + ax * (t1-t0)
vy(t1) = vy(t0) + ay * (t1-t0)
a is the acceleration. In a game you usually don't care about mass and force, just acceleration. In physics, a = F/m.
Edit 1:
In computer games, you update the position of an object very frequently (typically around 60 times per second). You have the position and velocity of the object at the previous update and you want to calculate the new position.
You update the position by assuming that the velocity was constant:
positionVectorAt(newTime) = positionVector(lastTime) + velocityVector*(newTime - lastTime);
If the velocity of the object is changed you also update the velocity:
velocityVectorAt(newTime) = velocityVector(lastTime) + accelerationVector*(newTime - lastTime);
Let's say we have a sprite at
positionVector.x=100;
positionVector.y=10;
The initial speed is
velocityVector.x = 3;
velocityVector.y = -10;
The sprite is using thrusters which is giving a horizonal acceleration per second of
thrusterVector.x= 5;
and it is also subject to gravity which gives a vertical acceleration per second of
gravityVector.y = -10;
The code to update the sprites position will be:
deltaTime = now - lastTime; // Time elapsed since last position update
// Update the position
positionVector.x = positionVector.x + velocityVector.x * deltaTime;
positionVector.y = positionVector.y + velocityVector.y * deltaTime;
// Update the velocity
velocityVector.x = velocityVector.x + (thrusterVector.x + gravityVector.x) * deltaTime;
velocityVector.y = velocityVector.y + (thrusterVector.y + gravityVector.y) * deltaTime;
// Done! The sprite now has a new position and a new velocity!
Here is a quick explanation:
x(t) = x(0) + v(0)*t + .5 (F/m) * t^2
Fx = (x(t) - x(0) - vx(0)*t) * 2m/t^2
Fy = (y(t) - y(0) - vy(0)*t) * 2m/t^2
These 3 equations are standard movement ones:
t: time
x(t): position at time t
v(t): speed at time t
vx(t): horizontal component of speed at time t
vy(t): vertical component of speed at time t
m: mass
F: force
Fx: horizontal component of the force
Fy: vertical component of the force
So of course, each time you see x(0) or vy(0), these values are taken at time t, i.e. they are initial values. These equations are basic cinematic equations with the basic cinematic variables (position, speed, force, mass).