[The E]

Given the distances involved, I suppose it won't be that heavy.

[Droid803]

You actually need 10km by 10km by 10km when you fly at like, 300-400 m/s.

it only takes like 30 seconds to fly from one end to the other, which is really fast and easy to do and then suddenly no more rocks... >.>

[Nuke]

I blame it on nuke, he fooled me!

meh, i didnt realize the game only did radius checks by default.

[Sobbsy]

Does the engine (in its current state) have any kind of support for Instancing? Because if we could instance asteroid objects (and perhaps fighters like Mara's and such that come in big waves) we could seriously reduce the rendering overheads. For anyone who doesn't know what instancing is, the most basic way I can describe instancing is taking 100 of the same object, and instead of rendering each and every one of those individually, you pass them through the rendering pipeline as 1 single object, drastically reducing the workload on the GPU. Basically...

I just think that if that can be implemented (and I don't imagine that it'd be TOO much to ask of this particular engine) than we could really start to see some improvements to the limitations of model-heavy scenes.

I'll let a coder call the ball on that one though.

[mjn.mixael]

How could you possibly 'instance' collision and lighting on multiple objects without it looking ridiculous.. or perhaps I don't really understand what instancing does...

[Luis Dias]

How could you possibly 'instance' collision and lighting on multiple objects without it looking ridiculous.. or perhaps I don't really understand what instancing does...

It's a quite known feature since directx 10, and I think that the latest iterations from opengl accept this. Still it's not every graph card that does it.

[mjn.mixael]

That doesn't answer my question...

[Sobbsy]

How could you possibly 'instance' collision and lighting on multiple objects without it looking ridiculous.. or perhaps I don't really understand what instancing does...

It's a quite known feature since directx 10, and I think that the latest iterations from opengl accept this. Still it's not every graph card that does it.

OpenGL 3.0 and beyond fully supports model / geometry instancing, so that won't be a problem. And so long as anyone playing FSOpen has a videocard made within the last 3 or 4 years, they should have no issues with support for that feature (and correct me if I'm wrong, but this is the target audience for FSOpen due to performance requirements of the mod and shaders etc). So I don't think it's a question of playerbase support, but rather the actual implementation of the feature and its feasibility.

Lighting & collision detection shouldn't be an issue either. I'm no coder but as far as I understand it, the lighting and/or collision mechanisms are handled at a different 'stage' within the rendering pipeline and therefore should pose no issues (you could almost look at it like post-processing in this situation). What we're talking about is just taking multiple copies of the same model and enabling the GPU to process them all as if they were the 1 individual object. Their size, texture, lighting, collision and so forth are all handled separately.

You can get the basic idea behind instancing here;

http://en.wikipedia.org/wiki/Geometry_instancing

Like I said, I'm no coder but I've hung around with enough folk working on instancing methods to understand that in theory this should be 'relatively' easy to implement and control, especially when using OpenGL as opposed to DirectX.

[Kolgena]

I think the question is: How does instancing help when the calculations for collisions of hundreds of entities is the real bottleneck in asteroid fields?

You said that collision and so forth are handled per-instance, which does nothing for cutting down collision calculations. I guess you do have a point for instancing ships and stuff though. Could reduce the load when there are multiple high stress ships (karunas) involved in a scene, and the GPU buckles before the CPU. However, I have no clue whether some form of instancing is already being used in the engine.

[mjn.mixael]

I think the question is: How does instancing help when the calculations for collisions of hundreds of entities is the real bottleneck in asteroid fields?

You said that collision and so forth are handled per-instance, which does nothing for cutting down collision calculations. I guess you do have a point for instancing ships and stuff though. Could reduce the load when there are multiple high stress ships (karunas) involved in a scene, and the GPU buckles before the CPU. However, I have no clue whether some form of instancing is already being used in the engine.

This was my next question.

[Sobbsy]

I think the question is: How does instancing help when the calculations for collisions of hundreds of entities is the real bottleneck in asteroid fields?

You said that collision and so forth are handled per-instance, which does nothing for cutting down collision calculations. I guess you do have a point for instancing ships and stuff though. Could reduce the load when there are multiple high stress ships (karunas) involved in a scene, and the GPU buckles before the CPU. However, I have no clue whether some form of instancing is already being used in the engine.

I'm just harking on about instancing because from what I can gather the collision detection limitation is currently being worked on and won't be too big an issue before long. I think what we'll start to see is a relaxation in the collision detection overheads, but then we'll see a bottleneck in how many asteroids & ships that can be rendered simultaneously - that's where I'm looking to with this.

It's all well and good if we can solve the collision detection performance issues so the overhead is negligible on x many hundreds (or thousands?  ) of objects, but if we just replace collision detection overheads for rendering limitation overheads, we're right back where we started. That's where I think instancing could help out dramatically.

 

[Kolgena]

Well, I guess instancing is going on that long list of "be nice if we had it, but I don't want/know how to do it" things, assuming it isn't already implemented.

[Bobboau]

I would like to take a moment to help everyone appreciate what N^2 complexity means, when there are 256 asteroids, this means that there are 65536 potential collisions that must be checked against, now this isn't too bad, lets make a gross understatement and say that the collision detection of these objects will take one nanosecond to determine, this means that for this grossly simplified model of the problem the absolute maximum framerate that we could possibly get assuming we did nothing other than collision detection (i.e. no drawing) using some insanely efficient bounding spheres implementation would be about 15258 FPS. pretty good right, we only want 60 FPS so what is the big deal, ok, well lets double it and see what happens.

now we have 512 asteroids that yields 262144 pairs, that's 3814 FPS, wow, that's still crazy good... but if you are perceptive, you might have noticed something, we increased our objects by a factor of 2, our framerate and amazingly high as it is, is now 1/4th what is was before, but that's no matter we have tones of room to expand, we only need 60 FPS and we have almost 4000. lets double it again.

1024 asteroids, 1048576 pairs => 953 FPS. wow, it was almost 4000 last time, now it's not even 1000. but no matter we still have a lot of room, lets go one more
2048 asteroids, 4194304 pairs => 238 FPS. lets do it again
4096 asteroids, 16777216 pairs =>  60 FPS. oh, wow, all we did was multiply the number of asteroids by 8, and our framerate went from over 15000 FPS, to just 60, if we go just one more step we hit 15 FPS, the one after that and its down to 4 FPS. keep in mind, this is doing nothing more than an impossibly fast collision test, in reality 1ns is about the speed it takes to perform one multiplication instruction, even just a simple sphere collide test is substantially more complex then this, these numbers give you an understanding of the performance characteristics of the overhead of the comparison, just simply touching them, it's how fast the nested loop would run if it did nothing. and this assumes we do nothing else, no graphics, no input, no game logic. now their might be a better way of running these tests, but it doesn't really matter because right now this isn't even the bottleneck. the bottleneck comes once we have exhausted all possible cheap routs and have to actually collide with a BSP poly-object.

now you might say to yourself, why are we using this horrendously complex structure? the answer is because it gives us logN complexity collision tests, this is effectively the opposite of what we have at the top level, testing for collisions on a model with 100 polies? that will take about 7 steps, more or less (actually it'll provably be more like 25 in the real world) want to collide with a poly object with a BILLION polygons? oh, that'll take about 30 steps (honestly it'd probably be more like 300, but who's counting?) without the BSP tree an object ten million times more complex would need a ten million times as much time to collide with, rather than 4 times more.

so you see we are already using an extremely efficient algorithm to do the model tests, and yet it is still slower than the extremely slow high level test we are using, and it doesn't even get used for asteroids.

[Kolgena]

The key is probably to unphysicalize a majority of asteroids when they're not doing much, but physicalize them on demand only when they are a certain distance to the player or inside the camera's fov. I'm not sure what would happen if you were to look at and physicalize two asteroids while they are floating within each other though.

Or do what WoD did and build a corridor of asteroids and hope the player is not going to leave it.

[Shivan Hunter]

"to look at and physicalize two asteroids while they are floating within each other" -> That "looking" is actually the problem. Checking per-poly is O(log N) according to Bobboau.

Don't asteroids not collide with each other at all? (I mean, is a high-level check done between two asteroids)? If that were the case, adding a ship would be O(N^2) but adding an asteroid would be O(N). a mission with 1 fighter and 65535 asteroids should have 65535 collision pairs.

Like Kolgena said, FRED could have an option- a radius around the player, or the origin, or maybe just a box like asteroid fields already are- within which asteroids check collision, and outside of which they don't. The FREDder would just have to make sure that no ships or installations are outside of the collision box but still inside the field, or that asteroids passing through it wouldn't be noticed.

[EDIT] also, soft particles are the solution

[IronBeer]

The key is probably to unphysicalize a majority of asteroids when they're not doing much, but physicalize them on demand only when they are a certain distance to the player or inside the camera's fov. I'm not sure what would happen if you were to look at and physicalize two asteroids while they are floating within each other though.

I don't think that such a solution would actually help, since you'd still need to be checking all asteroids continuously to confirm whether or not they are at the criteria to be physiciszed. Besides, what about events occurring off-screen, like a capital ship you're escorting getting pummeled by rocks, or a dopey wingman flying into a 'roid?

Damnit, Shivan Hunter. Edged me out!

[Nuke]

The key is probably to unphysicalize a majority of asteroids when they're not doing much, but physicalize them on demand only when they are a certain distance to the player or inside the camera's fov. I'm not sure what would happen if you were to look at and physicalize two asteroids while they are floating within each other though.

Or do what WoD did and build a corridor of asteroids and hope the player is not going to leave it.

thats kinda what i suggested before. right now asteroids are a derifitive of the object class, they have hitpoints physics data, etc, and they are persistant in the game all the time. if you find an asteroid shoot at it, and leave the area, you will be able to come back and the asteroid would still have all its data. they are persistant, and persistant objects are always being processed all the time (and that includes things like rendering and collision detection, the game checks to make sure 2 asteroids in a far cornerof the miccion collide, its really a waste of time). even if its 10 klicks away and at lod 6. now why does that behavior need to do that all the time. you have a one to ten meter asteroid, that is only visible if youre within say a klick of it. as soon as its out of sight, it simply ceases to existm, no further operations are being done on it. you would still be able to shoot the asteroids and youd still see them hit eachother, but they dont do it when your not looking (or rather when they are out ouf visual range, or rather non-existant at that point).

so what i would do is keep asteroid limits where they are. so you might have 256 good sized asteroids which are persistent at all times. but on top of that you have a another set of say 128 asteroids that only exist in the vicinity of the camera. it would pay heed to the cameras velocity so that asteroids are spawned as they are being "approached" (periodically an asteroid would be spawned a km or two in the direction of the velocity vector). as that happens your also gonna remove an asteroid that you have passed by a km or two, the furthest one away in the reverse direction. the game tries to keep a constant number of small asteroids (by varying spawn time based on the number of slots in the buffer), and they are deleted once they are out of range. so it may seem that there are millions of small asteroids, when in fact there are only ever a few of them. this is probibly something you could rig up in lua in a few minutes. doing this in the engine allows for other things to be done, like instancing for rendering performance. might not work to well in multiplayer since multiple players wouldnt see the same asteroids, maybe they would share asteroid data if their spawn areas ever intersected. or you would div up the buffer so each player could have some rocks and players could see eachothers rocks if they were close enough. thats a whole other can of worms.

of course coming back to btrl, it really shows you how to composite an awesome environment with several existing elements layered on top of eachother. i just say give modders a few more layers to play with. id really like to see improved environments in the game though. localized nebula and better asteroid fields, etc.

[Sushi]

I think the question is: How does instancing help when the calculations for collisions of hundreds of entities is the real bottleneck in asteroid fields?

You said that collision and so forth are handled per-instance, which does nothing for cutting down collision calculations. I guess you do have a point for instancing ships and stuff though. Could reduce the load when there are multiple high stress ships (karunas) involved in a scene, and the GPU buckles before the CPU. However, I have no clue whether some form of instancing is already being used in the engine.

To be fair, Rendering multiple high-poly objects is a pretty big bottleneck too. The engine is far more inefficient than it should be when rendering lots of a high-poly object (like the mediavps asteroids). Revamping our rendering pipeline (using instancing, or something else) would certainly result in framereate improvements.


As far as bumping asteroid limits, I honestly think we could probably get away with it, but I'd rather focus on bumping weapon/object limits first. Diaspora won't be able to release until that happens.

[fightermedic]

so, if asteroid collisions are the problem, what about a checkbox for asteroid fields to have them static?
in this case only ships etc would need to check for collisions with aseroids as the asteroids themselfs would not move.
and ships, rocktes etc only need to check their immidiate surroundings every now and then

[The E]

fightermedic, you do not understand the problem.