I'm currently in the process of developing a very basic 3D OpenGL game in C++ as part of a small college project. We don't get a lot of insight from the teachers however, and only very limited documentation, as well as a small timeframe, so I'm kind of a little lost here at the moment.
My game is a tank battle on an orthogonal plane that pretty much looks exactly like the image I sketched below. Each tank (A and B) can be controlled by a different player, and each one can shoot projectiles, which are supposed to influence the other tank's score upon collision.
My question is, what would be the simplest way of effectively implementing collisions for the tanks? (Tank vs tank, tank vs map boundaries and tank vs any kind of parallelepipedic object like the one in the center of the picture - and the same thing but applied to the projectiles shot from the tank turrets).
Ideally, without the need of using an external physics engine, but also accepted if the implementation can be done easily. At the moment, I'm solely using the GLUT library.
Download and integrate Box2D (http://box2d.org) into your project.
Unless your project is to implement a physics engine, then don't bother doing it yourself. Your time will be much better spent learning how to integratate libraries and how proper physics engines work.
You can then easily use a box collider for your tanks, circle for projectiles and 4 lines for your perimeter. You can create callbacks to notify you when a projectile has collided with another tank.
You will have to use forces and torques to move and rotate your tanks, rather than just updating their positions. But you would probably have to do that anyway if you were going to implement the physics yourself.
Actually, I'm currently working on a simple project to detect collision between 2 specific objects in a surgery scene. The problem is that I don't have background on such problems so I'm really newbie to such things and I don't know yet what to do. After a little bit of research, I found Bullet library which can be used as a collision detection tool but not sure yet if it suits my case. I already checked some examples where the developer create the objects of interest manually which led me to think that I should detect first the objects of interest then launch the collision detection process.
In my case, I have 2 types of data:
Video shooting the operating room
Cloud points representing the room in 3D
I need to detect the collision between two objects in the scene. Is there any way to use Bullet to achieve such thing? Is it common to use a video as input for a detection collision problem(I'm wondering since I could find too much resources on it)?
I'm just starting so it might be a fuzzy question so sorry in advance for any inconveniences.
EDITED:
I already checked it but my point was to understand what options can be used before digging into the details. For me, a collision detection problem should have 2 parts: the objects of interest (The 2 or more objects that we're trying to detect their collision) and the scene in which we will be trying to detect the collision of the objects of interest. For the scene, the data I have is presented in 2 types mentioned above. So, I was asking about which type of data should be used as input for bullet collision process. Should it be an image taken from the video or should it be a list of 3D points? Or something else?
I have used Bullet half a year ago. I remember, that you need to register objects to Bullet with a collision shape. In simplistic case of your points, it could probably be small spheres. In case of your video, you need to have a 3d representation. I do not understand a 100% what you mean by detecting a "video" for collisions. However, to use Bullet, you need to have a collision shape associated with the object.
Further, you register a Collision Callback. This is one function called for each collision detected. All callbacks are listed here: http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Collision_Callbacks_and_Triggers
As the wiki says - and I implemented it this way - to detect a specific collision, you need to iterate over allr esulting manifolds from Bullet manually. A little bit painful and performance wise strange approach. So you cannot register a specific callback for a specific object with another specific object!
Once the objects are registered, you run the algorithm and then you can check all manifolds in the callback.
To get started with Bullet, I used Bullet Physics Simplest Collision Example with the answers at that time.
I'm interested in trying to create realistic fluids (water), for a 2D game. This game is similar to Terraria. I have heard about how you can slap a bunch of colliding particles on the scene and render over it and voila, realistic acting water.
Terraria uses tile based water, which I am not a fan of.. I want something more advanced.
I thought about using bullet 3D physics (box2d has limits I would hit). For non colliding particle effects, I am thinking about using something like SPARK, since I think that'd give me the best of both worlds.
The issue I am thinking about, is that each block is 16x16, so on a 1600x900 scene, there are about 5 thousand tiles.
So I need to tell the physics engine that these tiles are collidable. Of course, there are void tiles that are considered to be non collidable.
Does anyone have ideas on this? Language is C++, I doubt that's relevant though.
EDIT: i think i'm going to have to cave in and use grid based water. I suppose, in retrospect particle based just makes everything more difficult but for what gain?
Your question is about tiled fluids, but you seem to actually be asking about a particle based approach.
If that's the case, what you're looking for is "Smoothed Particle Hydrodynamics", or SPH, which is a very popular technique for 2D and 3D fluid simulations in realtime situations.
Yes, it's basically just a particle system, with each particle responding to the forces in your environment (gravity, collisions etc.) in a reasonable (mathematically stable) way, combined with a constraint that they must stay a certain distance apart in order that the fluid is incompressible.
You can render the particles as points, if you have enough of them, or you can use them as a source for deriving a surface (for example using marching-cubes, though in 2D I wouldn't worry about that).
http://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics
It has the advantage of being relatively easy to code, and indeed to accelerate on a GPU.
Indeed I think they're probably a better approach than trying some kind of tile-based approach, and you get some more interesting results, such as spray kicking up, waves kicking against the edges of objects, etc. It's not too hard to get something pleasing working, I'd give it a go.
I have integrated box2d in my engine, ( Debug Draw, etc. ) and with a world I can throw in some 2d squares/rectangles etc.
I saw this post, where the user is basically not using a world for collision detection, however the user doesn't explain anything about how he's using the manifold (b2Manifold), etc.
Another post, is in the cocos2d forum, ( scroll down to the user Lam in the third reply )
Could anyone help me a bit with this?, basically want to add collision detection without the need of using b2World ,etc etc.
Thanks a lot!
Is there any reason you can't use a b2World? Just because you use it, doesn't mean you have to use the physics simulations, unless you're severely performance limited.
See this example on using Box2D for collision only in Cocos2d. Maybe you can apply something similar to your project: http://www.raywenderlich.com/606/how-to-use-box2d-for-just-collision-detection-with-cocos2d-iphone
The code in both of those posts seems complete to me. You begin with two polygon shapes and their corresponding transforms and from b2CollidePolygons you get back a contact manifold.
The b2Manifold is just a collection of points at which the two shapes' boundaries intersect. In the posted code the author uses that if the manifold's point count is greater than zero there is an overlap. Depending on the nature of the shapes there can be different number of intersection points when they overlap.
Note that the collision handling of the b2World is quite robust. Beyond simple collision queries it has broad-phase culling, ray-casting, a spatial tree, begin-contact and end-contact events, efficient memory management to name some things. There are classes in the API for most of these tasks but I can't say I'm familiar with using them manually. Could be worth a look.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm looking for some good ideas for a simple 3d graphics program as my final project for an intro to computer graphics class. As for some background information, we'll be using opengl and will have a little over a month to work on it, so nothing too far-fetched. The simpler and "prettier" looking, the better. It does, however, require some sort of interface that the user can interact with (so a very simple game or similar is a good idea) and must be 3D.
My only idea so far is maybe a 3D version of Tetris (google for some examples).
Edit: I ended up going with 3D Tetris. For a less than a month's worth of time, you can see what I came up with here.
A 3D text/code editor. Text is 3D, errors stand out, code indentations not only indent, but protrude on z axis, pages/files are 3D and can be flipped like a ringpad.
Probably not useful, but fun and more interesting than a game IMO.
In university, for my parallel programming course, I did an openGL/MPI implementation of Conway's Game of Life. It was quite interesting. Wish I still had the code around somewhere. The advantage of using open GL is that you can lay out the grid in different orientations rather than a flat grid. Remember, code doesn't exist until it's checked into source control.
Putting some physics in makes it more interesting. How about implementing Labyrinth (the maze toy where you are supposed to guide a ball from the starting point to the goal by tilting it).
EDIT: Erik told me it's called Labyrinth.
A 3D minesweeper game similar to this one.
Rubik's cube.
Look at http://www.contextfreeart.org/ ... write something similar, but for 3d.
If you've ever played Missile Command I belive that this could be a good project to '3d-ify'.
Try a chicken crossing the road game.
You will probably need to demonstrate the bare minimum of:
textures
lighting
animation
interaction
collision detection
Do not include even simple physics if there are no marks for it. Prioritise tasks based on the marking scheme. Get something simple working first and back it up :)
Honestly it's actually pretty easy to load up a bunch of animated models and set up a simple first person shooter. I mean, to get a generic thing working you don't need all that much:
Either load and display a heightmap or a BSP tree as the level.
Load and render some simple MD2 models (keyframe animation, low amount of polys and simple format).
Draw a simple hud.
Ray/AABB intersection, every time the user clicks you'll need to cast a ray from the center of the screen and see if it intersects an the bounding boxes of the enemies.
Simple FPS camera system.
The above is pretty doable in a month for as far as I'm concerned. (It's probably doable in a week if you already know some of the stuff).
I tried to do a 3D Asteroids for a class once. I never completed the gameplay part, since it was a graphics class. The ship could move around, as could the asteroids, but there was no collision detection. The ship and the asteroids had 3D textures applied to them, and the asteroids were built out of ellipsoids, so they were actually 3D. The gameplay was all 2D, though.
How about one of those games that are a wooden maze with a ball rolling around the top. You tilt the board and try to get the ball round the maze without falling down the hole? It has the advantage that it's relatively simple to get started, but you could probably think of some extensions if you have time.
If you're looking for a true university size task, mine was to produce a small helicopter "game" where you could take off from an aircraft carrier in an ocean and fly around with some environmental effects, moving water etc. i.e. nothing too complicated. As another example, the task set for the year previous to mine was a little sans-opponent racing game.
I would worry that you may loose marks with tetris as it sounds like little would be done on the z-axis and may come across a little too 2d though it obviously depends on your brief.
Anyway, these will give you the chance to experiment with the basic OpenGL features such as fog, lighting, geometry, textures and some basic movement physics & collision detection/response.
Further on this, though often beyond the scope of such a university sized task you could then take this further add nicities such as animated geometry (e.g. people), environment mapping, reflections, shadows, particle systems, shaders, perhaps a heightmapped island.
Rewrite Blocks 3D. The graphics on this project look horrible now. I remember playing this game (or one like it) on a 386 with wireframe graphics... awesome. The game is basically 3D tetris.
I would check Panda3D or Pygame.
Panda3D is probably close to what you are looking for, and one idea that always works is to put the user's face in the main character or object. 3d-pong with the player's face? Use something unexpected... like a tetris made of burgers instead of bricks.
I love little self-organising alife applications like boids. They can be fun to code and always benefit from a nice UI, especially 3D ones. User input can modify aspects of the environment as well as moving around/through the environment.
I like exoplanets. Go read up on them. On Wikipedia and http://exoplanet.eu there's a lot of information. Astronomers and public outreach people could always use fresh 3D animations showing how the Doppler effect works, or how the planet transiting in front of the star makes it for example 0.5% dimmer.
Or, what I work on, is how when the planet passes behind its star. At Earth we receive just a teeny bit less infrared from that star. The user could adjust the orbit, size of planet, etc. and see how that affects what astronomers see. It could be fun, simple enough to do, and unlimited potential in extending the work for nicer textures, slick lighting effects, etc., and you could end up with something to contribute to science education.
I'd be making such 3D animations myself, if I weren't busy helping crunch numbers for the actual science. I'll be jealous!