Jump to content
  • Advertisement

cannonicus

Member
  • Content Count

    136
  • Joined

  • Last visited

Community Reputation

136 Neutral

About cannonicus

  • Rank
    Member
  1. cannonicus

    Getting my head around RK4

    Hello, You don't need to make your derivative function explicitly dependent on time. You have the option to, but you don't have to. Typically, games do not. Your state however depends on time, in the sense that it evolves with time. But as long as you have your state for the wanted time, you don't need to input the actual time into your derivative function. So, how implement RK4 in practice? Wikipedia has a decent article on this. Lets start with definitions: y is your state. This is the complete state, including both positions and velocities. A point moving in three dimensions would have the state (px, py, pz, vx, vy, vz). This can be written more concisely as (p, v) y' is the time derivative of the state. So y' = (p, v)' = (v, a). Since a = 1/m * f, the forces of the system needs to be calculated to evaluate y'. f(t, y) give you y' for a given state at a given time. As I said before, you don't have to, and in this case shouldn't, have a direct dependence on time in this function. Just calculating the forces on the system given by the current state (y) is sufficient. Anyhow, lets calculate the k-values of RK4: k1 = f(t_n; y_n) Here you need to evaluate the forces of the system at state y_n, and save the forces divided by masses in k1 and the current velocities. k2 = f(t_n + 0.5h; y_n + 0.5*h*k1) Here you first need to create a temporary state, y_n + 0.5*h*k1. Evaluate the forces for this temporary state to obtain k2. k3 = f(t_n + 0.5h; y_n + 0.5*h*k2) Here you need another temporary state, y_n + 0.5*h*k2. Evaluate forces. k4 = f(t_n + h; y_n + h*k3) I guess you can figure this out Finally, y_{n+1} is given by: y_{n+1} = y_n + h / 6 * (k1 + 2k2 + 2k3 + k4) When it comes to objects interacting with each other, like collision handling etc, you need to evaluate this every time you evaluate the force for a given state. I.e., in your temporary state needed when calculating k3 two objects might collide with each other while not colliding with each others in the temporary state needed to calculate k4. Collision forces should be generate in the first case and not the other. (given that a force based collision avoidance scheme is used) Thats it basically, given that you have the ability to create these temporary states and calculate forces from them, implementing RK4 is not much more difficult than Euler integration (but lots more code ). It is however way more computationally expensive to use, which is probably the reason it's not commonly used in commercial games. But it is a fun exercise to implement! Hope that clear things up for you. //Emil
  2. Double check your math a couple of times! A few hints: c_2 never appears in the dx_dt and dy_dt functions. Third term in the expressions for x and y. Next last term in your and expressions. Also what iMalc said, but thats probably just a typo. Infact all of these things are probably typos. Your going about this thing the right way, but the details are slightly wrong. //Emil
  3. cannonicus

    Recursion in C++

    Recursion and tree structures go hand in hand. And tree structures (such as file systems, as in gretty's example) are very useful. [edit] Very deep recursion in c++ can be a problem though since it has limited stack size, especially if you're developing for embedded systems. On a computer you can set the stack size at compile time to something safe for your application.
  4. cannonicus

    Transform Vertex Coord: How?

    You cannot translate 3d vectors with matrices. You have to use 4d vectors with the 4:th component = 1 (homogeneous coordinates).
  5. cannonicus

    [GL] Transparency Issue

    Because of filtering of your texture. Try disabling it with: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); //Emil
  6. Hello! Im new to opengl but not to 3d rendering concepts. Im using opengl 2.0 + GLSL to render some stuff. I want to render to one or more off screen surfaces, possibly of different pixel formats. Can i do this in standard ogl2.0 or do i have to use some extensions? If so, which one? I know this is fairly standard functionality in graphics cards newer than geforce 6000/radeon 9000 series, and ive used this in directX, but now i want to do it in opengl too. Any links or google keywords are greatly appreciated. Also, id like to use floating point textures, like 4 * 32bit float pixel format. What extensions do i need for that? //Emil
  7. cannonicus

    Verlet Integration Problem

    Im unsure how this works. Ive never worked with quarternions. The way i understand quarternions they're like complex numbers only with 3 imaginary parts instead of one. In that case the notation should be: orientation *= orientation / prev_orientation * acc * dt^2 where acc is some quarternion acquire from your bodies intertial matrix and applied torques. Just dividing the torque vector with the mass wont do in 3d. Alot of things get more complicated when moving from 2d particle physics to 3d rigid body physics. But im probably totally wrong. How to acquire acc and your inertial matrix is another topic for another thread.
  8. cannonicus

    Verlet Integration Problem

    Yeah, no problem. You can use verlet for any function you know the second derivative to. Orientiaion(t) is no exception.
  9. cannonicus

    Verlet Integration Problem

    Thats correct behaviour. Your just changeing the acceleration, but maintain the velocity, so when you start the simulation the second time the particle will still have whatever velocity it had when the simulation was paused. If you want the particle to have another velocity when the simulation is restarted youll have to reinitialize prev_position according to that velocity.
  10. cannonicus

    Verlet Integration Problem

    No, just no. I cant reproduce your problem. Maybe ive missunderstood something. I tried putting the acceleration to +4, and the particle moved upwards as expected with what looked like 2 m/s initial velocity and some acceleration. The position never dropped below the initial value.
  11. cannonicus

    Verlet Integration Problem

    No, i really cant see the particle moving downwards at all with acc = +10 and vel = 2. Are you sure youre using the same version of the program as i am? Quote: And for my code its: potensial energy = particle.getMass() * particle.getAccel().y * particle.getPos().y No, you need the minus sign. Think about it. You want the potential energy to increase as you move to higher positions, right. So when y-acc is -10 and y-coord goes from 0 to 2 you will need the minus sign to get a higher energy for y=2. Your probably thinking about the textbook example potential energy Ep = mgh but in this case they have introduced the y-direction as pointing downwards, while your y axis is pointing upwards, hence the minus sign. //Emil
  12. cannonicus

    Verlet Integration Problem

    Quote: When i change acceleration does it need to do before simulation thing: prev_position = position - velocity*Integration timestep, or not? No, dont do that. You only need to do that before you start the simulation. When the simulation is running prev_position will always be the position of the particle in the last frame, you can apply any acceleration each simulation tick. Honestly i cant see anything wrong with the simulation i downloaded. Seemed to work allright. But if you want to be sure you can always calculate the particles total energy each frame. As long as you dont change the acceleration the total energy should be constant. Total energy = Kinetic energy + potential energy Kinetic energy = 1/2*m*v^2 potential energy = -m*y-acceleration*y-coordinate Quote: Now the problem here is when i make acceleration positive, there comes a bug i guess so. It goes downward a little bit and then goes upward. Why? (Change the acceleration from -10 to 10 and see what happens) I couldnt reproduce this.
  13. cannonicus

    Verlet Integration Problem

    Well, its only 0.01 sec between each line, so its not surprising the value is changing so slowly. (Assuming you now have velocity = (0 0 0), else something is still rotten) Congrats by the way and have fun with your verlet integrator :) //Emil
  14. cannonicus

    Verlet Integration Problem

    Damn, you beat me to it ;) Quote:Original post by grhodes_at_work Quote:Original post by cannonicus Do you ever initialize prev_position? You set your initial velocity to (0 5 0), so i guess prev_position should be position - velocity * dt ? Hope it helps. //Emil Kasya is using the basic Verlet integration, which represents velocity implicitly, e.g., velocity is not needed in the integration step. The derivation of the scheme cancels out the velocity terms. Yes, but the previous position of the particle is. What i meant is that he initializes position to (0 50 0) but doesnt (as far as i see) initialize prev_position (leaving it to 0). Thus the particle will have initial velocity of (0; 50/dt; 0) and not (0 5 0), which gives the exact numbers posted in the first post. Kasya: I didnt mean you should do prev_position = position - velocity*dt every integration tick, only before you start your simulation. So, basically what im saying: /* Testing */ //Specs: position = Vector3(0, 50, 0) acceleration = Vector3(0, -10, 0) velocity = Vector3(0, 5, 0) Mass = 10 Integration Timestep = 0.01 prev_position = position - velocity*Integration timestep ///////////////// You shouldnt have 2*position when you use += operator. You were right in your first post. Also, about your first post: you do have an initial velocity of (0 5 0), so its natural for the particle to move upwards for some time before reaching its peak height. Try velocity (0 0 0) to debug. It shouldnt give you any positive motion in y-direction. Quote: I tested the code without velocity too. But the results are same. This is just more proof that prev_position is you problem. //Emil
  15. cannonicus

    Finding closest point on tri to point

    A straightforward way of solving this is to project your point to the plane of the trangle, using triangle edges as basis vectors for your plane. This will give you the projection of the 3d point on a 2d surface where the triangle has vertices in (0, 0), (0, 1) and (1, 0). So its very easy to check whether your projected point is inside the triangle or not. So: //Triangle has vertices in v0 v1 and v2. P is your point r0 = P - v0 r1 = v1 - v0 r2 = v2 - v0 q1 = (r1 dot r0)/length(r1)^2 q2 = (r2 dot r0)/length(r2)^2 //now q1 and q2 are the coordinates of the projected point along r1 and r2 //is point in triangle? if (q1 > 0 and q2 > 0 and q1 + q2 < 1) yes //projection point in 3d space is v0 + r1*q1 + r2*q2 else no //find the closest point on the triangle if (q1 < 0){ if (q2 < 0) v0 is your closest point if (q2 > 1) v2 is your closest point else your closest point is v0 + r2*q2 } // if q2 < 0 you do basically the same as above if (q1 > 0 and q2 > 0) //this is trickier { t = (1 - q1 + q2)/2 if (t > 1) v2 is closest if (t < 0) v0 is closest else your closest point is v0 + v1 + (v2 - v1)*t } Lets hope i didnt screw that up to much now :) Hope it helps //Emil
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!