Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Krackers87 on June 16, 2007, 02:22:07 am
-
Thinking about back in the day when everyone clamored for geomod tech in FS i came up with an intresting idea. Now i dont know the limitations on how far this can go but i do remember there being a way to create non-targettable but destroyable subsystems. So combining the two i have come up with the idea that we can make parts of ships destructible (chunks of ships, wings, atenea and such) by making these chunks of ships seperate subsystems, while making the subsytem debris LOD consisting of broken beams, pieces of hull and wires and jagged edges to give that "damn i just blew that dudes wing off" look.
Feel free to slap me if this has already been conceived or is ludicrous.
Following a hopefuly positive response i will attempt to make a demonstration piece out of the perseus.
-
This would be cool... if anyone could implement it. ;7 Having ships just spark & steam, and then after a certain amount of damage, just explode, isn't that realistic... Also, having a SRed cut into another ship, and then nothing to show for it... If this could be implemented, then I think everyone would like it...
-
well the responcability is on the modeler to do all that, no reason for you to even post that in this forum.
-
That sounds a lot like how freelancer does it. Freelancer's models have submodels defined that function in a similar manner to FS2's subsystems. While they lacked detail, it is certainly plausible. But Bobboau is right - it requires no new code, just more effort on part of the modeller.
-
well the responcability is on the modeler to do all that, no reason for you to even post that in this forum.
Ah, so I take it that non-targettable, destroyable subsystems are fully supported by the SCP engine, then, right, Bobboau? All we need is a modeller to create the models, the code is already working. Go ahead with that Perseus, Krackers. :nod:
-
I keep hearing people talk about this idea, but nobody does it...
The practical reason is that subsystems have to be rendered individually, meaning higher system requirements or fewer ships. That doesn't stop it being used in missions with few ships or on missions with only a few of the class with the destroyable subsystems.
-
Following a hopefuly positive response i will attempt to make a demonstration piece out of the perseus.
:lol: Just do it, Krackers... :)
-
I've seen this idea pop up a number of times, and to put it simply; it's not going to happen any more than the geo-mod itself will. In fact I'd go as far as to say it's even less likely to happen.
Yes we have the ability to do it, but has anyone actually tried doing it? It doesn't just require a bit more effort on the modelers part, it requires what would probably average about twice as much work for an inferior result.
If you split up ships into untargetable, destroyable objects like this, you:
-----------------------------------------
1) Ruin the smoothing - without a lot of effort and tinkering, the seams will show up. Especially when seen at a distance I'd expect.
2) Will have a messed up ship radius which will ruin the targeting brackets around the ship (they'll be far too small) and collision detection (if another object isn't within this ship radius, it's not counted as being close enough to the ship to hit, even though the destroyable subobjects of that ship may easily protrude from that radius, effectively making them unhittable by anything outside the radius)
3) Slow down the rendering of the ship, because the game now has to render more polygons (the invisible interior ones) that are split over many subobjects (the switching to each new subobject will be a small drag, with the cumulative effect being relatively nasty) just to render the ships basic hull.
4) Open yourself to a whole host of hierarchy setup problems and bugs. (mainly because of the following point)
5) Would have to carefully plan each and every model to decide which chunks can be destroyed, and everything that would be attached to that chunk. For instance, if you blow off the neck of a Ravana, what happens to the head? If you destroy the base of a Sathanas arm, what happens to the rest of the arm? (this would screw up a number of campaign missions too incidentally)
6) Would need to work around or take into account turrets, so that the hull beneath them can't be destroyed without the turret also being destroyed, which means more major hierarchy headaches and balance issues.
7) Would probably need extra textures to put on the internal damaged areas, further (probably drastically) slowing the rendering down.
8) In all likelyhood would just need to use live debris for a lot of parts that would look ridiculous if they just went *poof*, so you can have the destroyed piece float away. This is the technique the Boadicea uses, and as it stands, it is the most complex original [v] pof by a long way. It will be a nightmare to HTL when the time comes for whoever is doing it. Oh yes, and this will add even more hierarchy complexity, and more stuff to build. ;)
9) All of the above points take time (and a lot of it at that) to take care of, and so each ship takes even longer to be released.
10) All of the huge effort you've taken to do all of the above points will probably not be noticed by 95% of players. Don't believe me? How many people here know that the HTL Hecate has destroyable engine and conning tower subobjects? And of those who do know, how many of you actually first noticed it in game rather than (as I did) looking at the pof? :p
-----------------------------------------
There are probably a lot of other potential issues that I've forgotten, but finally; almost no-one gives ships good debris as is (much to my disappointment :( ).
As such, there is no way they're going to go to the huge amount of extra effort it would take to do this virtual geomod technique.
Don't get me wrong in all this - non targetable, destroyable subobjects are great if used appropriately. It's just that using them to fake a geomod though is not one such use. ;)
-
Slow down the rendering of the ship, because the game now has to render more polygons (the invisible interior ones)
Shouldn't culling solve that? Or does FS2 for some strange reason not use culling?
-
not everyone who talks like they know what they are talking about actually does.
A)yes, culling would prevent drawing of backfaced polies.
B)the slowdown would not be caused by the increase of polygons, but rather by the increase of subobjects, the increase of subobjects is almost entierly the source of slowdown, the increase of polygons will be if anything barely noticeable in terms of how fast it draws. which is something I've tried to explain to everyone for like five years now, but a lot of people still don't get it (I'm looking at you Babylon project)
-
:lol:
In the case of subobjects, maybe there would be a way to speed up nontargetable subobject processing or is this just that generic "FS2 has horrible collision detection" problem again?
-
1) Ruin the smoothing - without a lot of effort and tinkering, the seams will show up. Especially when seen at a distance I'd expect.
I can't really speak authoritatively on this one (Some start... :p) but that seems more like a model quality control concern. Yes, even without this consideration, some models still don't look that great.
2) Will have a messed up ship radius which will ruin the targeting brackets around the ship (they'll be far too small) and collision detection (if another object isn't within this ship radius, it's not counted as being close enough to the ship to hit, even though the destroyable subobjects of that ship may easily protrude from that radius, effectively making them unhittable by anything outside the radius)
Ship radius appears to be stored in the model file and determined by the application which generates the POF file. All hittable subobjects should be inside that radius, regardless of whether or not the person is going for virtual POF. If #2 is actually an issue at all, you probably need to talk to Kazan.
3) Slow down the rendering of the ship, because the game now has to render more polygons (the invisible interior ones) that are split over many subobjects (the switching to each new subobject will be a small drag, with the cumulative effect being relatively nasty) just to render the ships basic hull.
This is partly true but not for the reasons you give. Slowdown will occur because every subobject must be rendered separately right now, because it may move or get destroyed. So for every subobject you add, you add [Number of subobject textures * (Number of map types - diffuse, glow, or shine) + ((Current number of applied lights - 8)/8)] passes. Or something like that. But in general you should assume that if you add a subobject with glow and shine maps, you're adding three more rendering passes. So if you have a ship made up of one subobject and then you add another, you've doubled the number of rendering passes.
Polygons play a part as well, along with lighting, so it doesn't automatically mean that adding a subobject will double the ship rendering time.
This is IIRC from what Bobb and taylor have been saying ever since HT&L was implemented.
4) Open yourself to a whole host of hierarchy setup problems and bugs. (mainly because of the following point)
5) Would have to carefully plan each and every model to decide which chunks can be destroyed, and everything that would be attached to that chunk. For instance, if you blow off the neck of a Ravana, what happens to the head? If you destroy the base of a Sathanas arm, what happens to the rest of the arm? (this would screw up a number of campaign missions too incidentally)
Point #4 is something I don't have enough modelling experience for Freespace 2 to refute, but Point #5 doesn't sound like a very good reason for why things will "never" happen. It will require planning, understanding of the consequences, and thought as to how things to work? I am all for artists having the freedom they need, but it seems a little silly to try something nobody's done before and then immediately give up because you have to solve a few problems in advance.
6) Would need to work around or take into account turrets, so that the hull beneath them can't be destroyed without the turret also being destroyed, which means more major hierarchy headaches and balance issues.
This gives me an idea for a new table entry slash system - dependent subsystems. When a parent subsystem is destroyed, the dependent subsystem is also destroyed and then subsequently disabled in the collision and rendering and targeting portions of the code.
You can do it with scripting (http://i22.photobucket.com/albums/b311/WMCoolmon/youcandoit.jpg), too.
7) Would probably need extra textures to put on the internal damaged areas, further (probably drastically) slowing the rendering down.
First of all, I don't think you would need more than one destroyed subobject texture as long as you UV-mapped it properly. If you blow off the wings on a fighter, the stubs are going to be very small. There's no need to have separate 4096x4096 maps for the wings and the tail; that would just be bad texturing. I assume you can UV-map destroyed subobjects just like any other part of the model, so you would only need to load one destroyed subobject into memory and use different parts of it. Since each subobject will automatically invoke its own rendering passes anyway, you won't have a significant memory hit.
Of course if you have 6 different textures that the video card has to swap in and out for every single instance of a ship in every single frame, and you're rendering a dozen subobjects besides, you're going to get noticeable slowdown. Poor texturing is not caused by destroyable subsystems.
8) In all likelyhood would just need to use live debris for a lot of parts that would look ridiculous if they just went *poof*, so you can have the destroyed piece float away. This is the technique the Boadicea uses, and as it stands, it is the most complex original [v] pof by a long way. It will be a nightmare to HTL when the time comes for whoever is doing it. Oh yes, and this will add even more hierarchy complexity, and more stuff to build. ;)
Because it's totally realistic that a ship will take massive amounts of pummeling from beam weapons and antimatter warheads and still be totally pristine, until a beam weapon happens to graze a communications antenna for a split second and the entire ship blows up. :p
9) All of the above points take time (and a lot of it at that) to take care of, and so each ship takes even longer to be released.
So what? It's valuable to understand, yes, but it's not a reason that this will _never_ happen.
10) All of the huge effort you've taken to do all of the above points will probably not be noticed by 95% of players. Don't believe me? How many people here know that the HTL Hecate has destroyable engine and conning tower subobjects? And of those who do know, how many of you actually first noticed it in game rather than (as I did) looking at the pof? :p
What if you include actual effects with virtual geomod? What if you make it so that when you blow off an engine, a ship's speed gets reduced? What if you make a mission where you have to destroy vulnerable parts of a capship to clear a way to its main reactor? What if you could blow off one of the arms of a Sathanas?
I daresay that there are implementations of virtual geomodding that would be noticed.
-----------------------------------------
There are probably a lot of other potential issues that I've forgotten, but finally; almost no-one gives ships good debris as is (much to my disappointment :( ).
As such, there is no way they're going to go to the huge amount of extra effort it would take to do this virtual geomod technique.
Don't get me wrong in all this - non targetable, destroyable subobjects are great if used appropriately. It's just that using them to fake a geomod though is not one such use. ;)
-
I concur with WMCoolman! Also...
Slowdown will occur because every subobject must be rendered separately right now, because it may move or get destroyed. So for every subobject you add, you add [Number of subobject textures * (Number of map types - diffuse, glow, or shine) + ((Current number of applied lights - 8)/8)] passes. Or something like that. But in general you should assume that if you add a subobject with glow and shine maps, you're adding three more rendering passes. So if you have a ship made up of one subobject and then you add another, you've doubled the number of rendering passes.
If you included the subobject textures on the ship texture (or bundle all the subobject textures into a seperate texture), wouldn't you be able to batch render the whole thing, drastically reducing rendering time? If a subobject got destroyed all you'd have to do is recalculate the indexbuffer.
-
I have various plans to help reduce the subobject rendering speed issues and I'll be phasing those change in over the next year or so. The minor stuff will go into 3.6.10, more advanced stuff in 3.6.11, but the biggest things won't hit until 3.7, since it will break compatiblity (namely, IBX files will change).
These changes include: cleaning up and optimizing both the API and higher level rendering code, fixing batching to be less resource intensive, using shaders to not have to require separate texture passes, proper frustum culling, render order changes to allow for efficient z-culling, changes to the way that model data is indexed and rendered, subsystem culling based on both frustum and line-of-site, and a few more things as well. Those things will help a LOT. Some are already in sub-public testing (ie, my Xt builds), some are just in dev testing (stuff that I use), and others are still on the drawing board as other basic design and functionality changes are made to allow the changes to be made appropriately. Certain test models have been created to properly stress-test these issues, and the lab has had changes specifically to make it easier to determine both progress and bottlenecks.
So, it's going to get significantly better than it is now, but it's going to take a while before it's all in place.
-
If you are trying to create 'chunks' of armour to blow out from a larger panelled area, like blowing pieces off an asteroid by actually breaking it into bits instead of replacing it with new models, then yes, the seams will show up where the object is intended to break apart, I think that's what VA means about that. There's not really much that can be done about it, even most modern commercial software suffers from 'joining' problems with vertices when used like that, you don't have to wander round in a Cave in Oblivion for long before you come across seam where one piece of cavern architecture connects to another.
Are debris given the same momentum as their 'owners'? So if you blew the wing off a fighter it would spin off realistically, or would it just 'fall' off as though it had been shot off a stationary object?
-
(long post)
Well hey, if people actually want to go ahead and try doing this, they're welcome. :p However, remember that I've already kinda been doing this with my debris on all HTL ships I've thus far produced. I take LOD 1 and crack it apart group of polys by group of polys, and then fill in the holes both on the piece and on the ship hull.
This is for debris, where small (and even large) holes, seams, texture missalignments and other problems won't really be noticed on a LOD with a lot less polys than the main one. There is also no need to plan your piece chunks in detailed ways, nor do you need to take heirarchy into account the way you would for a virtual geomod, but the process still takes a long time to complete, is quite tedious and very prone to problems during format conversion (centres of objects especially get muddled up a lot when getting it into TS for conversion)
1) Ruin the smoothing - without a lot of effort and tinkering, the seams will show up. Especially when seen at a distance I'd expect.
I can't really speak authoritatively on this one (Some start... :p) but that seems more like a model quality control concern. Yes, even without this consideration, some models still don't look that great.
Yeah, it is a quality control concern - a ship with jagged seams all over it (which probably breaks up shine mapping and env mapping on smooth surfaces), is going to be VERY difficult to bring up to to bring up to the level of quality you get from a ship built in one piece. Not saying it can't be done - it can. However, there would be a huge amount of work for every model invovled with doing so.
People thus far have created very few HTL ships with custom UV maps and all new textures. Though the end result will look a lot better if they do it well (it does depend hugely on the model involved though), they don't because of the huge effort involved in making such UV maps and textures. It's just asking too much of free-time modelers. (Which is basically the same reason geomod itself is probably never going to happen - technical feasibility aside, it's asking too much of free-time coders. ;) )
Again, I'm not saying it can't or won't happen, but I'm trying to show just how much work it would be to make a virtual geomodded ship fleet. :)
2) Will have a messed up ship radius which will ruin the targeting brackets around the ship (they'll be far too small) and collision detection (if another object isn't within this ship radius, it's not counted as being close enough to the ship to hit, even though the destroyable subobjects of that ship may easily protrude from that radius, effectively making them unhittable by anything outside the radius)
Ship radius appears to be stored in the model file and determined by the application which generates the POF file. All hittable subobjects should be inside that radius, regardless of whether or not the person is going for virtual POF. If #2 is actually an issue at all, you probably need to talk to Kazan.
Hmm, actually I think PCS did take subobjects into account when generating the radius data for pofs, so that wouldn't be too much of an issue. (3DS Max generated pofs already have radius size calculation problems, so they don't really count)
I do remember something Bobboau said about collision detection with subobject translation. IIRC, the problem was that when the subobject slid outside the parent object's (or was it parent ship's?) radius, there was no way to tell the game to keep colision checking it.
So yeah, probably isn't an issue in terms of geo-modded ships then. :)
3) Slow down the rendering of the ship, because the game now has to render more polygons (the invisible interior ones) that are split over many subobjects (the switching to each new subobject will be a small drag, with the cumulative effect being relatively nasty) just to render the ships basic hull.
This is partly true but not for the reasons you give. Slowdown will occur because every subobject must be rendered separately right now, because it may move or get destroyed. So for every subobject you add, you add [Number of subobject textures * (Number of map types - diffuse, glow, or shine) + ((Current number of applied lights - 8)/8)] passes. Or something like that. But in general you should assume that if you add a subobject with glow and shine maps, you're adding three more rendering passes. So if you have a ship made up of one subobject and then you add another, you've doubled the number of rendering passes.
Polygons play a part as well, along with lighting, so it doesn't automatically mean that adding a subobject will double the ship rendering time.
This is IIRC from what Bobb and taylor have been saying ever since HT&L was implemented.
Well you wouldn't really be able to avoid having glow and shine maps applied to individual chunks if they used the textures of the main hull, so you're looking at three additional rendering passes for every chunk of geomodded ship. Also keep in mind that, big hit or not, you'll have a great deal more polys in the geomodded ship than you would in the single piece version. The single piece would also only need approximately 3 rendering passes to render what the geomodded version used something like 24, 36 or more passes to do.
However, as Taylor has said, this particular issue won't be an issue in the long run, which is great. :D
4) Open yourself to a whole host of hierarchy setup problems and bugs. (mainly because of the following point)
5) Would have to carefully plan each and every model to decide which chunks can be destroyed, and everything that would be attached to that chunk. For instance, if you blow off the neck of a Ravana, what happens to the head? If you destroy the base of a Sathanas arm, what happens to the rest of the arm? (this would screw up a number of campaign missions too incidentally)
Point #4 is something I don't have enough modelling experience for Freespace 2 to refute, but Point #5 doesn't sound like a very good reason for why things will "never" happen. It will require planning, understanding of the consequences, and thought as to how things to work? I am all for artists having the freedom they need, but it seems a little silly to try something nobody's done before and then immediately give up because you have to solve a few problems in advance.
There are some points in TI where the mission requires this sort of feature, so I *have* already tried it and do still fully intend to get it completely working, but this means I do have an idea of the problems involved and how much work it requires to get around them. ;)
6) Would need to work around or take into account turrets, so that the hull beneath them can't be destroyed without the turret also being destroyed, which means more major hierarchy headaches and balance issues.
This gives me an idea for a new table entry slash system - dependent subsystems. When a parent subsystem is destroyed, the dependent subsystem is also destroyed and then subsequently disabled in the collision and rendering and targeting portions of the code.
You can do it with scripting (http://i22.photobucket.com/albums/b311/WMCoolmon/youcandoit.jpg), too.
That already happens if you set up your heirarchy properly AFAIK. Turret arms are an example - destroy the turret and both parts die. I'm reasonably sure the same thing will be true of any other subobjects.
This is what I meant about hierarchy headaches in the previous point though - what if you have two destroyable chunks both independantly connecting to a third one? The modeler will need to decide which one of them, when destroyed, will subsequently destroy the third one. This kinda thing needs a lot of careful planning, or you'll end up with very poor ingame results. :\
And right away the issues of turrets being destroyed when their parent chunk is destroyed leads to campaign balance problems - for example, a chunk beneath a bank of turrets is hit by a beam and destroyed. Where previously, the beam could have only destroyed one turret, suddenly it's destroyed 2 or more at once. Because of the virtual geomod, the ship has less turrets than it would otherwise, and if the Fredder needs certain turrets to be active, he'll then need to set them and all their parent chunks to be invulnrable.
I'm pretty sure there have been code features removed based on less problematic backwards compatability issues.
7) Would probably need extra textures to put on the internal damaged areas, further (probably drastically) slowing the rendering down.
First of all, I don't think you would need more than one destroyed subobject texture as long as you UV-mapped it properly. If you blow off the wings on a fighter, the stubs are going to be very small. There's no need to have separate 4096x4096 maps for the wings and the tail; that would just be bad texturing. I assume you can UV-map destroyed subobjects just like any other part of the model, so you would only need to load one destroyed subobject into memory and use different parts of it. Since each subobject will automatically invoke its own rendering passes anyway, you won't have a significant memory hit.
Of course if you have 6 different textures that the video card has to swap in and out for every single instance of a ship in every single frame, and you're rendering a dozen subobjects besides, you're going to get noticeable slowdown. Poor texturing is not caused by destroyable subsystems.
You could potentially map each and every piece to just the single main UV mapped texture of the hull to practically eradicate the problem (the Loki and Zeus use this technique on their debris incidentally), except most HTL models still use tiling, and you can't fit much of a debris texture onto a large UV map anyway. ;)
This would mean the typical solution would be to add another tilable map to apply to the damaged internal sections, probably 256 res or so. There wouldn't be any significant memory impact, but there would be an extra texture to render on each and every chunk subobject, and it'd be very time consuming for the modeler to map it in a way that looked good when the chunk above it was destroyed. They'd have to do that for every piece of internal hull that could become visible in game.
I think Taylors future plans may cover this though, so it's probably safe to say it's not an issue performane wise - just modeler sanity wise. :D
8) In all likelyhood would just need to use live debris for a lot of parts that would look ridiculous if they just went *poof*, so you can have the destroyed piece float away. This is the technique the Boadicea uses, and as it stands, it is the most complex original [v] pof by a long way. It will be a nightmare to HTL when the time comes for whoever is doing it. Oh yes, and this will add even more hierarchy complexity, and more stuff to build. ;)
Because it's totally realistic that a ship will take massive amounts of pummeling from beam weapons and antimatter warheads and still be totally pristine, until a beam weapon happens to graze a communications antenna for a split second and the entire ship blows up. :p
If being able to blow pieces of ships off is considered a really desirable feature, what I would recommend is that the modeler just look at the 'attached' pieces on the hull rather than the hull as a whole to be pulled apart. An example would be that antennae you mention - if it's hit by anything, it blows off. (still wouldn't change the fact that the damage would be applied to the main hull though)
Basically, anything that you might expect to be destroyable in the course of a battle could be considered by the modeler. Freighter docking arms maybe, thin extruding structures maybe, but gouging out portions of armour, or being able to cut your way through a ship is going too far.
Another thing to look into here is to reimplement Bob's damage decals. Huge blackened sections of hull are a lot more achievable than huge missing sections of hull. Something like this will get rid of the pristine post battle appearance, and just look generally awesome.
9) All of the above points take time (and a lot of it at that) to take care of, and so each ship takes even longer to be released.
So what? It's valuable to understand, yes, but it's not a reason that this will _never_ happen.
Well personally I'd greatly prefer to have two HTLed ships as opposed to one geomodded ship. ;)
10) All of the huge effort you've taken to do all of the above points will probably not be noticed by 95% of players. Don't believe me? How many people here know that the HTL Hecate has destroyable engine and conning tower subobjects? And of those who do know, how many of you actually first noticed it in game rather than (as I did) looking at the pof? :p
What if you include actual effects with virtual geomod? What if you make it so that when you blow off an engine, a ship's speed gets reduced? What if you make a mission where you have to destroy vulnerable parts of a capship to clear a way to its main reactor? What if you could blow off one of the arms of a Sathanas?
I daresay that there are implementations of virtual geomodding that would be noticed.
The first point is exactly what was done with the HTL Hecate. Has anyone noticed that (for the first time) in game though? ;)
The second is definitely possible, but virtual geomodding an entire fleet in order to be able to do that on one ship is not the best way to go about it really. The Sathanas arm thing on bearbaiting would be quite problematic where the arm is a bigger target than the beam. If you were to destroy it at the shoulder too, the sath loses an engine, and so would slow down. Balance issues. ;)
So yeah - some parts would be noticed, but for the amount of work needed to get that notice...... I think there are better ways to more effectively spend your time. :)
-
right, im not reading all that, but from what i can gather this is pretty much another one of those "ya, it would be cool, but i'm not going through the deepest part of hell to make it work" things.
-
the ideas been flung around many times but ive yet to see anyone actually do it.
-
right, im not reading all that, but from what i can gather this is pretty much another one of those "ya, it would be cool, but i'm not going through the deepest part of hell to make it work" things.
Heh, yeah. Bad habit - I lurk too much, and then when I do post I talk too much. :D
-
Decals seem like a more feasible feature - especially if normal/parallax mapping will be available.
-
Decals got removed for some reason IIRC.
-
Decals got removed for some reason IIRC.
Because they didn't work worth a crap, no one cared to fix all of the problems, and we were tired of dealing with all of the bug reports related to them.
-
they worked just fine for me.
-
they worked just fine for me.
The dozen or so Mantis bugs would disagree with you there. :)
That code had/has a ton of memory related problems causing everything from leaks to corruption to crashes, not to mention the rendering issues. I never got it to work properly for me, and many others had the same experience. Any time that it did work it was basically a fluke.
I think that Bobboau wants to do a better job with it anyway. Something about an updated POF format, and the additional of the materials system, should make decals work both properly and efficiently.
-
well i wasnt exactly paying any attention to memory usage. :D