feature freeze time

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
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: it's not about allocation, although it might work for a few things. It's about all the setup needed when creating units. There's already a "unit cache" to avoid a lot of that setup, but it's not enough I guess.

It's exploding units. They create tons of crates, so any unit cache just breaks there. That's another reason why we need dumber units, or even non-units.
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 »

before we jump to conclusions on what exactly is slowing things down lets get some profiles accumulated and looked at . No point in guessing when we can see for sure, or at least try to.
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 »

I already had... but lets do it again, no sweat.
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 »

klauss wrote:I already had... but lets do it again, no sweat.

It's really important that when profiling, you aren't taxing the graphics card in any way, as any cpu wait time is not logged at all. This includes waiting for GL, waiting for disk, etc. Also, non profiled code doesn't get timed, and i think this includes certain parts of the python scripts we run.

So any profile output is going to have to be carefully processed to give us an accurate picture of what needs improvement .

I was using the total_war_python mission to tax the system but that's pointless, it spends the vast majority of it's time taxing python. From now on i'm just going to use the regular game to profile.
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 »

Also, chuck. You may want to apt-cache search binutils-gold and we can work on supporting via an option the use of gold as our linker in linux land instead of regular gnu ld. gold is roughly 10x faster at linking c++ code than regular gnu ld (and just overall many times faster at linking anything that is an ELF object). It should be drop-in as i dont think we do much special in linux land with linking. I'll have to test it out and see if it drops compile times by much, if it's usable at all.
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 »

From my experience, linking takes only a couple of seconds, at the end of the process.
Build time is largely dominated by compiling C++ code.
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 »

I think once the shaders are stabilized, we're pretty much ready for a release after the appropriate docs are updated for the new version number and such.
maybe have any remaining artists get up to date on the new texture setup and produce some updated models or just textures and we can push this thing out.

In the meantime, I think i'm going to start replacing the rest of our physics system with opcode. Basically, this consists of the plane collider and ray collider

Ray collider obviously replaces beams and bolts. Eventually we can use it for navigation too.

Plane collider is used for determining if more complex collision detection is needed. ie. if a unit is found to be colliding or within a bounding box made of planes then it's within range of actually colliding with a unit. Check via mesh collider (tri-collider)
Not sure if that would be faster or not than a sphere collider ...guess only way to find out is doing both and testing.
All this is going to be going on in my branch only until we release.

edit: This has been on my todo list for a long time, i think i might actually have the time and concurrent motivation right now to get it done, so i'm going to whip it up hopefully this weekend and keep it on the side until after the release. I dont suspect drastic performance increases, since in-game collisions with anything happen rarely. The next area of focus other than rewriting bad code everywhere after release ought to be in allowing gcc to auto-vectorize our transforms for moving units around (which does happen a lot) and hopefully rewriting bad code claims other slow spots, or profiling sheds light on them.
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 »

safemode wrote:I was using the total_war_python mission to tax the system but that's pointless, it spends the vast majority of it's time taxing python. From now on i'm just going to use the regular game to profile.
That's a 100% valid and useful test result!
Why should there be so much use of Python in total war in the first place?
That's a BUG.

Linking takes two seconds for me.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

because that's it's purpose. it's total_war_python (which is what i was using) it's supposed to saturate python ...mostly through unit list traversals it seems.
we have multiple total_war scripts that supposedly aim at various things.

most of the /test missions are like that. i just have to see if it's at all possible to populate a system with ships and let them go at eachother with a minimal amount of python overhead.

"timing" the command while you profile is also helpful, even if it's done just by noting the time on a clock when you start it and stop it. As this would include wait time not included in the profile, essentially letting you see how much your graphics and disk and such are contributing to performance.

keep in mind, the /test missions and modules haven't been updated since before the last 0.4.3 release. Probably long before, so at least 4 years. Some may have been touched up a tad, but for the most part, they're all seriously outdated and most probably wont even do what they're supposed to (not that they're commented in any way ...bastards)

edit: despite the script's achingly obvious bugs (which it does have though heavy python use isn't one of them ) ..there's nothing like creating a thousand or so ships and then taking your Beholder into a swarm of them and death-raying them to oblivion. Though, another bug when dealing with these scripts that becomes obvious is that explosions seem to travel at light-speed ... so a swarm of units in a tight formation will all be destroyed at once if you destroy one of them. there's no kinetic collision at the cause of the explosions, it's treated like some type of beam weapon. Probably because explosion damage was a hack added well after the fact....and to avoid the complication of sphere collisions and calculating the kinetic force based on distance energy of explosion, momentum of receiving ship and shield strength etc.

correct explosion damage is something i hope to fix after i replace all the colliders in the game with opcode ones. It would be awesome to see at a safe distance a cap ship explode sending ships around it tumbling away/ pushed by the plasma shock front, with weaker ones exploding etc, and those further away buffeting it with shields and thrusters.
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 »

My solution to explosion damage would involve a sphere collider that has a radius equal to the some arbitrary minimum energy level we care about imparting... like say a laser hit. So whatever energy that is, we solve for r and create a sphere of that size. so something like this :

Code: Select all

laser_energy  = explosion_energy / (4 * pi * r^2),    or r = sqrt ( explosion_energy / (laser_energy*4*pi))
if that turns out to be too big, then we just use a larger energy cut-off. Anyways, this gives us a sphere collider to create. Now we check for units within or colliding with the sphere and for each unit, we create a ray-collider that will contact the actual mesh of the unit from the center of the sphere collider, providing the correct magnitude and direction of the force on the ship...as correct as we can get since we are rigid body simulating and so can't completely simulate a plasma's force across the entire facing side of a unit over time as it is being pushed.


The same thing can be used for missiles or mines and counter measures ...
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: that's oversimulation. Because the result would be incorrect due to simulation weaknesses, where an analytical solution is better given the trivial shapes involved (spheres).

A better solution, thus, is:

Create a local iterator (there's a spatially sorted structure) that iterates the objects within the sphere collider. Test all those units for collission against such sphere (the structure is an approximation, it produces false positives).

Compute the damage strength based on the distance of any colliding unit against the explosion center. Damage/force direction is the direction of the explosion's center.

Done. Ray colliders are not necessary. Unless you want to model ray occlusion, which is a tad harder than you portray it to be.

BTW: what explosion problem? I wasn't referring to damage from explosions, but the fact that exploding ships create lots of "cargo crate" units as leftover.
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 »

How do you propose to feed the damage function the correct face of the mesh to apply damage when all you have as the origin vector of the explosion and your own center to go by? What face of your ship is actually facing the explosion? A ray collider is just faster and easier than trying to figure what part of the ship actually received the brunt of the blast. The damage functions need a triangle to apply force and damage to, You're eventually going to recreate your ray anyway to figure out what triangle to feed the reaction to collision function so you are pushed in the correct direction and receive damage in the correct area.

The occlusion is just a bonus feature. It doesn't have to be perfect, because it's better than what we currently have, which is nothing, and it sorta works.

A ray that is blocked by one ship will terminate, but that is ship pushed and could still collide with the other ships behind it.

I think without the ray collider, you'll eventually have to re-create it within the react-to-collision functions in order to get the correct location for damage and the correct forces for kinetic energy. Since the ray is pointing to the center of the ship, and most ships are fairly symmetrical, it shouldn't result in much spinning or what not.

In any case, it's an idea ...not something i plan on doing soon. Not till after physics stuff is done for regular weapons and such.
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:How do you propose to feed the damage function the correct face of the mesh to apply damage when all you have as the origin vector of the explosion and your own center to go by? What face of your ship is actually facing the explosion? A ray collider is just faster and easier than trying to figure what part of the ship actually received the brunt of the blast. The damage functions need a triangle to apply force and damage to, You're eventually going to recreate your ray anyway to figure out what triangle to feed the reaction to collision function so you are pushed in the correct direction and receive damage in the correct area.
Perhaps we're tuned to different frequencies here...
I'm thinking explosions bigger than your ship, so damage should apply uniformly to everything facing towards the proper direction. No face computation required.

Now... you seem to be thinking of small explosions. Very small. Small enough to only affect a face.

In any case, no, you wouldn't need to recreate the collider. Not at all. A simple iteration over all systems, computing distance to the explosion and skipping the subsystem if the distance is too far would be enough. Since only systems get damaged, not faces.

Unless you're proposing a drastic restructuring of the damage model (drastic as in totally revolutionary, where you deform meshes and whatnot). Which I don't think is the case.
safemode wrote:The occlusion is just a bonus feature.
Man, you're grossly underestimating the work ray occlusion involves. It's not a lot of code, but to get ray occlusion you have to test the ray against ALL ships in the explosion's vecinity, not just the one being damaged. It's a huge computational complexity differential... and if you don't want N^2 complexity (which wouldn't be terribly bad given that one would expect N to be small, unless it's a huge explosion, in which case we could disable occlussion altogether), things get terribly more complicated.
safemode wrote:It doesn't have to be perfect, because it's better than what we currently have, which is nothing, and it sorta works.
Approximations are ok, but you leave so much "implied" that it seems trivial at a glance... and it's not.
safemode wrote:A ray that is blocked by one ship will terminate, but that is ship pushed and could still collide with the other ships behind it.
Aren't you forgetting that opcode only handles collisions between collider pairs?
safemode wrote:I think without the ray collider, you'll eventually have to re-create it within the react-to-collision functions in order to get the correct location for damage and the correct forces for kinetic energy.
For bolts and beams I totally agree.
For explosions no, I don't.
safemode wrote:Since the ray is pointing to the center of the ship, and most ships are fairly symmetrical, it shouldn't result in much spinning or what not.
But you will get spinning when the hit happens to hit an assymetrical point, which will happen more often than you'd like. Mostly because collider meshes will be grossly approximated and polygon reduced.
safemode wrote:In any case, it's an idea ...not something i plan on doing soon. Not till after physics stuff is done for regular weapons and such.
Not a bad one though. It just needs polishing ;)
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 »

klauss wrote:
safemode wrote:How do you propose to feed the damage function the correct face of the mesh to apply damage when all you have as the origin vector of the explosion and your own center to go by? What face of your ship is actually facing the explosion? A ray collider is just faster and easier than trying to figure what part of the ship actually received the brunt of the blast. The damage functions need a triangle to apply force and damage to, You're eventually going to recreate your ray anyway to figure out what triangle to feed the reaction to collision function so you are pushed in the correct direction and receive damage in the correct area.
Perhaps we're tuned to different frequencies here...
I'm thinking explosions bigger than your ship, so damage should apply uniformly to everything facing towards the proper direction. No face computation required.

Now... you seem to be thinking of small explosions. Very small. Small enough to only affect a face.

In any case, no, you wouldn't need to recreate the collider. Not at all. A simple iteration over all systems, computing distance to the explosion and skipping the subsystem if the distance is too far would be enough. Since only systems get damaged, not faces.

Unless you're proposing a drastic restructuring of the damage model (drastic as in totally revolutionary, where you deform meshes and whatnot). Which I don't think is the case.
I'm talking about faces as a point of reference for the push, not necessarily for only damage. You can't push against a side of the ship, that's not how we move things.

I'm simply taking the guess work of how to push the ship with the explosion out of the "react to collision" function and into a collider where it belongs rather than hack the reaction function to decide the force it's reacting to.
safemode wrote:The occlusion is just a bonus feature.
Man, you're grossly underestimating the work ray occlusion involves. It's not a lot of code, but to get ray occlusion you have to test the ray against ALL ships in the explosion's vecinity, not just the one being damaged. It's a huge computational complexity differential... and if you don't want N^2 complexity (which wouldn't be terribly bad given that one would expect N to be small, unless it's a huge explosion, in which case we could disable occlussion altogether), things get terribly more complicated.
You're overcomplicating it. A single pass through all units within the sphere collider of the explosion is all that's needed. Each unit would get a ray collider, if their ray collider hits something before it hits the unit, it's ignored. This is the approximation, since the ray collider attacks the centers of units within the sphere collider here, we pretend that the unit or object it hit is blocking the force of the blast. We then leave the unit that did get hit up to either taking the force or being pushed back into the units behind it or exploding.

safemode wrote:It doesn't have to be perfect, because it's better than what we currently have, which is nothing, and it sorta works.
Approximations are ok, but you leave so much "implied" that it seems trivial at a glance... and it's not.
Oh but it is, and it will be glorious :) you'll see.

safemode wrote:A ray that is blocked by one ship will terminate, but that is ship pushed and could still collide with the other ships behind it.
Aren't you forgetting that opcode only handles collisions between collider pairs?
raycollider vs mesh collider. sphere collider vs mesh collider. What's the lack of pair here?

safemode wrote:I think without the ray collider, you'll eventually have to re-create it within the react-to-collision functions in order to get the correct location for damage and the correct forces for kinetic energy.
For bolts and beams I totally agree.
For explosions no, I don't.
I believe you will, and it will be a huge hack to do it without colliders. but we'll see.. it's gonna be a while before things get to that point anyway.
safemode wrote:Since the ray is pointing to the center of the ship, and most ships are fairly symmetrical, it shouldn't result in much spinning or what not.
But you will get spinning when the hit happens to hit an assymetrical point, which will happen more often than you'd like. Mostly because collider meshes will be grossly approximated and polygon reduced.
Collider meshes are exact replicas of the unit mesh. Not gross approximations, and they dont LOD, and neither do unit meshes (at least none in the game so far).


We'll have to see how they behave when hit. it wont be a big deal to shoe-horn in a special case situation for explosions if we need to.

I'm just trying to avoid dynamically creating a perp plane collider for every unit within the sphere and having the ray hit the plane and the mesh and if it hits both, we are pushed in the correct direction since we ignore the face hit and use only the plane hit, and we know what faces of our mesh got the brunt because we compare the plane collider side that got hit against the mesh collider and all faces on the same side receive damage ....this includes shields and such on that side.

If it starts getting too complicated, we're going to dumb it down, but the way it's currently done will likely become broken as i remove our in-house bsp crap. so in any case, something new will likely replace the way it's done now.
safemode wrote:In any case, it's an idea ...not something i plan on doing soon. Not till after physics stuff is done for regular weapons and such.
Not a bad one though. It just needs polishing ;)[/quote]
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 »

For computing reactions to hits, we don't need a triangle to apply force to; all we need is the point of impact and the vector of the hit. As far as physics is concerned (unit getting pushed, spinning), it doesn't matter if what got hit was a radiator, an engine, or a decorative aileron; all that matters is the energy, direction, and where did it hit relative to the center of inertia.
Showing localized damage, that's another story; a long one. (Perhaps some day we could implement a 16x16 texel per-ship-instance texture that is writeable and acts as a damage texture mask.)

As far as damage models are concerned, shortcuts are taking their toll. If I'm shooting at a station, it's okay that it takes long to get through the shield; --it's supposed to regenerate, and presumably distribute damage energy; but once the shield is gone, armor should be susceptible to cumulative, localized damage. So, a narrow beam weapon should get through faster than a wide beam weapon, all other things being equal ***as long as you keep your aim steady*** and of course it should be visible; but that's a hard problem.
And then the question is, what's the consequence of puncturing through the armor? Does the ship or station explode right away?
Well, at least we should have damage sophistication of the level of Starcraft, which differentiated piercing from explosive damage.
There's also the issue that currently ship size has no bearing on armor strength. Getting through the armor of a carrier or a fighter takes the same number of shots if they are both "isometal", say. Pretty ridiculous. So the only ways to differentiate capships from tiny ships is via the shields and the core strength.
Another issue is that heatseaking missiles don't need a view of the rear of a ship to get a lock like they should; they work just like image recognition or FF missiles.

First on my to-do list for after release is refactoring of Unit. I think that the largest number of other ideas for improvements and refactorings are dependent on sanitizing Unit.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

time to make yourself a new cmake build dir and check out the new ccmake setup i whipped up. Should be a noticeable improvement in ease of use.

Use the cpu opts too, they aren't going to hurt (unless they cause a segault, in which case let me know...but no issues on my end.


That should be it as far as source code merges from my branch for a bit. I'm gonna be workong on replacing the bsp sphere and ad-hoc ray collider setup with opcode's and that's gonna be fun.
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 »

chuck_starchaser wrote:For computing reactions to hits, we don't need a triangle to apply force to; all we need is the point of impact and the vector of the hit. As far as physics is concerned (unit getting pushed, spinning), it doesn't matter if what got hit was a radiator, an engine, or a decorative aileron; all that matters is the energy, direction, and where did it hit relative to the center of inertia.
Showing localized damage, that's another story; a long one. (Perhaps some day we could implement a 16x16 texel per-ship-instance texture that is writeable and acts as a damage texture mask.)
Right now we emit "vapor" particles localized somewhat to where damage is occuring. This is cpu intensive however, as the stupid particles are tracked and moved manually. Not sure why that can't go on in GL and be forgotten about.
As far as damage models are concerned, shortcuts are taking their toll. If I'm shooting at a station, it's okay that it takes long to get through the shield; --it's supposed to regenerate, and presumably distribute damage energy; but once the shield is gone, armor should be susceptible to cumulative, localized damage. So, a narrow beam weapon should get through faster than a wide beam weapon, all other things being equal ***as long as you keep your aim steady*** and of course it should be visible; but that's a hard problem.
A laser cutter like the Shadows had in B5, hrmm . The issue here is that beams have no cross section, they are simply vectors with no volume. This can be accomplished either by giving them a mesh, or by having a special var to go along with energy levels to describe the radius of the beam.
And then the question is, what's the consequence of puncturing through the armor? Does the ship or station explode right away?
Well, at least we should have damage sophistication of the level of Starcraft, which differentiated piercing from explosive damage.
There's also the issue that currently ship size has no bearing on armor strength. Getting through the armor of a carrier or a fighter takes the same number of shots if they are both "isometal", say. Pretty ridiculous. So the only ways to differentiate capships from tiny ships is via the shields and the core strength.
the armor material should describe energy absorption rate per square meter or some other increment that is convenient and tensile strength for dealing with collisions. Really, how thick you want the armor should be set in the csv file for each unit and be per-material. You'd need less inches of isometal as you would weaker metals. etc. It might even be cool to have the game auto-set you at the minimum amount of armor when you upgrade (so you dont increase mass (maybe even lose some) to maintain the same strength level) and give you the option of increasing the strength level for added cost.

So if i have a llama with poly-steel, i upgrade to isometal, it'll be a very thin layer of isometal to match the strength i had with polysteel, but my llama will be faster maneuvering since i'm much lighter. I could opt to add more isometal armor though to some set max (so it's not unbelievably thick) and increase my strength at the cost of mass increase.
Another issue is that heatseaking missiles don't need a view of the rear of a ship to get a lock like they should; they work just like image recognition or FF missiles.
Your ship radiates heat all over...the hull is a heatsink, the shields probably function as heat convertors at least partially. So it's not too far fetched to think that a missile can lock onto you from in front. Now, should it hone in on your rear when it is visible to it, hell yes, it should lock onto the highest heat source within it's targetting cone (a cone that should be set when you launch it).

Personally, i think missiles move _Way_ too fast in the game. Extremely too fast to do any sort of maneuvering that would cause a ship at any appreciable distance to have trouble avoiding it.
Ed Sweetman endorses this message.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: feature freeze time

Post by Deus Siddis »

chuck_starchaser wrote: Showing localized damage, that's another story; a long one. (Perhaps some day we could implement a 16x16 texel per-ship-instance texture that is writeable and acts as a damage texture mask.)
There's also the idea of ships being built out of separate meshes that show localized damage and apply it to the relevant sub systems (like a thruster or sensors).
There's also the issue that currently ship size has no bearing on armor strength. Getting through the armor of a carrier or a fighter takes the same number of shots if they are both "isometal", say. Pretty ridiculous. So the only ways to differentiate capships from tiny ships is via the shields and the core strength.
Maybe you could just have a greater number of armor upgrades, distinguished mostly by thickness, with the thicker ones taking too much space and mass to be fitted on to smaller craft.
Another issue is that heatseaking missiles don't need a view of the rear of a ship to get a lock like they should; they work just like image recognition or FF missiles.
Might not want to change this in the VS mod though for a few realism reasons. For example, modern heatseekers are supposed to be sensitive or smart enough that they track without a direct shot at the thrusters. And then you have thrusters on all sides of ships and the vacuum-heat-dissipation issue. So I'd apply it to the privateer mods exclusively.

For VS the most serious issue with missiles is that there seems to be no way to evade them at all.

Maybe some combination of evasive action and point defense would make sense. You try to fly away from the missiles so that your anti-missile defenses have the greatest amount of time and the easiest shot at taking them out. Perhaps the missiles themselves also have to slow down by taking their own evasive maneuvers to avoid your point defense. Maybe add to that a reasonably good possibility of allowing players with a good aim to shoot down missiles with their own manually controlled guns.
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Re: feature freeze time

Post by Neskiairti »

there is always the possibility of handling 'armor' as sub-objects similar to turrets and what not. It wouldnt even have to be visible, just a collision mesh. if its reduced to 0 hp in one section, if that section is hit again, something in the ship goes kaboom :p maybe not entire destruction, but knocking systems out.
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:time to make yourself a new cmake build dir and check out the new ccmake setup i whipped up. Should be a noticeable improvement in ease of use.

Use the cpu opts too, they aren't going to hurt (unless they cause a segault, in which case let me know...but no issues on my end.
Did it before I read this; working really good.
Right now we emit "vapor" particles localized somewhat to where damage is occuring. This is cpu intensive however, as the stupid particles are tracked and moved manually. Not sure why that can't go on in GL and be forgotten about.
:D
You eternally overestimate GL, Safemode; GL is a rendering layer, but the cpu has to tell it what to render where. Well, there's a feature for vertex shaders called "instancing" which can make copies of things in the gpu, I believe, and we're not using it currently. Maybe...
A laser cutter like the Shadows had in B5, hrmm . The issue here is that beams have no cross section, they are simply vectors with no volume. This can be accomplished either by giving them a mesh, or by having a special var to go along with energy levels to describe the radius of the beam.
We could conceivably deduce beam cross section from other weapon stats, such as range and rate of decay; without having to create a new csv column.
the armor material should describe energy absorption rate per square meter or some other increment that is convenient and tensile strength for dealing with collisions. Really, how thick you want the armor should be set in the csv file for each unit
Exactly.
and be per-material. You'd need less inches of isometal as you would weaker metals. etc. It might even be cool to have the game auto-set you at the minimum amount of armor when you upgrade (so you dont increase mass (maybe even lose some) to maintain the same strength level) and give you the option of increasing the strength level for added cost.

So if i have a llama with poly-steel, i upgrade to isometal, it'll be a very thin layer of isometal to match the strength i had with polysteel, but my llama will be faster maneuvering since i'm much lighter. I could opt to add more isometal armor though to some set max (so it's not unbelievably thick) and increase my strength at the cost of mass increase.
This should be up to the mod to setup; some will prefer to have constant thickness upgrades with increasing strength.
Your ship radiates heat all over...the hull is a heatsink, the shields probably function as heat convertors at least partially. So it's not too far fetched to think that a missile can lock onto you from in front. Now, should it hone in on your rear when it is visible to it, hell yes, it should lock onto the highest heat source within it's targetting cone (a cone that should be set when you launch it).

Personally, i think missiles move _Way_ too fast in the game. Extremely too fast to do any sort of maneuvering that would cause a ship at any appreciable distance to have trouble avoiding it.
You're talking about vegastrike the game; not the engine. The engine needs the feature of knowing where you are relative to a bogey and have that affect weapon lock. In PU, ships only have back-facing heat signatures. We'd like to emulate the original Privateer game, in which you had to get behind a bogey to lock a heatseeker. The same could go for other forms of radiation. Ships emit a stronger microwave signature towards the front, if they use radar, for example. If in the future we implement stealth mode flying, which is something we've always wanted for PU, and would be great for vegastrike too, directional signatures are important and add a lot of depth to the game. In the old dos game TFX, some missions had you bomb ground facilities flying a stealth fighter at night, and there could be several enemy planes in the area. Avoiding detection could be extremely tricky. Basically, you had to fly loops and circles in a complex dance to avoid showing the heat of your engines to the bogeys; --always keep them to your right or to your left--; and when I couldn't, I'd temporarily turn off the engines and glide for a bit, then turn them back on when it was safe again. That's a kind of sophistication of gameplay I'd like to see in vegastrike and PU.
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 Siddis wrote:
chuck_starchaser wrote: Showing localized damage, that's another story; a long one. (Perhaps some day we could implement a 16x16 texel per-ship-instance texture that is writeable and acts as a damage texture mask.)
There's also the idea of ships being built out of separate meshes that show localized damage and apply it to the relevant sub systems (like a thruster or sensors).
Yeah, I believe Klauss is thinking along those lines.
Maybe you could just have a greater number of armor upgrades, distinguished mostly by thickness, with the thicker ones taking too much space and mass to be fitted on to smaller craft.
Yep. Well, this needs to be thought out and designed in a mod-agnostic way. The engine should not decide for the mods; it should simply expose choices, while hopefully rejecting inconsistencies.
Another issue is that heatseaking missiles don't need a view of the rear of a ship to get a lock like they should; they work just like image recognition or FF missiles.
Might not want to change this in the VS mod though for a few realism reasons. For example, modern heatseekers are supposed to be sensitive or smart enough that they track without a direct shot at the thrusters. And then you have thrusters on all sides of ships and the vacuum-heat-dissipation issue. So I'd apply it to the privateer mods exclusively.[/quote]The latter are in fact my concern.
For VS the most serious issue with missiles is that there seems to be no way to evade them at all.

Maybe some combination of evasive action and point defense would make sense. You try to fly away from the missiles so that your anti-missile defenses have the greatest amount of time and the easiest shot at taking them out. Perhaps the missiles themselves also have to slow down by taking their own evasive maneuvers to avoid your point defense. Maybe add to that a reasonably good possibility of allowing players with a good aim to shoot down missiles with their own manually controlled guns.
IOW, what we need from the engine is a more comprehensive interface in regards to missiles, missile locks, missile evasion, as well as weapons, armor and damage models in general. Presently the interface is too clunky and hard-codey.
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 »

klauss wrote:
safemode wrote:How long does compilation take for you? For me it's probably about 10 minutes. and my machine is years old.
My machine at home:

$ time make -j2
...
real 17m39.868s
user 31m41.639s
sys 1m20.697s

That's hyper threading, no real dual core here.
Hyper threading reduces build time by about 10%, in case you're wondering.
For the curious:

make -j1: 20 minutes
make -j2: 17 minutes

15% improvement

:D
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 »

Ok.

Lets get absolutely serious about this for a second. How long until we think we're going to actually roll up and put out a release ? 1 week? 1 month?

While, ray collisions isn't fully done ..it's fairly close and the diff between my branch and trunk is growing to probably 50 files now. Maintaining a clean merge over the course of another month may easily get very ugly if code cleanups persist and we start micro-optimizing.

Even if we documented things up, I really dont see us being ready for an actual release soon. The artwork needs time to catch up to the shader work. The beam/bolt drawing issue needs to get resolved. The Removal of the Nebula unit should be done. Our background generator should be finished. The release should be something we can stand behind, not kicked out in an incomplete state just so we can get onto more exciting things. I'm not saying we should rewrite entire subsystems to correct the ugliness there, but

I'm not ready to merge the ray collider to trunk yet, but it isn't going to be long before it's finalized ...and then i'm sure we wont be any closer to a release than we are now especially with the lack of artists active anymore. Chuck can't do everything by himself and i'm afraid i'm useless at anything art related.

0.5.1 is basically done. Has been for a while. 0.5.2 and 0.5.3 is where i think we're at now. generally. Maybe we should aim for 0.5.3 to be the next release and go that route, or modify the roadmap and aim for 0.5.2. i dont know. All i do know is that the /data side is seriously behind the engine side and we really can't release while it's like that.
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:While, ray collisions isn't fully done ..it's fairly close and the diff between my branch and trunk is growing to probably 50 files now. Maintaining a clean merge over the course of another month may easily get very ugly if code cleanups persist and we start micro-optimizing.
Isn't it mergeable right now?
safemode wrote:Even if we documented things up, I really dont see us being ready for an actual release soon. The artwork needs time to catch up to the shader work. The beam/bolt drawing issue needs to get resolved. The Removal of the Nebula unit should be done. Our background generator should be finished. The release should be something we can stand behind, not kicked out in an incomplete state just so we can get onto more exciting things. I'm not saying we should rewrite entire subsystems to correct the ugliness there, but
Perhaps you're putting too many features for the release. I believe bug squashing is the most important thing for the release. The most important graphical bugs have been squashed, namely those cubemap issues.

The release can be made with ad-hoc auto shininess, which looks rather nice. SVN isn't using it to motivate artists, but if no artist is motivated by release time I'd release anyway.

The beam/bolt drawing issue was deemed unimportant already, or that I thought.

The removal of the nebula unit should be made into a ticket and prioritized - I don't believe it's important enough to block the release for it.

The background generator idea was explicitly stated for after the release. For the release, the idea was simple foggy systems as you explained, with radar interference and that kind of stuff.
safemode wrote:I'm not ready to merge the ray collider to trunk yet, but it isn't going to be long before it's finalized
Why isn't it ready? I recall reading you had it working. Working is ready enough... isn't it?

Anyway, it's cleanup. If it isn't ready, don't merge, lets release without it. Although it removes duplication of functionality and the need for bsp files, so it's important, it still is invisible to users except perhaps a performance increase.
safemode wrote: ...and then i'm sure we wont be any closer to a release than we are now especially with the lack of artists active anymore. Chuck can't do everything by himself and i'm afraid i'm useless at anything art related.
About the artsy stuff, I believe I could produce shininess maps for units. That's about as artsy as I get, though. Lack of artists is real, and troublesome.

There's a technical aspect though that I could affront, and that's mesh quality. Some meshes are simply lacking LODs or proper smoothing - perhaps I could address that, but I certainly won't be fast in that department. It may take a week or more per unit, that's a lot.
safemode wrote:0.5.1 is basically done. Has been for a while. 0.5.2 and 0.5.3 is where i think we're at now. generally. Maybe we should aim for 0.5.3 to be the next release and go that route, or modify the roadmap and aim for 0.5.2. i dont know. All i do know is that the /data side is seriously behind the engine side and we really can't release while it's like that.
What's more important than features for the release is being able to build in the three supported platforms. Linux, is ok. Windows, is on its way, but slow. Mac... no clue whatsoever.

We need testing just as well. We should release a beta, test, fix serious bugs, then re-release. A branch has to be kept with source and data for the release so bugfixing can happen on that proven branch while development for the next release continues.

So we need a plan. We had a feature plan, now we need a release plan.

BTW: good thing you mentioned that roadmap, it had left my mind. Release 0.5.1 is very close, which is ever so good.

Lets squash all the serious bugs and release a beta as soon as there's a release plan, that will give us quick feedback on the bugs that need fixing. Lets also make it clear: the release is the first release in a faster release cycle, it may not be a huge change from 0.5.0 in terms of gameplay, it may or may not, I forgot already how 0.5.0 was, but it's not the point. The point is to release more often, get more feedback, and actually fix the bugs reported.
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 believe bug squashing is the most important thing for the release. The most important graphical bugs have been squashed, namely those cubemap issues.
Tickets #7 and #17 need to be resolved for a release. Yesterday I had 3 white starts in a row. If a new player would get 3 white starts in a row, he/she would assume that's what the game is supposed to look like and throw it into the recycling bin.
The release can be made with ad-hoc auto shininess, which looks rather nice.
I thought you agreed to my plan. If we keep postponing the requiring of shininess maps, we are NEVER going to have them. It's not "just for the release", because artists, by definition, will get the downloadable release, rather than svn, and will test their ships on that.
We have to, sooner or later, make models without shininess maps look bad. Do you agree? If that time is not now, would you tell me why, and when would be a better time? I'd say the time is NOW. Precisely because Fendorin disappeared and we have NO artists; so maybe the new artists we get can be more easily persuaded to do things right.
I think we have two choices:
  • We make all units look bad, or...
  • We fix them
But continuing to hack the shaders in order to hide an artistic problem is like abusing alcohol or crack. We need to stop this shit.
SVN isn't using it to motivate artists, but if no artist is motivated by release time I'd release anyway.
I agree, but without cheating in the shaders. And that cheating looks like shit, anyways. To cheat right you need to compare diffuse and specular saturations, and determine whether you have a dielectric. Dielectrics should look shiny even with low specular values.
How about we write a python program to generate the shininess map?
My problem is getting started with it. Just write a python program that does anything, like add textures A and B and write to C; and then I'll write the real algorithm.
Deal?
The background generator idea was explicitly stated for after the release. For the release, the idea was simple foggy systems as you explained, with radar interference and that kind of stuff.
I think Safemode was talking about vs_cubemap_gen. He doesn't know that you fixed the bug causing lines on reflections (ticket #14).
Safemode, we can release with the current cubemaps. Work on vs_cubemap_gen continues, as it will be MUCH better than ATI's, but the urgency is off it.
About the artsy stuff, I believe I could produce shininess maps for units. That's about as artsy as I get, though. Lack of artists is real, and troublesome.
Just help me with writing a python tool; then we can generate shininess for everything quickly.
Make it easy to use, though; if not graphical, at least with autocompletion, to quickly be able to browse for the input texture. Make it remember the previous input, so one doesn't have to go all the way from /usr/bin/shinegen/textures to the masters repo every frigging time. I can write a good shininess algorithm in no time; but all the plumbing is what kills me.
Heck, I'll make it generate a normalmap, too, while I'm at it.
((But if I do this, we'd better have that separation done about keeping mesh headers as text; otherwise it will be a huge amount of work to change the bfxm's to call the normalmaps.))
There's a technical aspect though that I could affront, and that's mesh quality. Some meshes are simply lacking LODs or proper smoothing - perhaps I could address that, but I certainly won't be fast in that department. It may take a week or more per unit, that's a lot.
All the meshes are complete disasters; but there's nothing we can do quickly about them. This puts a damper on baking AO's, but it doesn't hurt generating shininess maps; so we can leave mesh rework for the future.

Heck, we could maybe write an auto-unwrapper that would do a better job than the ones out there... That would be something...
We need testing just as well. We should release a beta, test, fix serious bugs, then re-release. A branch has to be kept with source and data for the release so bugfixing can happen on that proven branch while development for the next release continues.
Good plan.

I'd also like to try the engine on PU (maybe VT also); but I want to finish organizing the shaders first, and port them over.
Post Reply