Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
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  
  [SGS] Darkstar and physics simulation  (Read 2951 times)
0 Members and 1 Guest are viewing this topic.
Offline hplus

Senior Newbie





« Posted 2006-03-28 17:41:00 »

I've been reading the Darkstar documentation. It appears to use a common transactional model, where transactions are intended to cover only a small number of objects.

However, most physics solvers available today actually throw all world objects into a big matrix, runs an LCP solver on that matrix, and out comes the new positions/velocities/orientations of the objects.

A naive implementation of this mechanism as GLOs would have a world stepper that acquires (using get()) all the objects, throw them into the solver, writes the output to the objects, and then commits. This wouldn't scale all that well. While you can partition the solver into separate "islands" that can be solved separately, knowing which island an object belongs to is part of the collision and interaction connectivity graph, which in turn would be a single large object with references to everything.

Is there a better solution to this problem within the SGS?

Also, modern physics games step at between 30 and 100 steps per second; would the object store keep up with committing the entire world at that rate? Does it do write combining, and if so, is the write combining ordered per object or store-wide?
Offline SubZero

Junior Newbie





« Reply #1 - Posted 2006-03-28 19:34:37 »

I thought about the same thing and ended with the conclusion to make this simulation on the clients and only check the submitted positions on the the server. Otherwise I fear to overburden the object store. I think the object store will generally be the bottleneck, when you try to simulate large worlds.


Christoph
Offline hplus

Senior Newbie





« Reply #2 - Posted 2006-03-28 19:54:14 »

You're right, the claims in the server programming manual only say "an efficient, scalable, reliable, and fault-tolerant architecture" and doesn't actually mention "secure." When you trust the client on simulation, there are a whole class of cheat-proofing you just can't do, which you can with authenticated server-side physics. For a typical RPG, it probably doesn't matter, but for something like a first-person shooter, it would.

I agree that a single object store seems like the main bottleneck. Again, for an RPG, it probably won't matter, but for something with high-action, I don't see how they could do thousands of players in a single action game world.

Does anyone know what the actual object store back-end is, and more importantly, how well it scales (in commits per second)?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2006-03-28 22:26:34 »

The SDK ObejctStore is a custom in-memory transactional store backing itself up to BLOBs in Derby.

The full back-end is currently using HADB, which is a technology that Sun bought (actually we bought the whole company.)  It is a destributed in-memory database that scales "near-lineraly" according to the developers.

Shawn Kendall at full sail/IMI and I have been talking about this specific problem some.  To *really* take advanatge of the architecture you would want to develop a physics model which can handle parallel computation.  this would allow you to properly spread your load across the SGS back-end.  We provide the key primitive for such aprallel problems== which is the ATTEMPT form of GET.  You can see how this is used to paralelize the processing of timer events in the PDTimer source code.

Actually developing the destributed processing algorithym though I have a feeling is an un-done research project.  Anyone looking for a good thesis subject?  Cool

Short term, you can punt and do what you woudl have done anyway-- build a seperate physics server process around your favorite physics library.  You can then talk to it from the rest of your logic through the Raw Socket Manager in the SGS.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline hplus

Senior Newbie





« Reply #4 - Posted 2006-03-30 00:25:06 »

Quote
Actually developing the destributed processing algorithym though I have a feeling is an un-done research project.  Anyone looking for a good thesis subject?  Cool

Actually, I've seen that done, although in C++. I believe one rule has to be that an object can only derive its state from the state of objects in the past (i e, you must forego the big-LCP-solver approach), and thus you will need to at least double-buffer your physics state based on time. Thus, when updating state from (step-1) to (step), everyone could get state for (step-1) without interfering, and the object could lock itself at (step). However, I don't quite see how to express this in SGS parlance, because you lock the entire object when you get() it, and there's no "commit and swap" primitive. Any ideas?

Disclaimer: Daytime, I work for a company that has significant investment in a similar area.
Offline Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2006-03-30 05:17:25 »

We have that.  Its called a PEEK.  PEEK returns a tasklocal copy of the last comitted state.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline mudman

Junior Member




Here we go again...


« Reply #6 - Posted 2006-03-30 09:19:22 »

But the problem is that the object might already have been committed for (step) by another task.
Offline hplus

Senior Newbie





« Reply #7 - Posted 2006-03-30 16:07:27 »

@Jeff: I suppose it could be implemented with peek if the peek-er looked at both "previous" and "current" states and took whichever was for the timestep they could read.

@mudman: The order of commit doesn't matter if you make a partial ordering rule: all objects commit for step N before any object is allowed to commit for step N+1. This is basic simulation time management; you can read (for example) the HLA standard (ISO 1516) to learn all about it.

So, assuming that all you have is peek and get, and assuming that a peek that runs in parallel with someone else's get will succeed (and return the previous state, until global commit), then the loop might look something like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
// stepped by someone who knows how to step everything in order
object::evolve(long fromStep) {
  assert( cur.time == fromStep );
  swap( prev, cur );
  cur.time = fromStep+1;
  foreach( other in myCell.findIntersectionsWithMe(fromStep) ) {
    state = other.peek();
    if( state.prev.time = fromStep ) useState = state.prev;
    else useState = state.cur;
    handleIntersection(useState);
  }
  calculateNewState();
}
// commit here

Offline Jeff

JGO Coder




Got any cats?


« Reply #8 - Posted 2006-03-30 19:31:34 »

But the problem is that the object might already have been committed for (step) by another task.

If what you want is to keep a previous version even after commit of a new value, I suppsoe you could just keep 2 GLOs.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #9 - Posted 2006-03-30 19:39:56 »

@Jeff: I suppose it could be implemented with peek if the peek-er looked at both "previous" and "current" states and took whichever was for the timestep they could read.

A PEEK will pick up the most recently committed copy.  Is that what youa re  lookign for? If not, then yo ucoudl always run two GLOs per node and truly "double buffer."  Or keep multiple copies of the data in the same GLO...


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
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 (29 views)
2014-09-12 09:08:26

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

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

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

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

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

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

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

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

mitcheeb (40 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!