I was wondering how to implement a fast rendering technique for my Game-Engine and frustrum culling is the best technique but I don't understand how it works could someone explain me how it works (most vidéo explaining how it works are for 3D while I'm look for 2D)
Related
This is entirely a theoretical question because I understand the time it would take to do such a thing would be ridiculous
I've been working with "voxels" a lot lately and the only way I can display them to a user is to either triangulate the visible surfaces or make a CPU ray-tracer but both come with their own problems.
Simply put, if we dismiss the storage space needed for voxel meshs and targeted a very specific GPU would someone who was wanting to create a graphics API like OpenGL but with "true" voxel primitives that don't need to be converted be able to make such thing or are GPUs designed specifically for triangles with no way to introduce a new base primitive?
Its possible and it was already done many times
games like Minecraft,SpaceEngineers...
3D printing tools and slicers
MRI/PET scans tools
Yes rendering on GPU is possible with the two base methods you mention. Games usually use the transform to boundary representation 3D geometry. With rise of shaders even ray tracers are now possible here mine:
simple GLSL voxel ray tracer
using native OpenGL architecture and passing geometry as 3D texture. In order to obtain speed you need to add BVH or similar spatial subdivision of geometry...
However voxel based tools have been here for quite some time. For example many isometric games/engines are voxel based (tile is a voxel) like this one:
Improving performance of click detection on a staggered column isometric grid
Also do you remember UFO ? It was playable on x286 and it was also "voxel/tile" based isometric.
I am trying to model a simple 2D beam on elastic foundation in Abaqus. How to do this in ABAQUS? Any ideas or help?
Here are a few suggestions:
Model the beam as simple 2D QUAD elements.
See if ABAQUS has any infinite elements to model the foundation. If not, you'll have to discretize a large body that exhibits the "foundation" behavior (e.g. asymptotic Laplace like behavior far away from the surface).
Depending on the physics you want to capture, you'll have contact and friction defined along the contact surface between the foundation and the beam. These will make your problem non-linear and harder to solve, but may be more faithful to the physics you're trying to model. It'll allow gaps between the beam and the foundation.
I'm so glad to see so many ABAQUS questions here. No MSC, MARC, Ansys? From this perspective, HKS has 100% market share.
I have to develop an app that has to present a "floor" of hexagons in "The Sims" style, something like this, but simpler.
I really know little or nothing about CoreGraphics and absolutely nothing about OpenGL, which way you would use to do the job in a "easy" and "quick" way?
There are myriad ways to achieve this. As I read it, you're looking for a 2D perspective, which thankfully is far more accessible for anyone without experience with 3D rendering. You could explore the use of a 3rd party library as sch suggested.
If you wanted a "native" solution, your options are going to be either something CG based or something image/UIKit based. Both are relatively accessible.
With Quartz/CG, essentially you will draw series of lines and arcs to compose the shapes you want. I generally create sketches on paper, then kind of plot out the rough segments and components I need in code; it's really not very hard to draw the paths with CG commands. You can build a shape-factory class pretty easily, and then you can just ask that for a given shape in a given size when it comes time to drop a shape into your view.
If you're reluctant to draw the paths in code, your last option is to use UIKit. With this approach, you could create your shapes in photoshop, slice them into images, then place those into imageviews and into your app. You can then manipulate these images in 2.5d space using CALayer transforms. If your needs are modest, this is a relatively easy and simple way to do it and have it look decent. Unfortunately this approach is not highly dynamic, wouldn't scale well, and may simply not meet with the performance threshold you're looking for on-screen.
You should have a look at Cocos2D. It makes programming games like that much easier. It also supports tile maps, that you can use to create the floor.
Try using CATransform3D to apply perspective to your 2D views. Related Question: How do I apply perspective?
The definition of rigid body in Box2d is
A chunk of matter that is so strong
that the distance between any two bits
of matter on the chunk is completely
constant.
And this is exactly what i don't want as i would like to make 2D (maybe 3D eventually), elastic, deformable, breakable, and even sticky bodies.
What I'm hoping to get out of this community are resources that teach me the math behind how objects bend, break and interact. I don't care about the molecular or chemical properties of these objects, and often this is all I find when I try to search for how to calculate what a piece of wood, metal, rubber, goo, liquid, organic material, etc. might look like after a force is applied to it.
Also, I'm a very visual person, so diagrams and such are EXTREMELY HELPFUL for me.
================================================================================
Ignore these questions, they're old, and I'm only keeping them here for contextual purposes
1.Are there any simple 2D soft-body physics engines out there like this?
preferably free or opensource?
2.If not would it be possible to make my own without spending years on it?
3.Could i use existing engines like bullet and box2d as a start and simply transform their code, or would this just lead to more problems later, considering my 1 year of programming experience and bullet being 3D?
4.Finally, if i were to transform another library, would it be the best change box2D's already 2d code, Bullet's already soft code, or mixing both's source code?
Thanks!
(1) Both Bullet and PhysX have support for deformable objects in some capacity. Bullet is open source and PhysX is free to use. They both have ports for windows, mac, linux and all the major consoles.
(2) You could hack something together if you really know what you are doing, and it might even work. However, there will probably be bugs unless you have a damn good understanding of how Box2D's sequential impulse constraint solver works and what types of measures are going to be necessary to keep your system stable. That said, there are many ways to get deformable objects working with minimal fuss within a game-like environment. The first option is to take a second (or higher) order approximation of the deformation. This lets you deal with deformations in much the same way as you deal with rigid motions, only now you have a few extra degrees of freedom. See for example the following paper:
http://www.matthiasmueller.info/publications/MeshlessDeformations_SIG05.pdf
A second method is pressure soft bodies, which basically model the body as a set of particles with some distance constraints and pressure forces. This is what both PhysX and Bullet do, and it is a pretty standard technique by now (for example, Gish used it):
http://citeseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.4.2828%26rep%3Drep1%26type%3Dpdf
If you google around, you can find lots of tutorials on implementing it, but I can't vouch for their quality. Finally, there has been a more recent push to trying to do deformable objects the `right' way using realistic elastic models and finite element type approaches. This is still an area of active research, so it is not for the faint of heart. For example, you could look at any number of the papers in this year's SIGGRAPH proceedings:
http://kesen.realtimerendering.com/sig2011.html
(3) Probably not. Though there are certain 2D style games that can work with a 3D physics engine (for example top down type games) for special effects.
(4) Based on what I just said, you should probably know the answer by now. If you are the adventurous sort and got some time to kill and the will to learn, then I say go for it! Of course it will be hard at first, but like anything it gets easier over time. Plus, learning new stuff is lots of fun!
On the other hand, if you just want results now, then don't do it. It will take a lot of time, and you will probably fail (a lot). If you just want to make games, then stick to the existing libraries and build on whatever abstractions it provides you.
Quick and partial answer:
rigid body are easy to model due to their property (you can use physic tools, like "Torseur+ (link on french on wikipedia, english equivalent points to screw theory) to modelate forces applying at any point in your element.
in comparison, non-solid elements move from almost solid (think very hard rubber : it can move but is almost solid) to almost liquid (think very soft ruber, latex). Meaning that dynamical properties applying to that knd of objects are much complex and depend of the nature of the object
Take the example of a spring : it's easy to model independantly (f=k.x), but creating a generic tool able to model that specific case is a nightmare (especially if you think of corner cases : extension is not infinite, compression reaches a lower point, material is non linear...)
as far as I know, when dealing with "elastic" materials, people do their own modelisation for their own purpose (a generic one does not exist)
now the answers:
Probably not, not that I know at least
not easily, see previously why
Unless you got high level background in elastic materials, I fear it's gonna be painful
Hope this helped
Some specific cases such as deformable balls can be simulated pretty well using spring-joint bodies:
Here is an implementation example with cocos2d: http://2sa-studio.blogspot.com/2014/05/soft-bodies-with-cocos2d-v3.html
Depending on the complexity of the deformable objects that you need, you might be able to emulate them using box2d, constraining rigid bodies with joints or springs. I did it in the past using a box2d clone for xna (farseer) and it worked nicely. Hope this helps.
The physics of your question breaks down into two different topics:
Inelastic Collisions: The math here is easy, and you could write a pretty decent library yourself without too much work for 2D points/balls. (And with more work, you could learn the physics for extended bodies.)
Materials Bending and Breaking: This will be hard. In general, you will have to model many of the topics in Mechanical Engineering:
Continuum Mechanics
Structural Analysis
Failure Analysis
Stress Analysis
Strain Analysis
I am not being glib. Modeling the bending and breaking of materials is, in general, a very detailed and varied topic. It will take a long time. And the only way to succeed will be to understand the science well enough that you can make clever shortcuts in limiting the scope of the science you need to model in your game.
However, the other half of your problem (modeling Inelastic Collisions) is a much more achievable goal.
Good luck!
I'm working on a game where the physics are very simple. I just need to detect when a ball (point) hits a wall (line segment). There is no gravity, no friction, and the collisions are perfectly elastic.
I've already written collision detection code, but I'm about to make some major changes to the project, so there's an opportunity to replace it all with the Chipmunk physics library. Is this a good idea?
On the one hand, Chipmunk will be more heavily tested and optimized than my own code, and I won't have to do the work of maintaining it.
On the other, maybe Chipmunk will be less performant in my case, since it was designed to support a lot of features I won't be using.
I'm hoping someone more familiar with Chipmunk will spare me the effort of profiling it or reading the code myself to make this determination.
The only real advantage Chipmunk would have here is if you are colliding that ball (or many balls) against many walls as it uses a spatial index to only check the collisions of objects that are near each other. This means that you can scale up to hundreds or thousands of objects without slowing to a crawl, but offers no real advantage if you only have a dozen objects in the scene.
It sounds like what you've implemented so far works just fine for your needs. "If it's not broke don't fix it" is a good rule of thumb here. On the other hand, it would be really easy to implement the same thing in Chipmunk. If you want the experience and the possibility of scalability in return for the hassle of a dependency, go for it I guess.
Scott (the Chipmunk Physics guy)
I've found Chipmunk to be incrediblly easy to use, I would recommend it to anyone starting a 2D project. I can't answer the performance question without knowing your code. I know it uses a spatial hash for collision determination, it may end up doing less collision tests than your code. (On the other hand if there are a very small number of balls and walls, this may not be an issue).
It is open source, so another possibility would be to use Chipmunk, but remove all the features you don't need - gravity, friction, moments of inertia, etc. Again, it's hard to say this is a good option without knowing exactly what you have already implemented.
It really comes down to what you want it to do. I have not used chipmunk itself, but from what it sounds like I'd say you aren't really in need of a full physics library.
Now, if you have plans to expand it beyond a ball and a wall such that you would have use for the expanded physics, then learning it now on a simple problem now may be a good idea. Overall though, unless you either want to learn the physics library or plan on raising the complexity/number of types of physics calculations, I'd say just do it yourself.