feature freeze time
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
@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.
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
I already had... but lets do it again, no sweat.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
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.
Build time is largely dominated by compiling C++ code.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
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.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: feature freeze time
That's a 100% valid and useful test result!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.
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.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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 :
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 ...
Code: Select all
laser_energy = explosion_energy / (4 * pi * r^2), or r = sqrt ( explosion_energy / (laser_energy*4*pi))
The same thing can be used for missiles or mines and counter measures ...
Ed Sweetman endorses this message.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
@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.
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
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.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
Perhaps we're tuned to different frequencies here...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.
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.
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:The occlusion is just a bonus feature.
Approximations are ok, but you leave so much "implied" that it seems trivial at a glance... and it's not.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.
Aren't you forgetting that opcode only handles collisions between collider pairs?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.
For bolts and beams I totally agree.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 explosions no, I don't.
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: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.
Not a bad one though. It just needs polishingsafemode 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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.klauss wrote:Perhaps we're tuned to different frequencies here...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.
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 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.
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.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:The occlusion is just a bonus feature.
Oh but it is, and it will be glorious you'll see.Approximations are ok, but you leave so much "implied" that it seems trivial at a glance... and it's not.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.
raycollider vs mesh collider. sphere collider vs mesh collider. What's the lack of pair here?Aren't you forgetting that opcode only handles collisions between collider pairs?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.
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.For bolts and beams I totally agree.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 explosions no, I don't.
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).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: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.
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.
Not a bad one though. It just needs polishing [/quote]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.
Ed Sweetman endorses this message.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: feature freeze time
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.
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.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.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.)
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.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.
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.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.
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.
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).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.
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.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: feature freeze time
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).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.)
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.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.
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.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.
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.
-
- Confed Special Operative
- Posts: 334
- Joined: Thu Jan 11, 2007 4:10 am
Re: feature freeze time
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.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: feature freeze time
Did it before I read this; working really good.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.
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.
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...
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.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.
Exactly.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
This should be up to the mod to setup; some will prefer to have constant thickness upgrades with increasing strength.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.
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.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.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: feature freeze time
Yeah, I believe Klauss is thinking along those lines.Deus Siddis wrote: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).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.)
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.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.
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.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.
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.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.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
For the curious:klauss wrote:My machine at home:safemode wrote:How long does compilation take for you? For me it's probably about 10 minutes. and my machine is years old.
$ 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.
make -j1: 20 minutes
make -j2: 17 minutes
15% improvement
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: feature freeze time
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.
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.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: feature freeze time
Isn't it mergeable right now?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.
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.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
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.
Why isn't it ready? I recall reading you had it working. Working is ready enough... isn't it?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
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.
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.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.
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.
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.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.
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.
-
- Elite
- Posts: 8014
- Joined: Fri Sep 05, 2003 4:03 am
- Location: Montreal
- Contact:
Re: feature freeze time
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.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.
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.The release can be made with ad-hoc auto shininess, which looks rather nice.
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
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.SVN isn't using it to motivate artists, but if no artist is motivated by release time I'd release anyway.
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?
I think Safemode was talking about vs_cubemap_gen. He doesn't know that you fixed the bug causing lines on reflections (ticket #14).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, 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.
Just help me with writing a python tool; then we can generate shininess for everything quickly.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.
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.))
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.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.
Heck, we could maybe write an auto-unwrapper that would do a better job than the ones out there... That would be something...
Good plan.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.
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.
Latest version of Cinemut Opaque
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.
Latest version of LaGrande noodleworks (scroll down).
An evolving La Grande How-To...
The non-working, but latest, CineMut test_bike
PU (Privateer: Parallel Universe's Home). WC or Privateer Drayman for you?
WCpedia --The Wing Commander Encyclopedia-- From Angel Deveraux through Belisarius to Zachary Banfeld...
WC Nexus forum, the Moonbase Tycho of WC fans.