I found this (you need Java to play with it) and since have been fascinated by cloth physics. I don't understand the logic behind the code at all though...is there any essential reading or resources for beginners?
Cloth physics is actually only spring physics, where each "point" of the cloth is connected to its immediate neighbors (usually in a square grid) by a spring.
Pulling on a point then stresses the springs surrounding that point, which stretch temporarily. As they retract, they accelerate the neighboring points, which then "pull" on their surrounding springs.
Here's another demo (demonstrating their spring library).
Look to this paper for some details.
It depends on how faithfully you want or need to represent the physics. All models represent a choice of features to include and omit.
Doing it properly means knowing a lot of physics fundamentals: continuum mechanics for large displacements and strains and a good material model for fabric. I'd recommend Malvern or Fung for the former and a literature search for the latter.
paper on mass spring system
Theres something called a mass spring system, I suggest you google it and work it out. It's basically based on beams and points. You have rectangles with points which are the corners and beams which are the lines connecting them. The points can be moved and the beams stretch but the beams can only stretch a certain amount, if they stretch too much they will break allowing the points to disconnect.
Related
I am making an adaptation of the classic Boids simulation from the 80s in Java. It works well enough, but I am trying to add a new rule to the behavior that would force the agents to avoid rectangles (walls) and I am not sure how to go about this.
I have seen this thread :
https://gamedev.stackexchange.com/questions/45381/wall-avoidance-steering
But I am confused by the syntax used (like partsList[j] -> normal) in the final code presented and how to obtain the distance between the agent and the rectangle, as well as how to actually drive the agents away. The formula makes sense though. Could someone please explain it to me? Thank you very much!
P.S. I have been following this pseudocode and I also used this Java source code as a reference.
Edit: Okay, I see why I was confused with the syntax, but I am still in the dark when it comes to writing the wall avoidance rule.
Ah, I remember the 80s, and the boids simulation…
Generally in boids-like steering behaviors the idea is to apply a behavioral “steering force” against the velocity (momentum) of the agent. So implementing any given steering behavior comes down to finding some geometric construction that generates a vector pointing in the direction you want to turn. Ideally these will be tangential steering forces (perpendicular to the current velocity) so that steering is independent of speed control.
In the case of avoiding a wall—and a rectangle can be thought of as four walls—the general idea is to take a vector pointing away from (normal to) the wall. Using projection (dot product) you can separate out the components of that force that are parallel to and perpendicular to the velocity vector. The component of the wall normal that is perpendicular to the agent’s velocity is a steering force that will turn the agent away from the wall.
The other aspect is knowing when to use this wall avoidance behavior. A useful approach is to choose a time horizon, say 2 seconds, and decide if the agent would hit the wall within that time. Using current position, velocity, and that time value, you can do a simple linear prediction of where the agent will be in 2 seconds. If it crosses the wall during that interval then it ought to be using its wall avoidance behavior.
For more information, look up “containment” in that GDC 99 paper, and/or look at these:
http://natureofcode.com/book/chapter-6-autonomous-agents/
https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732
I am currently working on a project that renders large oil-wells and sub-surface data on to the android tablet using OpenGL ES 2.0.
The data comes in from a restful call made by the client (Tablet) to the server. I need to render two types of data. One being a set of vertices where I just join all the vertices (Well rendering) and the other is the subsurface rendering where each surface has huge triangle-data associated with them.
I was able to reduce the size of the well by approximating the next point and constructing the data that is to be sent to the client. But this cannot be done to the surface data as each and every triangle is important to get the triangles joined and form the surface.
I would appreciate if you guys suggest an approach to either reduce the data from the server or to reduce the time taken to render such a huge data effectively.
the way you can handle such complex mesh really depends on the scope of your project. Unfortunately there is no much we can say based on the provided inputs and the activity itself is not an easy task.
Usually when the mesh is very complex a typical approach to make the rendering process fast is to adopt dynamic Level Of Details (in programming terminology LOD).
The idea is to render "distant" meshes with a very low LOD (and therefore having a much lower number of vertices to be rendered) and there replace the mesh with an higher resolution every time the camera approaches the mesh's details.
This is a technique very used in computer games, for instance when a terrain needs to be rendered. When the player is in a particular sector of the MAP, the mesh of that sector is in High level of detail, the others are in low detail. As soon as the player moves, the different sectors become in "high resolution" (allow me the term).
It is not an easy way to do it but it works in many many situations.
In this gamasutra article, there are plenty of information on how this technique works:
http://www.gamasutra.com/view/feature/131596/realtime_dynamic_level_of_detail_.php?print=1
The idea, in your case, would be to take the mesh provided by the web service and handle it as the HD version of the mesh. Then (particularly if the mesh is composed by different objects), apply a triangular mesh simplification algorithm to create LD meshes of the same objects. An example on the way you could proceed is well described here:
http://herakles.zcu.cz/~skala/PUBL/PUBL_2002/2002_Mesh-Simplification-ICCS2002.pdf
I hope to have helped in some way.
Cheers
Maurizio
I have been working on a voxel game for some time now, but all that I have really accomplished was the main menu and an Item system. Now its time to make the voxel engine. I have been searching for a while now to find some tutorials or an ebook that will teach me such, but the best i could find were someones tutorials in c++, but I am making mine in Java. I have dabbled in c++ and c# in the past but it was too difficult to translate i.e. it relied on a class that java doesn't have. What I know is that there are different methods for voxel engines, they all begin with rendering a single cube, and Perlin and Simplex noise can be used to randomize terrain generation.
If anyone could point me in the correct direction, most appreciated.
I will be checking back at least once a hour incase someone feels this thread is dead.
I'm not entirely sure what you are asking, if you are asking how to make simplex noise, implement it in a voxel engine or how to start making a voxel engine.
If you are asking how to start making a voxel engine I would recommend practising with quads first (2D version) and focus on getting an understanding for the theory. Once you are happy with your understanding you should focus on the voxel class (one cube) - it is very important to learn as much as you can from it, and then add more so you can optimize rendering as much as you can, such that hidden faces are not rendered and even vertices are shared, voxel engines can be the most wasteful renderers if not optimized!
EDIT:
Optimization can be done through many methods, The first and most important is hidden face removal, this involves removing the faces of voxels that are touching which will mean you will need to check of a voxel exists on any given side of any voxel before rendering that face (e.g before rendering the left face, check if there isn't a block to the left). Next is the rendering method, do not render each face or each group individually, group them so they can be rendered faster, this can be done by using display-lists or the more technical VBOs, these ensure the data is in the GPU or the data can be given to the GPU faster, For example Minecraft groups them in chunks of huge 16x16x128 groups and uses display lists. If you really want to reduce every single vertex in memory you can also consider using strip drawing methods (in OpenGL), these will require you to define certain vertices at a certain time in rendering but allow you to reuse a vertex for multiple faces.
Next would be understanding simplex noise, I can relate to there not being much material online for noise generation algorithms, unfortunately I cannot link material that I used as that was years ago. You can implement your noise algorithm in the 2D version to prove it works in a simpler environment and then copy it to the voxel version. Typical usage would be to use the values as heights in the terrain (e.g white=255 = 255 high).
I would recommend using Unity. The engine is already made and you can add menus and titles with just a few lines of code. All of the game creation is either in C# or Javascript which shouldn't be any huge change from C++. Good luck!
I need to write a very simple 3D physics simulator in Java, cube and spheres bumping into each other, not much more. I've never did anything like that, where should I start? Any documentation on how it is done? any libraries I could re-use?
Physics for Game Programmers By Grant Palmer (not Java)
Phys2D (Java code)
Assuming you want to get started on how to do it, best way to start is with a Pen and Paper. Start defining focal points of your app (like the entities sphere, cube etc, rules like gravity, collision etc, decide hierarchy of objects etc..)
If you know how to do this, and want a primer on the technology side, Swing is a good option to make UIs in Java.
Also take a look here: http://www.myphysicslab.com/
NeHe's lesson 39 is a good starting point, it's in C++ but the theory is pretty easy to understand.
A nice java physics library is jmephysics (http://www.jmonkeyengine.com/jmeforum/index.php?topic=6459); it is quite easy to use and sits on top of ODE (http://www.ode.org/) and jmonkeyengine (http://www.jmonkeyengine.com) which gives you a scenegraph (http://en.wikipedia.org/wiki/Scene_graph), again something that you'll need for anything beyond a very simple 3d application.
I haven't used it for some time though, and see that they haven't released since late 2007 so not sure how active the community is now.
How about first defining a class for physical object? It has position, velocity, mass and maybe subclasses with other features like shape, elasticity etc.
Then create an universe (class) where to place these physical objects. Sounds like fun :)
If you all you need to simulate is spheres/circles and cubes then all you need is a bit of Vector math.
Eg to simulate a simple pool game each ball (sphere) would have a position, 3d linear velocity and 3d linear acceleration vector. Your simulation would involve many little frames which continually updates each and every ball. If two or more balls collide you simply sum the vectors and calculate the new velocities for all balls. If a ball hits a wall for instance all that is required is to flip the sign of the ball to have it bounce back...
If you want to do this from scratch, meaning coding your own physics engine, you'll have to know the ins and outs of the math behind to accomplish this. If you have a fairly good math background you'll have a headstart otherwise a steep learning curve is ahead.
You can start on this community forum to gather information on how things are done:
gamedev.net
Ofcourse you could use an opensource engine like Ogre if you don't want to code your own.
Check out bulletphysics. bulletphysics.com is the forum or check out the project on Sourceforge.
What should a small team choose for their first game, when they are low on time but have big ambitions? I'm an experienced programmer, but haven't done any game programming before this. My designer is very talented and artistic, he has worked with 3D about an year ago but hasn't done it since so it could take him some time to learn it again, and i'm not sure if he'll be able to do a good job at it even though his graphic design skills are terrific otherwise.
Our primary concern is to get the game finished as quickly as possible, and also to do it easily since this is my first game programming project. At the same time, we don't want to have any limitations that might hinder our progress later on, or otherwise make the game not fun in certain ways.
For example, i learnt that certain animations aren't possible in 2D such as rotation etc. I would like the ability to have the player's character be able to morph into animals and there must be the ability to shoot at the monsters, (like shooting an arrow and seeing it fly through and hit the other person). Are these things possible in 2D?
In the future, if we wanted to go from 3D to 2D, would it be possible without fully rewriting the game?
You don't have to use 3D to allow for a "3D look". Things like rotations, motions or transformations can be prerecorded or prerendered as animations or image sequences and seamlessly integrated into a 2D game.
The only thing that is not possible in 2D is to navigate freely within your "game space" (like walking or flying freely, turning arbitrarily etc.)
The main concern, however, when deciding for 2D or 3D should be the gameplay. There are games that absolutely need 3D (shooters, simulations), while others do perfectly without (adventures, puzzles, ...). So you don't actually have to decide but to choose the better fit for your game idea.
Personally, I'd avoid using 3D in your first game attempt if possible to eliminate all the constraints and hassles that come with it.
When using 3D you typically have to decide for a 3D framework which will heavily influence your software design, game look and feel and overall performance. Java3D for example brings a complicated class structure that you have to adjust to.
And a lot of effort goes into making that 3D stuff work at all. Simple things like rotating a square evolve into matrix operations incorporating quaternions. Every effect has to be done in the complex 3D world, and in such a way that its 2D projected look turns out the way you intended it.
Not to mention that 3D applications often suffer a very stereotypical look that is very hard to overcome.
In 2D, you literally avoid one dimension of complexity. You do everything exactly the way it is supposed to look, you can use standard graphic applications and open file formats to simplify the workflow between the designer and the developer. And a lot of pseudo-3D effects like parallax motion, depth of field and prerendered artwork allow for astonishing looks in a 2D world.
You should go 2D. You have stated several reasons to take this approach:
You are a small team, and 3D takes
more work.
It's your first game, so
you need to keep it as simple as
possible, or the project may fail
(you are exposed to a lot of risk!)
The 3D artist needs to relearn the
crafts!
You have a (seemingly
self-imposed) deadline.
Etc.
3D takes a lot of time, and it will be best invested in improving the rest of the game. Think of all the awesome games that existed previous to the 3D era.
Do not fear to accept restrictions: whilst 3D might give you lots of possibilities, 2D may result in more creative work!
I would considre a couple of factors:
Is it a mobile or applet game? If so, I would go for the 2D version. It's very hard to get 3D right under those circumstances.
What is your designer more comfortable with? Can he more quickly model, texture and animate a characte, rather than creating all the sprites needed for a 2D character?
Tool support. What output formats can your designer produce in both 2D and 3D? What kind of formats is the middle ware, you are going to use, able to handle? Can your 3D engine load, or at least convert, .obj files (just an example, could have used any other model format.)?
Even if you would like to go the 3D way, you can still make a 2D game (sometimes called 2.5D or pseudo 3D). Also there are some nice third party frameworks out there for both 2D and 3D stuff in Java. You don't have to use java2D/java3D.
Given your requirements, I'd choose 2D . You have more tools to choose from . more available talent to contract for artwork .. and the asset pipeline is simpler. In the end it's going to be all about how good the game is on its own merits. 3D is sometimes more difficult for your average user to figure out.
Depending on what you are conceptualizing, rotations and morphing oughta be quite possible in 2D. You might even consider a pseudo-3d approach ala Paper Mario ..
Moving from 2D to 3D should not be a major issue if you design your code structure with that in mind. ..
I would recommend 2D as well. A 3D game will be more graphically demanding on the user's computer, and many things like collision detection are significantly simpler in 2D. You could even make your character models in 3D and then project them down to 2D to make the sprites for the actual game. Puzzle Pirates (http://www.puzzlepirates.com/) takes this approach and it works very well in terms of consistent lighting, etc.
I think writing a 2D or a full 3D game needs a completely different design approach what cannot be modified easily later: SUN provides a Java 2D API and a Java 3D API for the two development decisions.
For the first game with tight deadline I would vote for a 2D version. If the gameplay is interesting and the design is nice then the 3D is not a must.