feature freeze time

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

safemode wrote:edit: some of the cpu_opts i'm using in cmake may cause bugs to rear up. let me know if anything strange is happening when you use them vs when you dont. I may have to switch off some of the unsafe math options. For instance, i notice on my machine sometimes certain ships are missing textures (they're all black)... weird things like that.
I think parallelizing loops using SMP is tantamount to assuming no aliasing, like in a big way.

Aliasing is what happens when what you do to one element can affect the neighbors.
For instance, if you run through an std::list<int> adding one to each int, that doesn't cause
aliasing, and can be parallelized. But if you

Code: Select all

typedef std::list<int>::iterator_t i_t;
for( i_t i = begin; i != end(); ++i )
{
  i_t j = i;
  ++j;
  if( *i > *j )
  {
      swap( i, j );
      i = j;
  }
}
This does cause aliasing, and is not parallelizable; --not easily, or automatically, anyways.
Essentially, any loop iteration is parallelizable if operations are on one element at a time without
knowledge of neighbors, and if there are no pointer manipulations internal to the elements being
iterated. Good practice is to make sure loops don't cause aliasing, or document the fact if it can't
be prevented. I'm sure we have loops with aliasing in many places, though. Vegaserver crapped
out with -O3, which assumes no aliasing when vectorizing.
Neskiairti wrote:you could always add a flag to runtime something like -artist
which would turn off the shiny mapping stuff. And if some one submits a piece of art without the shiny shit, tell them to display it in their game with -artist :P
reject it until they make it look good.
Yeah, ADT (Artist Detection Technologies); you move the mouse a certain way, and this background process checks in its knowledge base if that's an artistic mouse gesture --an artist's way of doing it... Is there an open source ADT? :D
charlieg wrote:Why not just release as-is, then release an update with the better shields, planets etc.

Feature creep, the enemy of a release cycle.
It's not about having better shields, for me at least, but about having these god-awful polygonated "spheres" gone. You're flying around and vegastrike is just starting to look fractionally decent; but the moment you get into a shoot-out it begins to do crazy things, like showing white polygons around ships you're shooting at, not letting you see your own shots; and if you're getting hit the screen is turning red for no reason, making it more difficult to see the colors of the dots in the sensor screen when you need it the most. If some mod needs spherical shields around ships, I understand; but they should look like spheres; not like diamonds.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

chuck_starchaser wrote:
safemode wrote:edit: some of the cpu_opts i'm using in cmake may cause bugs to rear up. let me know if anything strange is happening when you use them vs when you dont. I may have to switch off some of the unsafe math options. For instance, i notice on my machine sometimes certain ships are missing textures (they're all black)... weird things like that.
I think parallelizing loops using SMP is tantamount to assuming no aliasing, like in a big way.

Aliasing is what happens when what you do to one element can affect the neighbors.
For instance, if you run through an std::list<int> adding one to each int, that doesn't cause
aliasing, and can be parallelized. But if you

Code: Select all

typedef std::list<int>::iterator_t i_t;
for( i_t i = begin; i != end(); ++i )
{
  i_t j = i;
  ++j;
  if( *i > *j )
  {
      swap( i, j );
      i = j;
  }
}
This does cause aliasing, and is not parallelizable; --not easily, or automatically, anyways.
Essentially, any loop iteration is parallelizable if operations are on one element at a time without
knowledge of neighbors, and if there are no pointer manipulations internal to the elements being
iterated. Good practice is to make sure loops don't cause aliasing, or document the fact if it can't
be prevented. I'm sure we have loops with aliasing in many places, though. Vegaserver crapped
out with -O3, which assumes no aliasing when vectorizing.
parallelizing loops isn't what caused the issues i mentioned in my comment. That happened before i started using that option. Parallelizing loops is amazing, and had zero negative impact thusfar.

there are 3 things that can be causing the problems i'm seeing, my two math related options that are unsafe and admittedly dangerous to use if we need really tight float precision and such. Or vectorization. Both of which aren't turned on by normal -O2 but are by -O3. I'll have to play around to see which are offending.



As for shields, they're created as sphere meshes. How spherical they look is dependent on simple variables in the mesh creation function.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:But Klauss, this is horribly inefficient! Or am I missing something? What about overdraw? You're suggesting we cover every mesh with a second mesh using alpha-blending? !!! We need to invest on dual videocards in SLI just to see stupid shields?
How about my idea of faking a shield by showing billboard effects around the points of impact?
What?
It's only for the duration of the effect...

Billboard effects are nice though, mostly because we need some effect for hull hits.
I was thinking of particle systems. Spit debris here and there.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

safemode wrote:-ftree-parallelize-loops= What did i ever do without you? You are like porn for gcc optimizations. Really good stuff :)
Porn is the word for it :shock:
What an awesome feature!

And I thought you had to use openmp to get that, it seems gcc is getting better and better, if it can do it without even openmp annotations...

@chuck: imagine the physics loop we were discussing with that option on. :D

Aaaanyway.

@safemode: the shield mesh doubles as collision mesh. When you specify a shield mesh, it's used to initialize the opcode collision mesh. It's probable that regular meshes aren't opcode-friendly in some strange way, and there comes the segfault. I don't know... do you have a stacktrace?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

What about -fprefetch-loop-arrays? That would do a lot more for me, with a single core cpu ;-)
And it's totally safe.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

I'd rather use manual prefetching, with mm_prefetch (or something like that).

I managed to speed up lots of weird algorithms with it. You know the access pattern a lot better than the compiler or the processor, so inserting mm_prefetch here and there does wonders.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

klauss wrote:I'd rather use manual prefetching, with mm_prefetch (or something like that).

I managed to speed up lots of weird algorithms with it. You know the access pattern a lot better than the compiler or the processor, so inserting mm_prefetch here and there does wonders.
I totally agree; but let's do it, then. I'm not sure where the loops are, though; any way I can help with it?
BTW, I've seen a lot of file-reading functions all over the code, like to read csv data, or vegafig settings...
I hope we're not reading files again and again... Units.csv should be parsed once, and all the data be in memory by
the time the game is booted. Is it so?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:Units.csv should be parsed once, and all the data be in memory by
the time the game is booted. Is it so?
Pretty much certain it is so.

Before we start adding mm_prefetch everywhere it fits, we must get cmake/autotools to detect its presence and include the proper defines, and have config.h include the proper headers, etc, etc.

I can probably help in the autotools department, cmake, I'm just starting to play with.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

The segfault with tricking shieldmesh is in EnableSpecialFx in Mesh:: nothing to do with collision there.

We basically have a copy of the mesh after we load it and process it. This is referred to as the rapidMesh because our collider before opcode was the rapidCollider. Now, opcode translates our vectexes into a native format. It also converts any quadrilaterals into triangles because we're dealing with a triangle based mesh collider.

I think specialFX is causing the segfault because it expects a mesh with certain GL options turned on for it, where as our main mesh has other options because it gets wrapped in textures. The shieldmesh doesn't, it has to remain untextured and transparent. Plus, the real mesh is much more complicated than the shieldmesh would be. So it's fairly inefficient anyway.


I think when i'll eventually do is turn off shieldmesh and fake shieldmesh entirely. Have ApplyDamage still think there are shields and wait for the future when we can use a shader to paint a special effect on a ship called by shieldUp (which is triggered by applyDamage when we are hit and have shields active).
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

There would be a slight speedup by converting the rest of the game to using the same Point object that opcode uses in place of our Vector's.. But that would be a fairly large undertaking for an extremely minor performance gain.

when it comes to collisions, i dont think we have to worry so much about the speed of it. Right now we're plenty fast. We have to focus on problems related to visually displaying the collisions correctly and reacting to them correctly. And possibly scheduling the checks better.

the next thing on the collision chopping block is sphere colliders. Though i think i'll wait on that as i want to get cpack stuff all done first.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

safemode wrote:I think when i'll eventually do is turn off shieldmesh and fake shieldmesh entirely. Have ApplyDamage still think there are shields and wait for the future when we can use a shader to paint a special effect on a ship called by shieldUp (which is triggered by applyDamage when we are hit and have shields active).
I'd rather try to make it possible to reuse the real mesh as shieldmesh, albeit with a special "shields" technique. The technique could do vertex extrusion to make the shields hover a little over the real mesh, but overall wrap around nicely.

The technique should still use the same FX system (based on lights) since that's effective both with and without shaders.

So I'd rather fix the segfault. I'll work on that when I get home.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

You can't re-use the same mesh referenced by GL as the main mesh, since that gets textured and drawn differently than we would need shields drawn. It has to be a copy

At least, you can't re-use it while using the specialFX function as-is. I basically already did what you last said, and re-used the real mesh for shieldmesh and commented out the specialFX function call. No segfaults. The problem is that we still have sphere shield collision code elsewhere that will need to be turned off too so we dont get "shield hits" when we're not impacting the actual body of the ship. This should reduce collision load somewhat too since we wont have such large volumes to check collisions against. All we will ever need is spheres of the actual radius of the ship and not the radius of the shield.

in any case, removing the specialFX call and re-using the regular mesh like opcode does is trivial, as is removing whatever collision detection against the shields there is. What wont be trivial is creating your shader to do something nifty with it.


note, obviously we wont be commenting out the stuff we aren't using in VS - the game as other mods may use it in their code, so we'll have to create an option to enable sphere_shields.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

safemode wrote:You can't re-use the same mesh referenced by GL as the main mesh, since that gets textured and drawn differently than we would need shields drawn. It has to be a copy
That's what techniques are for.
So yes, you can reuse the mesh.
safemode wrote:At least, you can't re-use it while using the specialFX function as-is.
That's rather evident. Since it segfaults :P
But I get the point. I'll take a look.
safemode wrote:I basically already did what you last said, and re-used the real mesh for shieldmesh and commented out the specialFX function call. No segfaults. The problem is that we still have sphere shield collision code elsewhere that will need to be turned off too so we dont get "shield hits" when we're not impacting the actual body of the ship.
AFAIK, when there's a shield mesh collisions are computed against that mesh. Or am I wrong?
safemode wrote:This should reduce collision load somewhat too since we wont have such large volumes to check collisions against.
That's not true. There will be less collisions, but collisions against spheres are trivial, and collisions against meshes are not. I propose to test against a sphere first, and if that test passes, refine the test by testing against the mesh - unless opcode already does that.
safemode wrote:All we will ever need is spheres of the actual radius of the ship and not the radius of the shield.
Well, the radius of the shield should be more closely matched to the radius of the ship - I've seen way oversized shield bubbles.
safemode wrote:in any case, removing the specialFX call
...is not possible.
Re-read my post. Spherical shields like those are a required feature.
safemode wrote:and re-using the regular mesh like opcode does is trivial, as is removing whatever collision detection against the shields there is. What wont be trivial is creating your shader to do something nifty with it.
Maybe not trivial for someone not used to working with shaders ;)
An extrusion shader is indeed rather trivial.
safemode wrote:note, obviously we wont be commenting out the stuff we aren't using in VS - the game as other mods may use it in their code, so we'll have to create an option to enable sphere_shields.
Good to know yo know ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

klauss wrote:Maybe not trivial for someone not used to working with shaders ;)
An extrusion shader is indeed rather trivial.
Question: What technique/shader is currently doing the shields?
I'm thinking that, for spherical shields, the sphericity could be made perfect in the shader, regardless of the number
of polygons, if there's a center and a radius passed to the shader.

EDIT:
gcc 4.4.1 craps out...

Code: Select all

[ 78%] Building CXX object CMakeFiles/vegastrike.dir/src/gfx/vdu.o
/home/d/vs/repo/trunk/vegastrike/src/gfx/vdu.cpp: In member function ‘void VDU::DrawManifest(Unit*, Unit*)’:
/home/d/vs/repo/trunk/vegastrike/src/gfx/vdu.cpp:1159: internal compiler error: Segmentation fault
Please submit a full bug report,
The offending line:

Code: Select all

void VDU::DrawManifest( Unit *parent, Unit *target )
{
LOL
I hit make again, and it passed.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

klauss wrote:
safemode wrote:I basically already did what you last said, and re-used the real mesh for shieldmesh and commented out the specialFX function call. No segfaults. The problem is that we still have sphere shield collision code elsewhere that will need to be turned off too so we dont get "shield hits" when we're not impacting the actual body of the ship.
AFAIK, when there's a shield mesh collisions are computed against that mesh. Or am I wrong?
Technically, shields should all be checked for collisions prior to the units. I dont believe this is currently done. What activates the shields is soley the damage function of the unit being hit in the hull, rather than a direct result of a collision. It should not be hard to fix, but for now it will involve using both the in-house sphere mesh collider and opcode for the shield meshes that exist in the right format. Until i create a sphere collider setup that can deal with sphere meshes properly.

safemode wrote:This should reduce collision load somewhat too since we wont have such large volumes to check collisions against.
That's not true. There will be less collisions, but collisions against spheres are trivial, and collisions against meshes are not. I propose to test against a sphere first, and if that test passes, refine the test by testing against the mesh - unless opcode already does that.
That's not opcode's job. that's Unit's Collide function's job. It has to ask (future tense) opcode's sphere collider if our ray or unit or other sphere is colliding or inside it and deal with what the results of that are ...
Of the many options it can consider, many cases will result in checking for the mesh collider afterward.

basically around line 170 in unit_collide.cpp is where i believe shield colliding needs to occur if we want realistic impacts against shields instead of fake aftereffects.

But the reduction in cpu load i was referring to was the minimization of the volume of sphere vs sphere collision detection. This allow us to avoid checking the mesh collider if a sphere vs sphere returns true to see if a real collision occurred. No collision is much less intensive than what happens if there is one. Smaller spheres == less collisions.


Even if we dont have shields that exist off the surface of a ship's mesh, we'd still use sphere vs sphere to some radius away from the ship so that we can avoid units penetrating other units prior to a physics from from the collidee unit. By reducing shield size though, we reduce this sphere of possible collision.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

I'm not understanding... this discussion sounds very confusing.


Sphere collision, as Klauss says, is trivial:
Sphere to sphere is the trivialest: If the sum of their radii is equal or less than the distance between their centers, they are colliding.
If it's greater they are not.

Point to sphere collision is just as trivial, actually: if the distance of the point to the center of the sphere is equal or less than the sphere's radius, the point is colliding.

Thus, if we want to test shield collision, and the shield is spherical (or tries to be), we don't need to show its mesh to opcode at all.


Separate issue:

I don't know if opcode does this already or not... Testing two units for collision can begin with a minimum sphere to minimum sphere (trivial) test: If the spheres don't collide, no need to test the meshes; otherwise test the meshes.

I say this is a separate issue because this collision test optimization would use the minimal sphere that contains the ship, as opposed to a possibly larger shield sphere; --unless, of course, we want to collide units shield to shield, --and we happen, or they happen, to be using spherical shields.


Separate issue:

Whether a mod uses spherical shields should indeed be a vegafig option. BUT, we might care to have three options: Yes, No, and PerCSV.
Some mod might want spherical shields for some race, and skin-tight shields for another.


For another issue:

Whether a shield lights up as a whole, or only locally, when shot at, could also use triple vegafig options.
And for the local option, perhaps a small billboard where the weapon hits would be more efficient than creating a whole shield mesh.
And for the global shield light-up with spherical shield option, as I mentioned before, the shader could make it look perfectly spherical even if it were as low poly as a cube.


Totally off topic:

What happens if you shoot your weapons when you are INSIDE the shield, could also use some vegafig options. In WC literature, for example, shields are penetrable at slow speed, so when attacking a very large dreadnought, you can enter the shield, approach the shield emitters, and shoot them off at point blank range.


EDIT:
In other news, I was unable to find black ships or any other anomaly after recompiling with the new cmake options for Release.
Not sure if that's good or bad.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

chuck_starchaser wrote:I'm not understanding... this discussion sounds very confusing.


Sphere collision, as Klauss says, is trivial:
Sphere to sphere is the trivialest: If the sum of their radii is equal or less than the distance between their centers, they are colliding.
If it's greater they are not.

Point to sphere collision is just as trivial, actually: if the distance of the point to the center of the sphere is equal or less than the sphere's radius, the point is colliding.

Thus, if we want to test shield collision, and the shield is spherical (or tries to be), we don't need to show its mesh to opcode at all.
the spheres you talk about when you talk about sphere vs sphere collisions dont use meshes at all. Now, we could get away with that for spherical shields, but some shields aren't and these are the shields that have meshes associated with colliders ...because they would need them. The spherical shields do not have associated colliders.

We're arguing for having non-spherical shields for all our units.
Separate issue:

I don't know if opcode does this already or not... Testing two units for collision can begin with a minimum sphere to minimum sphere (trivial) test: If the spheres don't collide, no need to test the meshes; otherwise test the meshes.

I say this is a separate issue because this collision test optimization would use the minimal sphere that contains the ship, as opposed to a possibly larger shield sphere; --unless, of course, we want to collide units shield to shield, --and we happen, or they happen, to be using spherical shields.
Opcode does what you tell it to do. Test two meshs, mesh vs ray, sphere vs sphere, ray vs sphere etc. This is the job of the collision detection system, which sits on top of opcode. Yes, we do this already. Though i believe we have a broken setup dealing with shields.
Separate issue:

Whether a mod uses spherical shields should indeed be a vegafig option. BUT, we might care to have three options: Yes, No, and PerCSV.
Some mod might want spherical shields for some race, and skin-tight shields for another.
we kinda do, It's actually a csv option per unit. We currently dont have a means of auto-generated skin-tight shields. This is the feature we are discussing.
For another issue:

Whether a shield lights up as a whole, or only locally, when shot at, could also use triple vegafig options.
And for the local option, perhaps a small billboard where the weapon hits would be more efficient than creating a whole shield mesh.
And for the global shield light-up with spherical shield option, as I mentioned before, the shader could make it look perfectly spherical even if it were as low poly as a cube.
for skin-tight, we're hoping to not use a separate mesh at all. We're looking at making everything skin-tight in VS the game, and simply paint effects on the ship's main mesh, with location of collisions provided by opcode as normal.
Totally off topic:

What happens if you shoot your weapons when you are INSIDE the shield, could also use some vegafig options. In WC literature, for example, shields are penetrable at slow speed, so when attacking a very large dreadnought, you can enter the shield, approach the shield emitters, and shoot them off at point blank range.
we check if we're inside the sphere and if so, dont apply damage to shields and instead apply it all to the ship.
EDIT:
In other news, I was unable to find black ships or any other anomaly after recompiling with the new cmake options for Release.
Not sure if that's good or bad.
That's expected. When you use unsafe options like -ffast-math and fassociative-math, and then vectorize them, it's going to be machine and particular software - dependent on if glitches occur.

I should probably put some of the unsafe options behind another toggle option.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Showing a skin-tight mesh is so easy it's a no-brainer. Just add a second pass to the technique and specify a shield.vp that simply moves all vertices by a set amount along the vertex normals. A one hour job.

Problem is performance impact: this would force a pixel per pixel overdraw of the whole ship; and not only that, but being a blend operation, it would have to get scheduled for the back-to-front sub-phase.

I think a better solution is to modify the existing vertex shaders to compute a line-of-sight shield thickness, and pass it to fragment shader, which then uses this thickness to compute an alpha amount by which to blend in blue light, or whatever, where a weapon hits. No blending pass; all blending done in code, IN the opaque fragment shader. Thing is, though, I would still need some way to know where the bolt hit the shield. Probably I would need an array of bolt hit locations and time-stamps, or precalculated impact age, to be able to fade them.

The impact locations could be mesh impact locations, as probably what I would do is show light as a function of inverse distance squared to the epicenter of the hit.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:LOL
I hit make again, and it passed.
It's quite common with internal compiler errors, they tend to relate to internal compiler state more than the source, so hitting make again tends to fix it.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

getting impact locations is easy. be them beams/bolts/ships/asteroid etc impacts. I can return the exact triangle where the collision happened. The thing we then want to think about if we go this route is what effect do we want. You talk about fading and that got me thinking what exactly are shields in VS and how do they work?...

I think in VS shields should be some form of reactive plasma field closely bonded to the hull of a ship. This adds a normally invisible thick layer of plasma around a ship which when comes into contact with something that has high kinetic or radiant energy it instantly becomes denser in that area rather than being pushed away (kinda like those liquids that become solid when a strong kinetic force is applied). So this plasma becomes a thick "liquid" at the point of impact in direct ratio to the amount of force being applied (be it kinetic or radiant) up to the maximum reactive force allowed by our current shield level and shield reserves.

What happens with shields then is that they slow down what passes through it in a proportion to the amount of energy of what they're slowing down has and how thick our shields are. This action effectively destroys the plasma state of the shield material involved, requiring replenishment from the shield emitters. That which passes through shields with some energy left however will still hit the hull, it will just either be moving much slower, or contain much less energy.

the sudden densifying of shield plasma would also be responsible for causing missiles to explode rather than pass through them and slowly hit the hull and explode there. Though, shield piercing torpedoes would probably exist.

Basically, i agree with a dense color that fades rapidly ... no full discernable shape to shields would be seen, just these impact sites until there is insufficient shield strength left and then no effect, just hitting the hull.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

The idea of using lights and a mesh can live with that - the shader would merely use light position as hit position and light brightness as hit strength, which fades over time.

It can apply whatever postprocessing to those values.

Fixed function is harder, but the techniques should be able to handle many setups. Including the one you're saying, btw, with proper blend mode magic.

So I'm still rooting for the current technique of drawing shields, coupled with better and more customizable defaulting of shield mesh, and the ability to specify a (possibly per-unit) shield gfx technique.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: feature freeze time

Post by Deus Siddis »

Are there any mods that really want spherical shields, specifically? Maybe pure collision meshes would do the trick.

VS only uses them on some ships, shields in the star trek universe look more elliptical, in star wars they are like interlocking plates or something, and I thought someone said someplace that they are aerodynamically-shaped like a lifting body in wing commander, for the purpose of atmospheric flight.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

@Deus: Were you talking about me saying that? The only mentions of shields that relate to atmospheric flight, in WC lore, that I've read, simply mention the shields affording some kind of protection from reentry burn; never heard anything about them being specially shaped, or producing aerodynamic lift; though I may have speculated about such thing in a drunken daze.
As for your question, I don't know; I do have an image in my head of seeing spherical-looking shields in some sci-fi, but don't remember when or where.
My room-mate is saying he thinks he saw spherical shields in some StarTrek movie.
klauss wrote:The idea of using lights and a mesh can live with that - the shader would merely use light position as hit position and light brightness as hit strength, which fades over time.

It can apply whatever postprocessing to those values.
I'm still not comfortable with the idea of having a entire mesh overlaid on another, even if it's temporary. But just placing a temporary light hovering over the ship's mesh would not give much of a sense of shieldness. So, I still think we should just spawn billboards when we want to show hits.
Fixed function is harder, but the techniques should be able to handle many setups. Including the one you're saying, btw, with proper blend mode magic.
Even for fixed function, a billboard would be the best solution I think.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:
klauss wrote:The idea of using lights and a mesh can live with that - the shader would merely use light position as hit position and light brightness as hit strength, which fades over time.

It can apply whatever postprocessing to those values.
I'm still not comfortable with the idea of having a entire mesh overlaid on another, even if it's temporary. But just placing a temporary light hovering over the ship's mesh would not give much of a sense of shieldness. So, I still think we should just spawn billboards when we want to show hits.
Well, I am :p
No, really. I've seen many games do something like that and it works perfectly fine. Of course the precise effect will need some artistic optimization, but from the performance standpoint it's not an issue by any chance.
I completely agree with billboards too - I'd do both, configurable so that every mod can have their own effect.
chuck_starchaser wrote:
Fixed function is harder, but the techniques should be able to handle many setups. Including the one you're saying, btw, with proper blend mode magic.
Even for fixed function, a billboard would be the best solution I think.
Depending on the desired effect, lighting and blending magic could perhaps achieve a similar effect in fixed function, perhaps not.
What's true is that GPUs using fixed function would feel the double processing of vertices harder - and they wouldn't be able to extrude the mesh either.
So... perhaps only billboards then.
But shader techniques would greatly benefit from the mesh. Alpha testing can alleviate overdraw issues.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

klauss wrote:Alpha testing can alleviate overdraw issues.
True. Still, the texels have to be read to be discarded. And vp load... some meshes are 50,000 to 100,000 polygons... (but some are 1500 polygons, so you can't arbitrarily decide to use the second LOD). And asking artists to produce shield meshes risks the kind of response I got with shininess maps, squared. I see this as a dangerous road to take. But alpha testing would help no matter which way we go.

Speaking of the devil... Xmesh has alpha testing threshold, but techniques don't. Thought I'd mention, since I think your intent is to move as much as possible from xmesh to technique, right?

And I have an idea for cloaking fades: Using noise as alpha, for alpha testing. Could be shader-generated noise, or come from the detail texture.
Post Reply