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.
Related
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.
I am looking for a method by which to generate 3D models for use in video games. The idea is virtual primitives that are simply points with associated data for size, shape, material and rotation.
For instance an asteroid might start as two simple spheres that intersect. Material of dusty rock which would tell the skinning algorithm to provide smooth sandy curves and occasional jagged boulders. Probably end up with a sort of lumpy peanut shape.
After that add smaller spheres with material of void or crater, peppered around the object. These would produce crater like areas in the surface of the peanut and the skin would adjust to suit. In the end you would have a semi plausible representation of an asteroid.
Now with that in mind, my question is, are there any decent open source or public domain examples of skinning algorithms that can find the surface of a model and generate a smooth, evenly distributed quad-strip mesh that could be then textured?
Some more information; I'm looking at CSG methods for the underlying models (adding and subtracting volume) then looking at other methods for remeshing the whole thing.
Skinning is an art more than a scientific process (and so almost impossible to automate) because skinning is a visual approximation of movement. To get something fully automatic, you would either have to assume bone placement or simply assume there are none at all.
Here's an example. This is an open-source project that skins automatically based on the fact that the provided mesh is a humanoid.
http://igl.ethz.ch/projects/fast/
EDIT: Wait, you mean the other way around? Isn't that similar to marching cubes? http://en.wikipedia.org/wiki/Marching_cubes
This is an exciting question and no doubt there are many ways it could be done. Personally I'd probably start by getting basic shapes on .obj format, which is easy to both parse and create programmatically, and then do exactly that in my code: tweak or randomize the the vertices you export from a modelling program to create an infinite variety of similar but slightly different objects, like asteroids. Of course if you need more than asteroids, you'd go back to a different .obj file. It's hard to say the best technique for your case since I think some experimentation would be required no matter what you try.
I've started reading into the material on Wikipedia, but I still feel like I don't really understand how a scene graph works and how it can provide benefits for a game.
What is a scene graph in the game engine development context?
Why would I want to implement one for my 2D game engine?
Does the usage of a scene graph stand as an alternative to a classic entity system with a linear entity manager?
What is a scene graph in the game
engine development context?
Well, it's some code that actively sorts your game objects in the game space in a way that makes it easy to quickly find which objects are around a point in the game space.
That way, it's easy to :
quickly find which objects are in the camera view (and send only them to the graphics cards, making rendering very fast)
quickly find objects near to the player (and apply collision checks to only those ones)
And other things. It's about allowing quick search in space. It's called "space partitioning". It's about divide and conquer.
Why would I want to implement one for
my 2D game engine?
That depends on the type of game, more precisely on the structure of your game space.
For example, a game like Zelda could not need such techniques if it's fast enough to test collision between all objects in the screen. However it can easily be really really slow, so most of the time you at least setup a scene graph (or space partition of any kind) to at least know what is around all the moving objects and test collisions only on those objects.
So, that depends. Most of the time it's required for performance reasons. But the implementation of your space partitioning is totally relative to the way your game space is structured.
Does the usage of a scene graph stand
as an alternative to a classic entity
system with a linear entity manager?
No.
Whatever way you manage your game entities' object life, the space-partition/scene-graph is there only to allow you to quickly search objects in space, no more no less. Most of the time it will be an object that will have some slots of objects, corresponding to different parts of the game space and in those slots it will be objects that are in those parts.
It can be flat (like a 2D screen divider in 2 or 4), or it can be a tree (like binary tree or quadtree, or any other kind of tree) or any other sorting structure that limits the number of operations you have to execute to get some space-related informations.
Note one thing :
In some cases, you even need different separate space partition systems for different purposes. Often a "scene graph" is about rendering so it's optimized in a way that is dependent on the player's point of view and it's purpose is to allow quick gathering of a list of objects to render to send to the graphics card. It's not really suited to perform searches of objects around another object and that makes it hard to use for precise collision detection, like when you use a physic engine. So to help, you might have a different space partition system just for physics purpose.
To give an example, I want to make a "bullet hell" game, where there is a lot of balls that the player's spaceship has to dodge in a very precise way. To achieve enough rendering and collision detection performance I need to know :
when bullets appear in the screen space
when bullets leave the screen space
when the player enters in collision with bullets
when the player enters in collision with monsters
So I recursively cut the screen that is 2D in 4 parts, that gives me a quadtree. The quadtree is updated each game tick, because everything moves constantly, so I have to keep track of each object's (spaceship, bullet, monster) position in the quadtree to know which one is in which part of the screen.
Achieving 1. is easy, just enter the bullet in the system.
To achieve 2. I kept a list of leaves in the quadtree (squared sections of the screen) that are on the border of the screen. Those leaves contain the ids/pointers of the bullets that are near the border so I just have to check that they are moving out to know if I can stop rendering them and managing collision too. (It might be bit more complex but you get the idea.)
To achieve 3 and 4. I need to retrieve the objects that are near the player's spaceship. So first I get the leaf where the player's spaceship is and I get all of the objects in it. That way I will only test the collision with the player spaceship on objects that are around it, not all objects. (It IS a bit more complex but you get the idea.)
That way I can make sure that my game will run smoothly even with thousands of bullets constantly moving.
In other types of space structure, other types of space partitioning are required. Typically, kart/auto games will have a "tunnel" scene-graph because visually the player will see only things along the road, so you just have to check where he is on the road to retrieve all visible objects around in the "tunnel".
What is a scene graph? A Scene graph contains all of the geometry of a particular scene. They are useful for representing translations, rotations and scales (along with other affine transformations) of objects relative to each other.
For instance, consider a tank (the type with tracks and a gun). Your scene may have multiple tanks, but each one be oriented and positioned differently, with each having its turret rotated to different azimuth and with a different gun elevation. Rather than figuring out exactly how the gun should be positioned for each tank, you can accumulate affine transformations as you traverse your scene graph to properly position it. It makes computation of such things much easier.
2D Scene Graphs: Use of a scene graph for 2D may be useful if your content is sufficiently complex and if your objects have a number of sub components not rigidly fixed to the larger body. Otherwise, as others have mentioned, it's probably overkill. The complexity of affine transformations in 2D is quite a bit less than in the 3D case.
Linear Entity Manager: I'm not clear on exactly what you mean by a linear entity manager, but if you are refering to just keeping track of where things are positioned in your scene, then scene graphs can make things easier if there is a high degree of spatial dependence between the various objects or sub-objects in your scene.
A scene graph is a way of organizing all objects in the environment. Usually care is taken to organize the data for efficient rendering. The graph, or tree if you like, can show ownership of sub objects. For example, at the highest level there may be a city object, under it would be many building objects, under those may be walls, furniture...
For the most part though, these are only used for 3D scenes. I would suggest not going with something that complicated for a 2D scene.
There appear to be quite a few different philosophies on the web as to what the responsebilties are of a scenegraph. People tend to put in a lot of different things like geometry, camera's, light sources, game triggers etc.
In general I would describe a scenegraph as a description of a scene and is composed of a single or multiple datastructures containing the entities present in the scene. These datastructures can be of any kind (array, tree, Composite pattern, etc) and can describe any property of the entities or any relationship between the entities in the scene.
These entities can be anything ranging from solid drawable objects to collision-meshes, camera's and lightsources.
The only real restriction I saw so far is that people recommend keeping game specific components (like game triggers) out to prevent depedency problems later on. Such things would have to be abstracted away to, say, "LogicEntity", "InvisibleEntity" or just "Entity".
Here are some common uses of and datastructures in a scenegraph.
Parent/Child relationships
The way you could use a scenegraph in a game or engine is to describe parent/child relationships between anything that has a position, be it a solid object, a camera or anything else. Such a relationship would mean that the position, scale and orientation of any child would be relative to that of its parent. This would allow you to make the camera follow the player or to have a lightsource follow a flashlight object. It would also allow you to make things like the solar system in which you can describe the position of planets relative to the sun and the position of moons relative to their planet if that is what you're making.
Also things specific to some system in your game/engine can be stored in the scenegraph. For example, as part of a physics engine you may have defined simple collision-meshes for solid objects which may have too complex geometry to test collisions on. You could put these collision-meshes (I'm sure they have another name but I forgot it:P) in your scenegraph and have them follow the objects they model.
Space-partitioning
Another possible datastructure in a scenegraph is some form of space-partitioning as stated in other answers. This would allow you to perform fast queries on the scene like clipping any object that isn't in the viewing frustum or to efficiently filter out objects that need collision checking. You can also allow client code (in case you're writing an engine) to perform custom queries for whatever purpose. That way client code doesn't have to maintain its own space-partitioning structures.
I hope I gave you, and other readers, some ideas of how you can use a scenegraph and what you could put in it. I'm sure there are alot of other ways to use a scenegraph but these are the things I came up with.
In practice, scene objects in videogames are rarely organized into a graph that is "walked" as a tree when the scene is rendered. A graphics system typically expects one big array of stuff to render, and this big array is walked linearly.
Games that require geometric parenting relationships, such as those with people holding guns or tanks with turrets, define and enforce those relationships on an as-needed basis outside of the graphics system. These relationships tend to be only one-deep, and so there is almost never a need for an arbitrarily deep tree structure.
Just learning the basics of OpenGL for a class and was looking for something challenging and interesting to try and draw. Any suggestions?
Aiming to photorealism (just plain models, lights, materials, textures, etc.) is one thing, but what is even more interesting in my opinion is demoscene and all kinds of non-photorealistic effects. The idea of a demo is to program some nice animated graphics that automatically change from one effect to another or tell some sort of a story, and have a background music. Here you can find some videos. Just take a look at what some others have done and use your imagination. That's the funniest part of 3D programming in my opinion. Of course what you'll first program would be something extremely simple when compared to those videos on youtube, but everyone has to start from somewhere. Simple also doesn't need to be ugly. Some random suggestions:
mathematical shapes with sin(), cos(), etc.
alpha blending, especially addition blending (glBlendFunc(GL_ONE, GL_ONE);)
terrain rendering
read 3d model data from a file. (Wavefront .OBJ is a relatively simple one)
feedback effects with glCopyTexImage2D, which copies pixels from screen to a texture (in real life you shouldn't use this because it's too slow, but when learning the basics it's ok)
etc...
You might consider building an OBJ viewer. You will get the experience you're looking for, and it's a pretty good project for a beginning 3D graphics programmer, in terms of difficulty.
I believe opengl has built in shapes such as a teapot that you can call and have it draw. For starters, I'd stick with easy shapes like squares, circles, and cones. Try drawing a wireframe model first since that's the easiest, by using either quadstrips ,triangles or just poly lines. After you've gotten that down, learn to set up lighting and materials so you can draw a solid model.
At school we had a very interesting assignement to get started with OpenGL that I will share. The long term goal was to modelize a living room so you basically have to draw:
A table.
Two chairs.
A carpet.
A sofa
Some stuff that you might find interesting to add on the table for
instance a TV!
When you have all the things done, try to polish the scene a little bit by adding some lighting effects!
Hint: for all the objects you simply need to start with a basic rectangle. Then you can construct your scene step by step using translations/rotations.
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!