I want to simulate fire using SPH particles. I understand the concept behind SPH but don't understand yet how to model the fire as a fluid.
Do I have to add some temperature property to my particles from which I can derive there color?
Do I have to take the surrounding air particles in account to create some buoyancy effect?
Where do the particles get their heat from? Do I have to add a heat emitter over some space which creates warm particles so that the temperature then diffuses to the other particles over time?
Are there some tutorials which describe my problem?
Yes, you'll have to have a temperature property. It really isn't fire if temperature isn't involved. And once you have temperature it's easy to get luminosity and color. (You probably don't have to worry about radiative heat transfer, at least not for a first effort.)
If you handle pressure and gravity right, buoyancy will arise (ahem) naturally.
You can start with a fixed heating element and an inert gas, then when you're ready you can introduce combustion as a differential equation: the rate of energy generation is a function of temperature, fuel pressure and oxygen pressure.
Related
Description of the situation
I want to use the BOSCH BMI160 sensor to check the speed of the vehicle on the go.
GPS is not available in the current situation.
Question
What is the formula for getting velocity from a 3-axis acceleration sensor?
Is there an error of more than 10% when an error occurs in an uneven area of the hill or the ground?
Resources
BOSCH BMI160 DataSheet : https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMI160-DS000.pdf
Thank you
What you want to do is called "inertial navigation", which is an error prone technique, by nature.
The operation you need is 3 axis accelerometer integration and 3 rotation integration, to get the heading and speed of your system. Moreover you need your initial state (speed and orientation) from which your integration should start. It is not at all a simple operation, and errors accumulate with time, and depend from many factors (starting from the accuracy of the sensor).
If you don't need the heading and you just care about linear speed in the direction of the car, you can reduce to single axis integration in the car direction, which is simpler, and may work well for a short period of time. Due to gravitational acceleration, you could have problems when going up-or-down-hill, because you will have to get rid of the average acceleration
I am trying to extinguish the fire particle using Unity water particle. Which is working. But the water particles Splash effect is overflowing. I tried to scale it but it"s not working. So how can I reduce the splash effect?
To stop the water particles from overflowing you can do a combination of two things:
decrease emission rate of particles or the velocity of particles. You find these things under certain modules. Here is the list of modules:
To change the emmission rate, find the particle system in the inspector and go to the emmission module. If not already opened - open it. Adjust the Rate over Time variable to a lower value, you should notice a lot less particles being formed.
Then to change the velocity of the particle system, this one can be change a few ways. And, it depends on how you change it for your water to go upwards. A good place to check is in the Velocity over Lifetime module and you want to decrease the speed modifier or the linear velocity values.
You may also want to check if lowering any velocity values from Limit Velocity over Lifetime, Inherit Velocity, Force over Lifetime solves your issue.
EDIT
To stop emitting particles just set the prediscussed particle emission Rate over Time back to 0. To do this inscript:
GetComponent<ParticleSystem>().emission.rate = 0.0f; // Or a higher number if you want to restart it
Also, when I notice your particle system, you don't have to add burst like I have done so in the examples. Just change the specific variables mentioned.
I have a small remote controlled car going on the room floor. For simplicity let us assume it is moving along say x-axis. Now, the floor seems flat but there are very minute uneven bumps in every surface. So whenever the car is not exactly flat (as it was at starting position) or in other words whenever the car has even slightest of tilt then,
Total Acceleration obtained from accelerometer = Linear Acceleration + Acceleration due to tilt
My question is how to remove the acceleration due to tilt so that I get only linear acceleration? Can I somehow use gyroscope to do that?
I have implemented sensor fusion for the Shimmer platform based on this manuscript, it's basically a tutorial:
Direction Cosine Matrix IMU: Theory
This manuscript pretty much answers your question.
These have also been a big help:
An introduction to inertial navigation
An Introduction to the Kalman Filter
Pedestrian Localisation for Indoor Environments
Combine Gyroscope and Accelerometer Data
Just promise me you won't try double integrating the linear acceleration because it won't work and I suspect that it is what you are trying to do.
I'd like to build a game to learn cocos2d. Lunar lander is the first exercise coming in my mind. Any pointer/source code/tutorial of the physics calculations required will be appreciated. Thanks!
You'll need stuff like this:
Newton's laws of motion in 2D.
Ability to change effect of gravity. 9.8 m/s^2 is the right acceleration on earth, but you should be able to change this to the appropriate value for Mars, moon, Jupiter, etc.
Ability to turn thrusters off and on to counteract the effect of gravity. Not a very interesting game if you don't, because every one ends in a crash.
Way to relate duration of thruster fire with fuel consumption. If you don't manage fuel well you crash.
Initial conditions (e.g., height above surface, initial velocity, initial fuel, etc.)
You'll start with initial conditions and loop over a number of time steps. At the end of each step you'll check the position and velocity. If the y-position above the surface is zero or negative you'll have landed. If the velocity is greater than a critical y-value you'll have a crash; less than the critical value means a safe, soft landing.
You'll solve Newton's equations of motion numerically. In your case it's four coupled, first order ordinary differential equations: rate of change of velocity in x- and y-directions and rate of change of position in x- and y-directions. If you have the thrusters in place you'll add another equation for conservation of mass for the fuel.
You can eliminate two equations if you assume that there are no x-components: the lunar lander moves perpendicular to the surface, the thruster force only has a non-zero component in the vertical direction. If that's true, you're down to three equations.
You'll do time stepping, so it'll be good to read up integration techniques like explicit Euler or implicit 5th order Runge-Kutta.
A challenging problem - not trivial. Good luck.
The math you need for a lunar lander game is pretty straightforward. Newton's Laws of Motion are all you really need - just pick up a basic physics textbook. You should be set after the first chapter. There are only two force inputs in the system - gravity and thrust from the engines. Just calculate the vertical & horizontal components of the motion, and animate your spaceship accordingly.
The physics are very simple: http://csep10.phys.utk.edu/astr161/lect/history/newtongrav.html
I assume you won't be worrying about drag or wind, so depending on your angles of inclination (user input), you'll be implementing:
Sourced from: http://en.wikipedia.org/wiki/Trajectory. You can even probably get away with simplifying it. If you don't want to be super-accurate, you can just do something like F=ma where is is whatever you decide the gravitational acceleration to be (9.8 m/s² on Earth).
If your game is in 2D, You don't need much math, you need physics, Specifically basic Newtonian motion. Probably intro college or late high school. The math is some grade school algebra with early high school calculus.
If you look at up-down motion, then your ship is essentially an object that is exposed to a force of gravity (the constant depends on your "moon") negated by the force emitted by its engines. You can use that to determine acceleration and from there velocity. Using the velocity, you can do your collision-outcome. The left-and-right motion is easier, since if your moon has no atmosphere, you are merely applying a constant force.
If you want something more realistic, you can modify the gravity constant based on distance from the surface, and can add an atmospheric friction force (though it wouldn't really be our moon).
If your game is in 3D, and your ship has side thrusters in addition to bottom thrusters, then you would not only have motion in location but also rotation. That has to do with rigid body physics. AFAIK that involves college level calculus.
This may be overkill, but I recommend looking at Numerical Recipes -- read the chapter on ordinary differential equations. You don't even need to study the entire chapter; just the first couple of sections.
In two dimensions, on every time tick you want to add the ship's rotational thrust to its rotational velocity, add its rotational velocity to its current heading, compute a thrust vector by multiplying the sine and cosine of its heading by its main thruster output, add that vector and a gravity vector (a straight downward vector of some magnitude) to its current velocity, and add its current velocity to its position. If the timer ticks are small enough, that's pretty much all you have to do, other than check to see if the craft is in contact with the ground. Experiment with the magnitude of your thrust and gravity values until you have a playable game.
Is it possible to determine the speed at which someone is shaking their iPhone? This would be the time they start moving to the ending point where they are now going back to the origin. Basically it is one swipe that I'd like to measure the speed of. This discussion comments on initial speed: http://discussions.apple.com/message.jspa?messageID=8297689#8297689. It seems that the important component of distance is lacking in the iPhone to get a good measure of speed.
Sure, it sounds like all you'd need to do would be to numerically integrate the acceleration twice to get the distance traveled. For instance, look at
Calculate the position of an accelerating body after a certain time
Note that you'll have to subtract gravity from the measured acceleration to get the kinetic acceleration, which is what you should integrate. As for how to do that, re: GoatRider's comment: I might try storing the last measured acceleration whose magnitude was equal to gravity (I think that's 1 in iPhone units?). Then for each acceleration measurement you make whose magnitude is greater than 1, subtract the last known acceleration of gravity - this will need to be a vector subtraction - and use that as the kinetic acceleration. Of course, this assumes that the user keeps the phone in the same orientation throughout the swipe, which I think would be approximately true.
Unfortunately, there's no technique you can use to distinguish between gravitational acceleration and kinetic acceleration in general - that is, a determined user could always find a way to fool whatever algorithm you might come up with. (Trivia: that's called the equivalence principle, and it's the foundation of Einstein's theory of general relativity)
You'll have to do the calculations yourself. Each acceleration event you receive will tell you the relative G-forces registering on the accelerometer and the time at which the event was recorded. You'll have to sample over several events and interpolate. Here's more info on the acceleration event itself:
UIAcceleration Class Reference