TWiki > Team5 > ProjectTwo (r1.14)	TWiki webs: Main | TWiki | Know | Sandbox
	Team5 . { Changes | Index | Search | Go }

-- BrianYoung - 02 Oct 2004

Divided work for basic stuff, and discussed how actual classes are divided.

• The environment, or GolfWorld? class. Has data structures for triangles and the ball.
• The CollisionDetector? class. Has functions that accept triangles and the ball, return any data we need from collisions, and what-have-you.
• The ball as its own class, with CollisionDetector? as a friend. The collision detector can then manipulate the ball's velocity and stuff.

-- BrianYoung - 02 Oct 2004

Well, because I don't know how C++ vectors work, there's a bug in the world destructor. This note is mainly here for my reference so I can find it later. I also massaged the files to make dependencies work, and added return false to all the undone collision detections so we could at least get a build.

Instead of just boolean collision detection functions, do we want two sets: alphaCollide to return the time at which the collision will take place (1.0 being never) and normalCollide to return the normal vector it could occur with? Then in our timestep function, we call alphaCollide on all the triangles, decide which will collide first, then normalCollide on just that one.

-- BrianYoung - 04 Oct 2004 (let me know if I'm coming off as bossy)

Fixed the destructor bug; found that the vector was storing copies of our Triangles after all. Also implemented the world timer, and a world pause. Current state of project - white ball on green background, press space to make the ball start or stop moving.

Also, in golf.cpp there is commented code for timeStep that just needs alphaCollide and normalCollide implemented, and will be ready to go. Next up - make the ball feel gravity!

-- BrianYoung - 05 Oct 2004

GolfWorld? and GolfBall? classes are done. World is stored as global _world; ball is stored as _world._ball. CollisionDetector? should have an alphaCollide function that takes a ball and a triangle and returns the float betewen zero and one when they will collide; and a normalCollide function that takes the same and returns the normal that they'll collide with. After that, uncommenting the code in timeStep should make it work nice and happy (and removing the _ball.move(1) at the end).

I can answer questions. I have an algorithms test, thoguh, aso I may not get much coding time in. I'm in a big hurry.

--Brian

So, I've gone through the CollisionDetector? stuff to make it fit with current variable names and whatnot. The next step here is to implement the alphaStep function Brian wants; that should be relatively straightforward, as the three collision algorithms (edge, face, and vertex) return the alpha values; we just run all the possible cases and return the smallest alpha. The normal one will be a bit different; (for one thing, we'll need to implement calculating the normal vectors) and then get it to return that. The best way to do this is probably to have the functions that are already written return (alpha, normal) pairs and then have the normalCollide just use the same results as the alphaCollide so we don't check everything twice.

Now, however, I am going to sleep. I'm going to be really busy tomorrow, hopefully not forever, with PLs homework; LSD after midnight and Thursday morning is always a possibility.

MacMason - 06 Oct 2004

I've added in my code for vertex collision, and I'd LOVE to have you guys look over it. Here are some of the problems I ran into: * The web page said I needed the triangle normal in my collision, and when writing it I assumed a triangle object would have something like... triangle.normal[0] or something like that. Anywho, it may not be needed. I'll look into it and see if I can work around it, but I'd still like you guys to look it over (my code is very well documented, you shouldn't have too many questions about what I'm doing with my code). * I couldn't get it to compile. I loaded stuff into a project in NET and I get a handful of errors (many are about GolfBall? in the collidor class not being an identifier). Anyways, I'll work on this a bit and let you know if I get anywhere, but there were a few other errors I couldn't fix as well, so I'm unable to test the code at the moment.

Also, I'm heading to work on interface stuff, which won't really be able to happen until I can get things compiling.

-- JasonArold - 06 Oct 2004

GolfBall? and GolfWorld? classes are now split into their own files. Also, I added a global normal(Triangle t) function that will return the normal vector to a given triangle. I'll be back in the LAC at 11; from there I'll try to get triangle standard-orientation stuff working.

Brian

We changed a bunch of stuff; the Wiki just ate my typing. At the moment, the ball manages to have velocity even when we tell it not to. See also the comment in the collider to figure out how we're making our "take a triangle as input" code take a line or a vertex.

-- MacMason - 07 Oct 2004

After stealing some matrixmultiply and transformation code from the assignment website (insert evil laugh here) I should have the triangles set so they not only store theire spatial vertices vn, they also store their standardized vertices sn. Collide should work with those instead - I thought I changed it to do so but it's not behaving nicely. I'll be back to this in tht "morning"..

Brian

So, during class, we've decided the following:

• Triangles should be a class, not a struct.
• Triangles should store:
  • Their vertices
  • Their standard form
  • The matrix to transform themselves from non-standard to standard.
  • The standard forms of their edges
  • The transformation from non-standard to standard for each of the edges
  • Color / texture / whatever

The triangle constructor should take in three vertices and compute all of these member variables from that.

-- MacMason - 07 Oct 2004

I've narrowed the problems I've been having in standardization down to glGetFloatv not working. It should load the current OpenGL? transformation matrix into the parameter we give it; right now it leaves the parameter happily alone.

Problem solved, stupidity averted. I updated alphaCollide to check all edges and vertices; I'm going to clean up the collidor files now, and then try to get true normal collisions working. Meanwhile, Jason has some dead sexy graphics effects in the works.

Brian

Brian and I were working tonight. I implemented lighting (ambient, diffuse, and specular). I also worked on fog effects and textures. Fog didn't look so hot without more triangles, and textures caused things to crash, so I'll visit with prof Z about those. Anyways, I'll keep tweeking stuff this weekend, hopefully adding some camera movement via the mouse and point-lights rather than diffuse ones.

-- JasonArold - 08 Oct 2004

Ok don't be angry. I added initial camera stuff, so make sure you update. You'll notice a new class, the CCamera class, in addition to a TON of other tweaks to get it to work. Fortunately, I didn't comment very well.

One thing you'll notice is that I started using the windows.h header, as it provides some functionality necessary for smooth camera movement (and I think we'd have to end up using it later anyways).

About the camera... two things. First, it doesn't work well. Things move, but there's some disconnect between my code and that of the tutorials that makes it not work well. We have strafing and rotation, but they're not at all near 'correct.' Secondly, mouselook is currently the default. So, if you run the .exe, you may notice that you have to ctrl-alt-del to get out of it. This will be the case until (a) you fix it or (b) I fix it tomorrow morning. Sorry, it's sort of a nasty side effect.

Anyways, I'll get working on stuff. I may switch our interface around from a standard glut one to a flashy windows one, and that might make things work correctly (I think it has to do with box dimensions...). Also, that would let me import textures, and I want to import textures.

-- JasonArold - 09 Oct 2004