Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Cracks  (Read 2499 times)
0 Members and 1 Guest are viewing this topic.
Offline malberts

Junior Member





« Posted 2008-05-19 14:19:32 »

I'm thinking of how to implement destructability in objects by simulating cracks with a kind of L-system (like the way 2d trees are drawn). Eventually when the cracks reach the other end bits will break off (these bits are determined by the L-system pattern).

I'm new to how physics engines work, but how severly does the size of objects affect performance? And what if the objects are polygons? How many objects can these engines typically handle at a time when they all are moving?

The bits that break off should not be treated as particles from an emitter because these bits should still act as objects that can be moved, but they just won't be crackable anymore.

All of this will be in 2d platformer type environment, using something like phys2d.

Thanks

In space no-one can hear you System.out.println()
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2008-05-19 14:48:29 »

Wouldn't it be a lot easier to implement a 'net' of triangles with springs holding them together. The visual triangles will be larger than the physical ones, so that you won't see gaps, until the springs break due to a tension threshold. I think this is both easiest (nothing to analyze, stuff just breaks) and most realistic (it's like tearing apart fiber / molecules).

With slightly varying spring-strengths you can have unpredictable cracks.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline malberts

Junior Member





« Reply #2 - Posted 2008-05-19 15:08:39 »

That's an idea. But how would I go about predefining the triangles?

The objects that can break will be textured, like a brick wall or a wooden box. Then I would assign a crack pattern to each of those. The patterns are just an L-system string like "AABA[AB]BA". So when the object gets hit I would draw the "pattern" associated with that substring of letters, onto the object (how would you do this with triangles?). The lengths of the crack lines will be determined by the size of the object so that the crack always goes through after a certain amount of hits.

Then when the object gets broken I use the L-system string to calculate the polygon points and remove the original object and replace it with the broken bits and then the physics engine kicks in to make them fall down and roll and whatever. These bits should still be visible and react to physics, for example when an object below that one gets blown up too.

Using an L-system isn't very difficult as I've used it before. But my issue is how will the physics engine react when 10 crates each blow up into 10 bits each? It now needs to calculate the movements of 100 polygons, and most probably much more when near everything on the screen can be destroyed. If these were done with particle effects then it wouldn't matter but then these bits won't act like they should.

Or do you think I'm a bit overoptimistic in what the current physics engines can handle?

In space no-one can hear you System.out.println()
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2008-05-19 15:40:02 »

Well, my solution was more like dealing with true physics, no L-systems.

Things would simply happen, because they would happen in reality. It's is pretty much non-deterministic, so if you want to crack an object after N hits, it's problably not a good solution to rely on a physics-engine that cracks the materials.

Anyway, Verlet-Integration would be a nice fit, if you'd go with a triangle-net, and scales really good (linear).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline malberts

Junior Member





« Reply #4 - Posted 2008-05-19 16:10:20 »

Your method is to have the object throw off triangle, kind of like when something gets chipped?

What I want is for the object to kind of "explode" once its taken enough damage. The "explosion" will be the bits that are formed from the cracks.

I don't want the physics engine to handle the cracking. The L-system will determine the crack pattern. The physics engine must handle all the bits that come loose.

Once an object breaks the bits that come loose must be handled by the engine, the same way "rolling a box" would be handled. Once these broken bits come to a standstill they must remain there as smaller objects, not as particle effects. So if something was to happen that disturbed the bits' rest then they should once more roll along or whatever.

The area in which this destructability occurs could potentially lead to a lot of broken bits. My question is how many such bits can the engine handle before becoming slow?

Maybe I should only have asked how many objects the physics engine can handle at a time. I only mention the cracking to show how the objects will originate and how they will be, ie. smallish polygons.

In space no-one can hear you System.out.println()
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #5 - Posted 2008-05-19 16:22:48 »

The area in which this destructability occurs could potentially lead to a lot of broken bits. My question is how many such bits can the engine handle before becoming slow?
You're not going to get an easy answer to that, they're just too many variables to take into account. What physics engine? What speed CPU? What's the rest of the physics environment like? What's the target framerate? What's the complexity of the shrapnel? You'll probably just have to knock up a test app and see how it copes to get some actual numbers.

I suspect you'll largely be limited by the speed of the collision detection, most physics engines are slanted towards geometric primitives (circles, rectangles) rather than poly meshes. Keeping the number of sides of your shards to something low would probably make a big difference. Removing old shards (say, once they've been off screen for a while) would be a good optimisation too.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline malberts

Junior Member





« Reply #6 - Posted 2008-05-19 16:51:38 »

I mentioned phys2d, but I haven't used it or anything else before. Since this will be in a game it should probably run at 60 fps and not only just on new cpus.

I suspect you'll largely be limited by the speed of the collision detection, most physics engines are slanted towards geometric primitives (circles, rectangles) rather than poly meshes.
That sort of answers my problem, but how much will polygons affect the speed? Are there some benchmark results for the available engines?

If the polycount was reduced to triangles then the shards won't look too good when a bunch of triangles are laying around. And there won't really be any optimization, once the object is broken the shards remain there as new objects.

Mmm, or maybe I should just rethink the effect I want to achieve from this.

In space no-one can hear you System.out.println()
Offline ewjordan

Junior Member





« Reply #7 - Posted 2008-05-19 18:25:10 »

If you want some sense what you can get out of a physics engine in Java, see http://www.jbox2d.org/v2demos/ and flip through the demos - there are demos with body counts ranging from one or two all the way up to hundreds and hundreds.  The "proxy count" stat roughly correlates to the number of bodies (it's actually the number of shapes, of which there may be more than one per body).

Those demos use JBox2d, which is not entirely optimized, and it also is slowed down quite a bit by the use of Processing's software renderer to draw everything, so you could probably squeeze a bit more out of an engine in practice.

That said, a physics engine with a good broadphase (JBox2d has a pretty good one) can happily simulate in the neighborhood of a thousand bodies without too much difficulty, as long as they are not piling up on each other.  What slows an engine down is large islands of touching bodies that need to be iterated over as a group to solve interpenetration constraints - the pyramid, circles, and domino tower demos at the above link are examples of worst cases.

BTW, polygons in Box2d (and JBox2d by extension) are pretty fast, I wouldn't worry too much about that.  Triangles are actually sort of a worst case, as a triangle shatter will likely cause a lot more pieces to be generated than a polygonal one, and triangles are just handled as a special case of polygon.

In any case, I doubt if 100 bodies would be a difficult to handle for most engines.  Phys2d and JBox2d are based on the "same" engine (Phys2d came from an early Box2d, JBox2d is a port of the newer one), so speed should be similar - any algorithmic improvements made in the newer Box2d are likely made up for by the fact that Phys2d has had more time to get optimized and stable.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (27 views)
2014-09-07 01:11:22

Longarmx (27 views)
2014-09-07 01:10:19

mitcheeb (35 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!