Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Pages: 1 2 [3]

Author Topic: Hypothetical challenge: eliminate lag  (Read 15022 times)

reactorcore

  • Guest
Re: Hypothetical challenge: eliminate lag
« Reply #30 on: February 06, 2014, 06:04:16 AM »

BE CLEAR WHEN YOU POST.

 :(

But thats exactly what I did. I posted a clear question and then posted some examples of ideas that could contribute towards it, but people got more curious why and what was it for, so I explained the origin. Unfortunately in doing so, people who are complaining about the lack of clarity are the ones who caused it in the first place.  :-\

Again, the challenge I'm trying to solve here is how to make a scenario with overwhelming amount of objects work without lagging through the use of clever optimized design. Look at the OP again, the picture shows the type of issue I'm trying to figure out, where you got lots of game objects, with different values and physics collision enabled, like the asteroids in Starsector, all moving in random directions and random velocities, trying to find a way how to have unlimited amounts of them, even if it means using illusionary solutions to create that optimization that allows it to work without lag.
Logged

TJJ

  • Admiral
  • *****
  • Posts: 1905
    • View Profile
Re: Hypothetical challenge: eliminate lag
« Reply #31 on: February 07, 2014, 06:54:45 AM »

lmgtfy

http://gameprogrammingpatterns.com/spatial-partition.html

The most important thing to take away from that article is: do you need to?

Even a naive implementation* of circle<->circle collision detection & response can be brute forced ( O(n^2) ) when n is small. (small<1000)

*I just so happen to have such a naive implementation that I wrote over a decade ago. Shocking how the Internet remembers everything!
Logged

reactorcore

  • Guest
Re: Hypothetical challenge: eliminate lag
« Reply #32 on: February 07, 2014, 01:38:06 PM »

lmgtfy

http://gameprogrammingpatterns.com/spatial-partition.html

The most important thing to take away from that article is: do you need to?

Even a naive implementation* of circle<->circle collision detection & response can be brute forced ( O(n^2) ) when n is small. (small<1000)

*I just so happen to have such a naive implementation that I wrote over a decade ago. Shocking how the Internet remembers everything!

Certainly a good technique, very useful and even necessary if the goal is to simulate a live universe. Making stuff go idle if its far away or not do anything at the moment is the single most useful thing to do for such real-time simulation worlds.

One thing I'm concerned about is how to deal with events like these:

(Warning! Big animated gifs, may slow your browser down)
Spoiler








[close]

Mass object interaction events, lots of stuff happens at once, players doing ridiculous things or otherwise something of epic proportions happens. How to make those moments NOT turn into a slideshow.

One idea I've been throwing around is to have priority of an object determine whether to load it or omit it. If a huge object interacts with a small one in any number, like say a moon collides with a planet, where the surface of the planet had all sorts of small interactive things, like people, animals, trees, vehicles, loose terrain etc, only the physics interaction of the planet and the moon is calculated, meanwhile everything squished in the middle simply get deleted and not simulated further, because of their insignificance in the huge event.

Sadly, that idea works only in small vs big object interaction situations. Meanwhile, what if you have an event where lots of small objects of different types collide in a single instance? What to do to eliminate the lag in that situation?  ???
« Last Edit: February 07, 2014, 02:06:24 PM by reactorcore »
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: Hypothetical challenge: eliminate lag
« Reply #33 on: February 07, 2014, 02:10:19 PM »

Quote
How to make those moments NOT turn into a slideshow.
You can't; your job is to make the game spectacular without having to resort to brute-force things like that.  Cortex Command is almost "how NOT to optimize a game properly", lol.

For example, most engines have a particle queue and culling system; if > max particles, then quit generating (or eliminate the particle furthest way from the event) to save some CPU / GPU.  You can do that for all sorts of events, but you can't really do much about it for physics, other than degrading collision meshes, which won't take you very far (if your collision meshes are 1:1 with the display mesh, you're doing it wrong).


Logged
Please check out my SS projects :)
Xeno's Mod Pack

Tecrys

  • Admiral
  • *****
  • Posts: 596
  • repair that space elevator!
    • View Profile
Re: Hypothetical challenge: eliminate lag
« Reply #34 on: February 07, 2014, 02:27:12 PM »

Cortex Command is almost "how NOT to optimize a game properly", lol.

I bought that piece of crap, it's actually much more fun to watch it then playing it. Controls are way too clunky and it's not really fleshed out. Feels unfinished. (although I haven't played it for a long time, it might be that updates improved it a lot.
Logged
Symbiotic Void Creatures 0.5.0-alpha for 0.97a is out
https://fractalsoftworks.com/forum/index.php?topic=28010.0

reactorcore

  • Guest
Re: Hypothetical challenge: eliminate lag
« Reply #35 on: February 09, 2014, 09:34:43 AM »

Quote
How to make those moments NOT turn into a slideshow.
You can't; your job is to make the game spectacular without having to resort to brute-force things like that.  Cortex Command is almost "how NOT to optimize a game properly", lol.

For example, most engines have a particle queue and culling system; if > max particles, then quit generating (or eliminate the particle furthest way from the event) to save some CPU / GPU.  You can do that for all sorts of events, but you can't really do much about it for physics, other than degrading collision meshes, which won't take you very far (if your collision meshes are 1:1 with the display mesh, you're doing it wrong).


I'm looking for solutions other than the brute-forcing you mention, thats the whole point of the thread. Got any more ideas?
Logged
Pages: 1 2 [3]