How would I go about modeling a turgid bag of fluid in Box 2D, i.e. what physics equations would be useful in modeling this? The bag of water could move when touched, but that is the only interaction. Any places equations or models would be much appreciated!
You could use a library for this. Google's LiquidFun is quite good http://google.github.io/liquidfun/
User99345's answer is the way I'd go to model a bag of liquid, but if you're wanting to use an unmodified Box2D library you can model it using instances of b2EdgeShape, b2RevoluteJoint, and b2CircleShape. Whether that's a good enough way to model it, you'll have to decide.
Additional basis/insight for this...
After seeing your question I put together a model for a bag of liquid as a Testbed demo in my dev branch of my fork of Box2D. The demo is called "Bag of Disks" because that's basically what the demo models and it's in the file BagOfDisks.hpp. The code uses a series of edge shapes connected by revolute joints to model a deformable container and fills it with circle shapes (called DiskShape in my fork) to model a liquid. If you build the library and Testbed of my fork you can see for yourself how the model looks.
As a model of a bag of liquid, I'm of the opinion that the code I whipped together has shortcomings like the following:
It must be computationally less efficient than using particle simulation like Google's LiquidFun does.
I don't believe joints as currently implemented in Box2D (or my fork of it), can always ensure containment. That's because I don't believe joints are able to 100% prevent alternative movement of the connected shapes.
The "bag" in the demo doesn't level evenly at it's top like I'd expect a normal bag of liquid to do.
The "bag" doesn't model a buoyancy force that I'd expect the top of a bag to do.
I imagine things can be done from a user level to improve the model's behavior but I suspect less can be done from a user level to improve the model's speed. By user level, I mean as a user of the Box2D library.
While my fork has made many changes to the Box2D library (especially in naming), I don't believe what I've done in the demo itself can't be reproduced pretty closely using the original Box2D library and syntax as I'd said in my first paragraph using instances of b2EdgeShape, b2RevoluteJoint, and b2CircleShape.
As to what physics equations would be useful in modeling this beyond the equations that Box2D already uses, I'm sorry to say that I have no idea at the moment. I am interested in that however and am looking into it as well. Physics equations for this are available of course but the closest related work that I'm aware of from a Box2D user level is what iforce2d put together in his Buoyancy web page.
Hope this answer contributes helpfully to what's already been said.
Related
So in the beginner coding classes I teach, they've (the district) moved us away from the Graphics library with java.awt.* and java.swing.* to the simplified standard graphics library, StdDraw -- not necessarily a bad thing as it has most of the bells and whistles that my students need and we only really use it for one chapter and then its an option for a later project if they feel more artsy that analytical. It also more closely mirrors the coordinate system they're using in math classes and logically makes more sense to them defining center pionts to draw instead of corners.
One of the things I really wish it had was the ability to draw sectors/wedges/slices of circles. It does arcs (the portions of a circumference), but especially for the graphical [pie] charts, it's quite essential. For the moment they're just coloring the arcs and we're going on with the lessons. But for NEXT year, I'm hoping I can edit something into the library ahead of time and let them use it traditionally without going against the other teachers across the (large) district and utilizing two graphical libraries "StdDraw" and "g" or being the lone one who uses g entirely.
Most results online suggest migrating to the g-library, my only hesitation was the explicit move away from that for the younger students. More advanced, older may still use it, but I don't teach them. A decent Google, reddit and stackoverflow search didn't return anything that I could just plug into the StdDraw library so wondering if you have any suggestions or work-arounds?
I am working on a game scene with multiple objects that need multiple materials. I extensively searched online, but I could not find any satisfactory solution.
My scene will have like a river flowing by and the material there will require a separate shader anyway (it will combine many specular and normal maps into what would look like a river) then there is a terrain that would mix two (grass and sand textures) requiring another shader. There is also a player with hands and amour and all.
EDIT: Essentially I wish to find out the most efficient way of making the most flexible multiple material/shader implementation.
Briefly, there is a lot of complex objects around requiring varied shaders. They are not many in number, but there is a lot of complexity.
So using glUseProgram() a lot of times dosn't seem like the brightest idea. Also Much of the shader code could be made univeral like point light calculation. Making a generic shader and using if's and state uniforms could possibly work, still requiring different shaders for the river and likewise diverging materials.
I basically don't understand the organization and implementation of such a generic system. I have used engines like Unreal or possibly Blender which use Node based materials and allowing the customization of every single material without much lag. How would such a system translate into base GPU code?
If you really face timing problems because of too many glUseProgram() calls, you might want to have a look at shader subroutines and use less but bigger programs. Before that, sort your data to change states only when needed (sort per shader then per material for example). I guess this is always a good practice anyway.
Honestly, I do not think your timing problems come from the use of too many programs. You might for example want to use frustum culling (to avoid sending geometry to the GPU that will be culled) and early z-culling (to avoid complex lighting computations for fragments that will be overriden). You can also use level of detail for complex geometries that are far away, thus do not need as much details.
I'm creating a game along the lines of Minicraft. I posted a question about how I should make a terrain similar to the one in the game here and user by the name of Quirliom posted an answer referring to what is called cellular automata.
I had absolutely no clue what it was, let alone how to do it. I did look it up and see what it was. But I have yet to find out how to do it. Could somebody please explain how to do it and how it works, perhaps a link or two or even some source codes/ examples.
For the theory, check out http://en.wikipedia.org/wiki/Book:Cellular_Automata. Once you have a sense of what cellular automata are in general, the next step is finding sources on their application to landscape generation (a pretty non-standard but not unheard of use); I suspect the initial theory readthrough will give you a pretty good sense on implementation techniques.
Formally, cellular automata are a subclass of dynamical system where space and time are discrete.
Depending on the model considered, some properties may or may not apply:
The component of the model are connected by a regular graph that is invariant by translation, rotation, etc.
Given S the state space, the updating rule is a function F(S^n) -> S where S^n is given by the neighborhood of a cell.
The updating rule is the same for all component.
The updating rule apply to all cells simultaneously, building states t+1 from states t.
Generally, cellular automata are good models to simulate a dynamical environment (sand, brownian motion, wildfires) because they allow large size and computation speed, due to their extreme simplicity.
If you want an entry in the world of cellular automata, I recommend you look up the Game of Life by Conway, find a tutorial and implement it.
I am currently working on a 3D engine in java and have run across a few problems. Such as, a reliable way to create 3D (or 2D or 1D) geometry in a reliable, simplistic way. Of course, there is no real, straight-forward answer for this, but I'm mainly anticipating this to be a discussion-type-post.. But, nonetheless, I'm looking for a simple, yet reliable way to instantiate geometry in my 3D engine.
(As an example of what exactly it is that I mean, I currently have everything being composed of 3D points (as it is in reality), but telling the engine what the points compose is a difficult task, making it hard to get reliable geometry. I need a more reliable system rather than just using many many points.)
Yay discussion-type question -- first off, just a warning, discussion-type questions tend to be frowned upon at stackoverflow, but I'll pitch in nonetheless:
The first thing that popped into my mind was the Half-edge Mesh Datastructure -- a simple, and powerful-enough-for-everything-I've-needed-so-far structure -- with almost no space-wise superfluous data. This would cover basically all of your mesh structure needs.
Another solution which you'll find in many 3D game engines is the object-tree system (I'm not sure whether that is the correct name), which you;ll find in action in the python panda3D game engine, Blender (kinda, not that familiar with blender), and so on and so forth. The idea is to have a simple Object3D class, which can contain other Object3D objects at relative positions within. This nested hierarchy works very well with complex systems, where parts come together to form more complex parts of other things. This nested hierarchy also lends itself very well to recursive O(log n) collision algorithms, and recursive frustum culling (for graphics). This is also very easy to code -- I wrote a basic 3D engine using object trees in 11th grade, and let's just say I wasn't exactly a MENSA member back in the day.
In any engine, we'd need some way to compute intersections and so on, so we can do frustum culling, physics collisions, and so on and so forth. The trick I used (very efficient, and just intelligent enough), was the AABB tree -- if we already have trees of objects, we simply let every object store & compute its AABB, and hey presto! AABB tree.
Anyways, you say, since I've some experience writing some code like this I must be able to provide samples, right? Yes:
public class Object3D {
public LinkedList<Object3D> children;
public AABB aabb; // the AABB of the object -- constructed
// by union of children's AABBs
public void doesIntersect(Object3D obj){
// intersection using AABB-AABB intersection
// sadly web resources are sorely lacking, so I shall handle this one below
}
}
On AAABB-AABB collisions (if you need to know)
We have two boxes. Each box is aligned with the axes, and each box has a width, height, and depth. To test if they collide, we see whether they overlap when looking along all three axes -- after all, if they don't overlap when we look along even one axis, they can't possibly be colliding. Some fancy math later, we note that:
"Box A and Box B collide" iff "Box A and B have overlapping x coordinates" and
"same for y coordinates" and "same for z coordinates" and
"same for any other dimensions of space you decide to implement".
As it turns out, this is a trivial check, both to code and to compute, which is why AABBs make good bounding volumes for object trees.
Well, for a discussion this answer has gotten rather one-sided. Anyways, comments would be lovely, I'm sure there are some useful things I've missed (verlet integration, raytracing, but all of those are easy on a base as described above)
I am trying to create a Java package that can be used to write simulation programs.
My goal is to create 'objects' like springs or solid objects like cubes and spheres. They will have mass, velocity, gravity etc. and they can interact with each other.
I have seen some simulation programs on www.myphysicslab.com but my problem is that I don't want to write different equations for different senarios. Is there any way to do this? I am new to programming.
Creating a physics engine is hard. (Very hard). But it can also be a lot of fun. Well, fun in a "why am I doing this to myself?" kind of way.
Assuming your have a fair grasp of the maths involved*, and assuming you're interested in Rigid Body Dynamics there are a couple of classic references to start with:
First of all Chris Hecker's Rigid Body Dynamics tutorials
And of course Witkin and Baraff's SIGGRAPH course
Those are good places to start and will provide more than enough of a challenge for you.
You could also look at Box2D by Erin Catto and his associated GDC tutorials which you can download.
For more specific help, the forums for Bullet also contain a sub-section where you can discuss and ask questions once you have understood some of the basics.
*If you don't have this fair grasp, learn. If you're not willing to, don't try and just use an existing engine. If this is your very first programming experience, just focus on the programming first. Don't get yourself overwhelmed.
Good luck.
To understand physics, you must first understand maths. Attempting to write a physics engine without using mathematical equations is like making a cake without ingredients.
Entire careers are built on creating physics engines, so my advice is to either use an existing engine, or get your books out.
Building a physics simulator can be a lot of work. Two dimensions is considerably simpler than three, so maybe you want to start with 2D. You might want to begin with an existing package like JBox2D. It has a constraint solver, friction, etc. You can build on top of JBox2D or study how it works.
An HTML5 version is available with online demos: GWTBox2D
There is a program called Easy Java Simulations
that does exactly what you want!
You can create java applets and has many of the visual objects ready.
You can also write java code and subprograms.
visit http://fem.um.es/Ejs/ to download.