bubble shields - the re-take

[srs008]

i've been in a few discussions about bubble shields now, the real problem (i think) comes from the approach, at the moment we are proposing rendering a entirely seperate entity to the ship, whilst still keeping it attached to the ship, this would crate a intense amount of processing, yes the rounded shape would shave a few fps, but it's more the implementation, then the shape...

as an example, i'm going to refer to one of the most buggy games, and it's almost as buggy "mod/mod framework" ... minecraft, and minecraft forge. we all know it's got a heck ton of bugs, and a large amount comes from poor coding, or just poor rig jobs... (no i'm not actually dissing forge here, they have to work with what they are given.)

and yet one of the most impressive things i saw was a forcefield mod for minecraft (modular force field system, MFFS, last i checked, it was dead, but that was like half a year ago), despite the game itself being slow and jittery (i was running a dual core amd based laptop from 2008 at the time),
the mod had little effect on the game's already degraded performance, this mod had default "shapes" (round, pyramid, square), you could adjust the size of the field in six directions (up, down, left, right, front and back) change it's "effects" (place "solid blocks" from a chest, shock on contact, "sponge" (remove liquids) or even use another blocks texture...

it achieved this by using a custom block, and rendering it in place from the "generator". the animated block was square, and partially transparent

starmade would have no issues using a similar approach, and i think it'll be more efficient, the game would check for the highest and lowest points on a ship, the widest points... and the longest points...
add a few blocks "gap" and render a poor "oval"...

to reduce lag the "shield" should render invisible (unless modified by a color block, and then only faintly glow) (hey maybe "blacklight" could halve the light as a poor man's stealth?)

and it should be three blocks thick, this is so the hit detection can run 3x less often (server setting please),
the outer layer of blocks should be the ONLY blocks that render when hit, or anything...
this approach could also be used for planetary shielding (just treat it as a object in space, not one "orbiting" a planet) (i prefer the idea of having an "emitter" per side of the planet, connected to a shield capacitor with total capacity divided by the emitters, but shield rechargers directly charging the capacitors... very fast recharge, but building a shield capable of withstanding a shot from a battleship becomes difficult)

the ship shield would be considered "part" of the ship, so the game would handle it as the same entity (essentially they'd be a block with no health or armor, but protected by the shields and only deleted when the shields "drain"...
as a side note, a collision with an object should have no effect on the ship, except to drain the shields relative to the damage amount, this should NOT destroy blocks, but it should damage them...

the "bubble" shield should be a SERVER setting to allow on, and then a method of switching to bubble shielding with normal shields (structure tab?), so if people feel it's a issue, they can turn it off... of course, we'd like access to the various settings in the config.

 

[takethispie]

the problem isn't about rendering at all, it's about projectile detection , detecting a projectile and where it comes from on a spherical surface is really a pain in the ass and take a lot of processing power for nothing

 

[srs008]

surely detecting on the ship's surface would be more costly? especially with some of the crazy designs out there? i'm talking about projecting a fake wall in a spherical shape, as far as the client and server are concerned, they'd be the actual ship... i'm suggesting a dirty hack if that makes sense.

 

[Megacrafter127]

surely detecting on the ship's surface would be more costly? especially with some of the crazy designs out there? i'm talking about projecting a fake wall in a spherical shape, as far as the client and server are concerned, they'd be the actual ship... i'm suggesting a dirty hack if that makes sense.

Nope, it is far easier to detect collision on the blocks. Why?
Spheres involve sinus, cosinus and roots, which take up tons of calculation(compared to other operations).

 

[therimmer96]

to be fair, he is suggesting new blocks, that appear in a circle/other shape, which the build helper already does. This is a good way of lookinh at it in my opinion.

 

[ToyotaSupra]

to be fair, he is suggesting new blocks, that appear in a circle/other shape, which the build helper already does. This is a good way of lookinh at it in my opinion.

The more ideas the better.

Spoiler

Your new sig is making me dance slightly

OP this has been suggested before, there is a game (or was, now dead project) that did this but there was a deadweight with the cpu that the dev found, guess what it was? This would LOOK cool but we have to strike a balance between cool looking and low on resource.

 

[Cybertooth]

If the problem is hit detection, would it be possible to still detect collisions on the blocks, but display the sheild hit animation a certain distace away from the ship? It would be purely a visual thing, so none of the fancy stuff i've seen suggested before like flying inside the shields (allthough i suppose you could just have weapons fire from within a certain distance ignore shields, which would produce the same effect).

 

[FunnyBunny14]

It still might lag a lot more than it currently does. I really don't think bubbles are a priority right now.

 

[Lecic]

I prefer the skin shields over bubble shields. Seeing impacts ripple across the surface of the ship looks cooler than it hitting an identical bubble on every ship.

 

[DrTarDIS]

All i'm going to say is that it's entirely possible to make your ship have "bubble shields" right now.

 

[Lecic]

All i'm going to say is that it's entirely possible to make your ship have "bubble shields" right now.

Open plex doors are a wonderful thing.

 

[Keptick]

Open plex doors are a wonderful thing.

Area activators are too :P (plus they don't add any mass!)

 

[Lecic]

True, but you can slam the doors shut while a ship flies through, which is hilarious.

 

[Qweesdy]

Nope, it is far easier to detect collision on the blocks. Why?
Spheres involve sinus, cosinus and roots, which take up tons of calculation(compared to other operations).

For spherical shields; let's assume the core is the centre of the sphere and the radius is the corner of the ship's box dimensions. This means "radius = pow(box_x/2 * box_y/2 * box_z/2, 1/3);" (where box_x, box_y and box_z are the box dimensions). The distance from a projectile to the ship's core is like "distance = pow( abs( (x1-x2) * (y1-y2)* (z1-z2) ), 1/3)". When the distance from projectile to the core is less than or equal to the radius of the shield's sphere, then the projectile has hit the shields. This means:

if( pow( abs( (x1-x2) * (y1-y2)* (z1-z2) ), 1/3) <= pow(box_x/2 * box_y/2 * box_z/2, 1/3) ) {

// It hit the shields​

}​

However; this can be optimised (the "pow()" on both sides cancel out), and the sphere's radius can be pre-computed and doesn't have to be calculated every time. This means it becomes:

if( abs( (x1-x2) * (y1-y2)* (z1-z2) ) <= shield_radius ) {

// It hit the shields​

}​

This is virtually nothing. On a modern CPU you're probably looking at an average of 20 cycles.

For collision against blocks; I'm guessing the game would begin with a bounding box test; then determine which 16*16*16 block section (and if the section is present or not), then find the block within that section and test if it's solid or not. In this case the calculations are probably just as bad as the "spherical collision test". However; the problem is not the calculation, it's RAM access times. More specifically, every "look-up" involved is a likely cache miss, and cache misses on modern systems are extremely expensive. The full sequence is likely to cost thousands of cycles.

Basically; the "spherical collision test" (as described above) would be hundreds of times faster.

 

[Megacrafter127]

For spherical shields; let's assume the core is the centre of the sphere and the radius is the corner of the ship's box dimensions. This means "radius = pow(box_x/2 * box_y/2 * box_z/2, 1/3);" (where box_x, box_y and box_z are the box dimensions). The distance from a projectile to the ship's core is like "distance = pow( abs( (x1-x2) * (y1-y2)* (z1-z2) ), 1/3)". When the distance from projectile to the core is less than or equal to the radius of the shield's sphere, then the projectile has hit the shields. This means:

if( pow( abs( (x1-x2) * (y1-y2)* (z1-z2) ), 1/3) <= pow(box_x/2 * box_y/2 * box_z/2, 1/3) ) {

// It hit the shields​

}​

However; this can be optimised (the "pow()" on both sides cancel out), and the sphere's radius can be pre-computed and doesn't have to be calculated every time. This means it becomes:

if( abs( (x1-x2) * (y1-y2)* (z1-z2) ) <= shield_radius ) {

// It hit the shields​

}​

This is virtually nothing. On a modern CPU you're probably looking at an average of 20 cycles.

For collision against blocks; I'm guessing the game would begin with a bounding box test; then determine which 16*16*16 block section (and if the section is present or not), then find the block within that section and test if it's solid or not. In this case the calculations are probably just as bad as the "spherical collision test". However; the problem is not the calculation, it's RAM access times. More specifically, every "look-up" involved is a likely cache miss, and cache misses on modern systems are extremely expensive. The full sequence is likely to cost thousands of cycles.

Basically; the "spherical collision test" (as described above) would be hundreds of times faster.

distance isn't |(x1-x2) * (y1-y2)* (z1-z2)|^(1/3)
distance²=dx²+dy²+dz²=(x1-x2)²+(y1-y2)²+(z1-z2)²

 

[takethispie]

first you can not pretend to write a code and then say it would be faster because you don't know how the game is written
also no you can't say how much time in cpu cycle it would take because also you don't know how the game is written, again ... xD
btw it would be the GPU not the CPU because GPU works a lot faster on floating point

anyway bubble shield sucked , I know because I WAS HERE when bubble shields were still in the game

 

[Qweesdy]

distance isn't |(x1-x2) * (y1-y2)* (z1-z2)|^(1/3)
distance²=dx²+dy²+dz²=(x1-x2)²+(y1-y2)²+(z1-z2)²

You're right (but this doesn't change much, the square roots still cancel, and it's still a fast calculation vs. far more expensive cache misses).

first you can not pretend to write a code and then say it would be faster because you don't know how the game is written
also no you can't say how much time in cpu cycle it would take because also you don't know how the game is written, again ... xD
btw it would be the GPU not the CPU because GPU works a lot faster on floating point

Based on information I do know about the game, combined with extrapolating from observed behaviour, combined with a little experience; it's not hard to make a "likely close to correct" educated guess about how the game does things.

You can't know exactly how many cycles anything will take (even in assembly for a specific CPU) - modern CPUs are too complex for that (and for Java code there's a whole layer of "unknown JIT overhead" that make it even more impossible). However; you can approximate (in the same way that you can classify algorithms with "big O notation"without implementing or benchmarking them) and you can say "this is going to be several orders of magnitude slower".

I very much doubt that the game does collision detection using GPGPU (and expect it's done in Java). Also, GPGPU doesn't do individual floating point operations faster than CPU; instead it just does more floating point operations in parallel. If you want to deliver one package quickly, would you give that package to a guy on a fast motorbike who takes 10 minutes to deliver 1 package, or would you give the package to a guy with a huge slow truck who takes 2 hours to deliver a load of up to 1 million packages? The guy on the motorbike would be 6 times faster (even though he can only do 6 packages per hour and the guy in the truck can do 500 thousand packages per hour). Of course "faster" isn't really a good word - better words are "latency" and "throughput" (e.g. CPU has better latency, and GPU has better throughput). In our case (a small number of floating point operations with interdependencies that prevent them from being done in parallel) we care about latency and not throughput.

anyway bubble shield sucked , I know because I WAS HERE when bubble shields were still in the game

So was I, and I don't remember bubble shields ever being a problem (and if they were a problem that I didn't notice, then they were nowhere near the top of the list problems). Also note that collision detection has little to do with generating the "shimmering sphere" graphics effect - it's possible that you're blaming one because of potential problems in the other.

 

[jayman38]

Personally, I'm OK with a bubble-shield client visual effect. However, the devs will catch all kinds of complaints from players, saying that their near-hit shot "should have" hit the shield, even if they missed the body of the enemy structure.

If I had my way, I'd make a client-side bubble-shield visual available and client-configurable, but turned off by default. On a personal note, I'd probably continue to use the skin-shield that we have now.

 

[NeonSturm]

Nope, it is far easier to detect collision on the blocks. Why?
Spheres involve sinus, cosinus and roots, which take up tons of calculation(compared to other operations).

WRONG

Cos and Sin can be emulated using Bezier Curves over multiple steps or with a look-up table for x, y and z.

To detect hits, you
1. translate (=move) the projectile matrix with the negative ship positions - this would move the ship to 0 0 0
2. rotate the projectile coordinates - this would rotate the ship to 0 vertical 0 horizontal and is again a step to put the projectile into the ships coordinate system.
3. you scale the projectile's position by this pos through the ship's position.

Now you only have to check the inside|outside-value of a float-position like +0.8 +1.5 +3.6 against a second for a sphere of radius 1 around 0 0 0.

You need the impact angle on this sphere only - you try to get a position of distance=1 (to 0 0 0) between point A and point B.

To get the impact point on the sphere, you reverse translation, rotation, scale -> -scale, -rotation, -translation.

 

[Megacrafter127]

WRONG

Cos and Sin can be emulated using Bezier Curves over multiple steps or with a look-up table for x, y and z.

To detect hits, you
1. translate (=move) the projectile matrix with the negative ship positions - this would move the ship to 0 0 0
2. rotate the projectile coordinates - this would rotate the ship to 0 vertical 0 horizontal and is again a step to put the projectile into the ships coordinate system.
3. you scale the projectile's position by this pos through the ship's position.

Now you only have to check the inside|outside-value of a float-position like +0.8 +1.5 +3.6 against a second for a sphere of radius 1 around 0 0 0.

You need the impact angle on this sphere only - you try to get a position of distance=1 (to 0 0 0) between point A and point B.

To get the impact point on the sphere, you reverse translation, rotation, scale -> -scale, -rotation, -translation.

2. involves multiplying/dividing by the result of a sine(either sin, cos or tan)[unless we are talking about rotating a sphere with it's center at 0 0 0 of the ship, then it is just squares]