# Shai

Member

925

540 Good

• Rank
1. ## making a ball roll

I have a ball that needs to rotate around its global X and Z axis. If I do glRotatef(angleX, 1.0f, 0.0f, 0.0f); glRotatef(angleZ, 0.0f, 0.0f, 1.0f); then the ball will rotate around the global X-axis and the local Z-axis. (The local Z-axis is the global Z-axis after it has been rotated around the X-axis by the first rotation). If I change the order of rotations, the opposite happens. Is there any trick to get both rotations to occur around their respective global axes?
2. ## What causes a ball to rotate? [now with actual content]

Solved it :). Thanks guys.
3. ## What causes a ball to rotate? [now with actual content]

I've recently started work on a very basic physics engine. Right now, I'm trying to figure out which forces are responsible for causing a ball, going down a slope, to roll. The basic setup is shown in the picture below. The following is what I see happening. It's obviously wrong, so I'm hoping somebody could point out to me what mistakes I'm making and could help me correct them. At time 1, the ball is placed on a slope. Gravity acts on the center of the ball. The normal force has magnitude m*g*cos(theta) and acts on the contact point between ball and slope. A frictional force with magnitude coeff*m*g*cos(theta) acts on the contact point. The direction of this force is tangential with the slope. Since the tangential component of gravity (not pictured here) is bigger than the frictional force, the ball will start sliding down the slope. The frictional force will now generate a torque that causes the ball to start rolling. This torque can be calculated as the cross product of the frictional force and the vector between center and contact point. (I'm ignoring inertia, since it's just a constant.) At time 2, the ball has come down the slope and is now rolling along a flat plane. Once again there is gravity, a normal force and friction. Since theta is 0, the frictional force is now equal to coeff*m*g and is hence bigger than it was at time 1. This in turn causes the torque to be bigger than it was at time 1, which causes the ball to rotate faster. However, the frictional force also causes the ball to slow down. So, according to my - obviously wrong - calculations the ball would start rotating faster, while slowing down. Please tell me what I'm missing here. edit: forum acting weird... apparently this post didn't have any content at first [Edited by - Shai on May 15, 2008 7:58:56 PM]
4. ## ordering a list of 3d vertices in (anti)clockwise order

Thanks for the help guys, I've got something working now :).
5. ## ordering a list of 3d vertices in (anti)clockwise order

my frame of reference would be the center of the coordinate system
6. ## ordering a list of 3d vertices in (anti)clockwise order

If anyone knows a way to check whether a bunch of 3d vertices are ordered (anti)clockwise... I'll settle for that too :).
7. ## ordering a list of 3d vertices in (anti)clockwise order

Hi, I have a list of four 3d vertices and was wondering how I could order them in clockwise or anticlockwise order. I considered Graham's scan, but that doesn't work for 3 dimensions. Does anyone have any suggestions on how to do this? It doesn't matter if it isn't very efficient, it just has to produce the correct result. :) Many thanks in advance.
8. ## timing individual passes

I got a program which consists of 2 passes. The totale framerate is 370 fps. I'd like to time how many milliseconds are spent on each pass. Is there any way to do this? So far I've tried using GetTickCount and timeGetTime() to get the time at the beginning and at the end of a pass. But when I substract these two values, I always get zero. What am I doing wrong?
9. ## overhead of switching between different framebuffer objects [BUMP]

oh come'on... one of you guys must know something about it :)
10. ## Quick question about Cg

Make sure you start with glEnable(GL_VERTEX_PROGRAM_POINT_SIZE_ARB). Then in your vertex shader you can output a value to the PSIZE register. This sets the size of the points.
11. ## Calculating the normal of a vertex in a grid

luckily I'm using a grid of which the vertices are displaced using low amplitude Perlin noise. So I probably won't be running into this problem. Thanks for the warning though :).
12. ## overhead of switching between different framebuffer objects [BUMP]

For my application I need 2 different framebuffer objects. One that works with 16-bit textures and one that works with 32-bit textures. The application itself consists of 5 passes. The first 3 passes are done with the 32-bit textures, the other 2 with the 16-bit textures. So between the 3th and 4th pass I switch between framebuffer objects. This switch is the cause of a fair drop in the framerate. But why is this? What exactly happens during such a switch that takes up so much time? Isn't it just a matter of changing the pointers that point to the framebuffer and depth buffer or am I missing something? [Edited by - Shai on August 12, 2007 8:29:46 AM]
13. ## Calculating the normal of a vertex in a grid

Exactly what I needed :). Thank you.
14. ## Calculating the normal of a vertex in a grid

Hi guys, I've got a grid of 100x100 vertices. Every vertex has 8 neighboring vertices. How can I calculate the normal of a vertex using the position of the 8 neighboring vertices? Does anyone know a formula? Thanks in advance.
15. ## is it possible to attach textures of a different format to a single FBO?

damn, I was afraid that might be the case