TWiki > Team5 > ProjectTwo (r1.30)	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

Added a config file parser; it will let us define an arbitrary number of triangles and set the ball's start position and velocity without hours and hours of typing.

See also: I could have done this in four lines in python. C++ => very bad with text handling, and I feel the need to complain about it.

-- MacMason - 11 Oct 2004

Ball now spins and bounces approximately correctly; at least, it rolls down a hill properly; at least, more properly than it has earlier.

-- BrianYoung - 12 Oct 2004

Created several test cases, including the "crazy ball in the box" case. Also made tranparency work. Also, digitized diagrams and posted them to Wiki.

-- JasonArold - 14 Oct 2004

BIG CHANGES! Very important! Firstly, Brian: you need to talk to me about our changes to world.cpp and golf.cpp. It won't let me merge. :-( Second: I've added implementation for ghosts that follow the ball around! right now, there are 4 shiny, beautiful little white ghosts that follow the ball around in crazy circles, rotating and spinning. It's really a sight to see! The downside is that you might not be able to get this to work until brian and I merge stuff. but it works well on mine (you should TOTALLY take a look). So, add in the 4 Model files (MilkModel?.h/cpp, and Model.h/cpp) and move the skulltest.m3sd (I think that's the extension...) into the location of your .exe. Brian, since you were working on that 'hole' thing, I also want to talk to you about building the final golf course so I can get working on a few other things.

Textures and Cameras are on the way. Z said they'd be on the web page, but that probably won't happen till later this week. -- JasonArold - 19 Oct 2004

Lots of changes for me in the last 24 hours! -Camera is now functional (mostly). some builds don't have the camera working, but if you hit "build" once or twice more, the camera works. I'll look into this. -Implemented texturing (roughly). Haven't tested it, but the code compiles. -Updated the course given by mac and brian last night to make it more on scale with the ball. Only problem now is getting the hole to work. How did you guys do it last night? Also, the two cones don't make the ball do what it should. Basically, any velocity shoves the ball into the air. -Added shiny red bumpers around the entire course (you have NO IDEA how long that took). -Added three planes to denote the 'game world. -Added 2 Goblin statues near the ramp

What I need next is -the hole to work -the cones not to act weird (ball should 'roll' over them, ideally) -invisible walls to keep the ball in the course (I'll do this later, it should only take about a half hour).

-- JasonArold - 20 Oct 2004

Well, the project is due in one week. We've got the hole to work, we got the cones set up right, and we got invisible walls set up. Our work plan is as follows:

Jason: Work on textures and the golf paddle/ball visualizations. Finish up any visual tweaks Brian: Finish physics and implement ball-hitting functions and gameplay Mac: Work with sounds/music, and the 'powerbar' visual and implementation.

all in all, it's looking pretty great. Good work, team! -- JasonArold - 22 Oct 2004

Textures are in. Be sure to load the .bmp files into the folder with the .exe, otherwise god will hate you. there's also an updated goblin model with a few teeny tiny tweeks, so plop that in there as well.

A current 'bug' is the hole. I've textured right on over it. Sorry bout that. I'll fix that sometime this weekend.

Ball and Club models aren't on the page yet, so I won't be doing anything with those until they are so I can see how she implemented them. Nice work on the stuff from last night, by the way. I was so happy to come in and see... well... a working mini golf game! -- JasonArold - 22 Oct 2004

GolfWorld? is implemented as a singleton now. GolfBall? is not - in the theoretical version 2, we would have a different ball for each player. CollisionDetector? is also not, since it has no member data anyway. Also, I committed a .zip to CVS, and will upload it here, with a folder containing our final build and all necessary data files.

-- BrianYoung - 30 Oct 2004

I've attached rough draft (in .pdf and .tex) of the User's Guide. People should give it a once-over. -- MacMason - 01 Nov 2004

A rough draft of the Final Report (again, in .pdf and .tex) is attached. -- MacMason - 02 Nov 2004

Attachment:	Action:	Size:	Date:	Who:	Comment:
ClassDiagram.gif	action	7768	14 Oct 2004 - 19:25	JasonArold	Class Diagram as of Oct 14
Prototype2.exe	action	372736	14 Oct 2004 - 20:20	BrianYoung	Requires config.txt
coneworld.txt	action	798	14 Oct 2004 - 20:20	BrianYoung	World with spiky thing and hat
Week2workchart.gif	action	2422	14 Oct 2004 - 20:47	JasonArold	Work Chart for week 2
Prototype2stuff.pdf	action	41386	15 Oct 2004 - 17:21	BrianYoung	The required paperwork
MinotaurGolf.ppt	action	377344	30 Oct 2004 - 22:33	JasonArold	Final Presentation ppt
MinotaurGolf.zip	action	540137	31 Oct 2004 - 02:01	BrianYoung	Final build and all data
UMLdiagram.jpg	action	181805	31 Oct 2004 - 21:59	JasonArold	UML diagram for final
users_guide.pdf	action	47864	01 Nov 2004 - 07:28	MacMason	User's Guide Rough Draft (pdf)
users_guide.tex	action	2710	01 Nov 2004 - 07:29	MacMason	User's Guide Rough Draft (TeX?)
final_report.pdf	action	54098	02 Nov 2004 - 19:38	MacMason	Final Report Rough Draft (pdf)
final_report.tex	action	2880	02 Nov 2004 - 19:39	MacMason	Final Report Rough Draft (TeX?)
tests.zip	action	2532	02 Nov 2004 - 20:48	BrianYoung	Test vault - collision cases, stress test