[Vasudan Admiral]

Open up any [v] pof in modelview. Enter the pof-editor and look on the right hand side. See all the lights entered in there? Well they do didily-squat, yet they're on every canon model. Why?

[karajorma]

Do the split subsystems even _have_ an effect in-game? I've never been able to achieve any noticable difference with them.

They define where the shockwaves start.

[taylor]

Would that be faulty normals in terms of collision mesh and/or rendering? (ie, where, if anywhere could we expect visible problems to arise because of this?)

In current builds I don't think that you should notice much difference.  Depending on what fault the normal has the game code will automatically fix it, but it doesn't fix everything.  OpenGL will also regenerate normals in most cases if they are invalid, but that's obviously slower than if they were just correct in the first place.  I think that the biggest issue, for anything that the code doesn't automatically fix, is that you will get corrupted IBX files and those will have unpredicatble results.  For some people those IBX files will work fine, for the majority of people it will cause strange rendering issues, missing geometry, strange problems with textures/lighting, etc.

If there is a bad normal identified, to the point that FRED reports it, then it's a good idea to fix the problem.  If it's not fixed then the model could work differently for different people just because the data would generate random and unpredictable results.

[Raptor]

Would that be faulty normals in terms of collision mesh and/or rendering? (ie, where, if anywhere could we expect visible problems to arise because of this?)

In current builds I don't think that you should notice much difference.  Depending on what fault the normal has the game code will automatically fix it, but it doesn't fix everything.  OpenGL will also regenerate normals in most cases if they are invalid, but that's obviously slower than if they were just correct in the first place.  I think that the biggest issue, for anything that the code doesn't automatically fix, is that you will get corrupted IBX files and those will have unpredicatble results.  For some people those IBX files will work fine, for the majority of people it will cause strange rendering issues, missing geometry, strange problems with textures/lighting, etc.

If there is a bad normal identified, to the point that FRED reports it, then it's a good idea to fix the problem.  If it's not fixed then the model could work differently for different people just because the data would generate random and unpredictable results.

Ahh, but that begs the questions:

1) how do we find out which normals are bad?
&
2) how do we fix bad normals?

VA, that's why I asked about the auto-facet builds of PCS.  Great shot BTW   I really wanted to show just how big this beast really is.

Still not sure about the hull plating though.  On the one hand, without the hull looks kinda plastic like, but on the other you shouldn't be able to SEE the seems between plates unless your a couple inches away from them (unless the dockyard workers did a REALLY poor job on it!)  Suppose the question is can you see the seems between plates on the side of a (wet) ship from more than a couple of feet away?

An altnerative would be to use a seperate map for the plated areas, or even a tile, but those mean re-uvmapping the ship...   And I can't tile map at all.

[taylor]

1) how do we find out which normals are bad?
&
2) how do we fix bad normals?

Don't have a f'ing clue.

That's what all of the POF/model experts are supposed to know, I'm just a code monkey.

[WMCoolmon]

1) how do we find out which normals are bad?
&
2) how do we fix bad normals?

taylor probably knows the answer to this better than me, but what I've assumed is that normals are XYZ values from 1 to -1, that define a point in 3D space. Then, a ray is drawn from the axis to that point in 3D space, which indicates the direction that the normal indicates.

So an invalid normal would be one with value(s) greater than 1, or less than -1. (These larger values would be unneccessary because a normal does not really have magnitude, since it only defines a direction1)

[Vasudan Admiral]

They define where the shockwaves start.

Oh. Well that would explain how I didn't see much - I was looking for the right subsystem size to get the model to actually split in those positions during it's death, and I'd turned shockwaves off to get a better view of exactly where it split. :\
Ah well - wouldn't help achieve the top/bottom split effect you're after Raptor, but you could use splits to get some shockwaves eminating out of some of the basestar's hanger bays at least.

About the plating, it looks like plastic primarily because each plate only has one colour - a little like lego bricks really. Aldo devised a very effective plating technique which he posted a while back, which I'll write up and stick in the wiki if you're interested?

----

Back OT, it seems that the faulty normals problem may arise from the fact that the Hera isn't triangulated. However, when triangulated, a bigger problem arises - it's polycount doubles to 20 000, meaning PCS is unable to convert. I deleted all the engines, bringing it down to 12 000 and allowing it to convert, but now Fred crashes as soon as it even tries to open it.

Basically, you're going to need to cut down on the polycount if you want it to work properly in game, because it's only going to get much much worse as you add turrets and anything else.
One of the biggest causes of the massive polycount will be the little indents that you've got all over the hull. Remember that whenever you're adding greebles, you have a choice between things that indent into the hull or bulge out of it.
Any object you extrude will be at least three polygons - because you don't need to attach it to the hull, while anything you indent has to be at _least_ 8 to have the same shape (not counting the polygon it was indented into). So, when dealing with the shear numbers of greebles you've got here, you should almost always choose extrusions over indents unless an indent really will look better.

[Flipside]

I find turning the background a lurid colour help to find the holes, you may also have problems if the indents are booleaned into the surface, a lot of 3D programs struggle with booleans, creating ghost polygons and vertices, as well as duplicate ones.

Personally, I always triangulate models before conversion, that way I'm certain that the model I am sending to the converter will make a solid model. I've certainly had situations where a non-triangulated model in Lightwave has been auto-triangulated by another program and the normals have not all been facing outwards, yet Lightwave will happily do it correctly if I use the in-program function.

Just remember the points always go clockwise around a polygon, that's how hidden face removal is done, if the second polygon is anti-clockwise to the first one, the polygon is facing away from you, always been impressed at the simplicity of that

[Raptor]

Yea, I have kinda gone mental with the Hera haven't I?

Thinking about it, I think I know were the bad ploys are.  In the girderwork on the spars holding the 2ndry engines.  Somes in TS some of the faces vanish at certain angles.  I assumed that since FS2_open trianlgates everything anyway, it didn't matter so moch.

Most of those indents won't be fill BTW, only the perfectly square ones.  See attached image for the full array.  All the red stuff are turrets.  Note there are four more on the back of the spars support that can't be seen from that angle.

[attachment deleted by admin]

[Vasudan Admiral]

Crikey - that's a lotta guns.

BTW, I think you may be able to get around the problem by doing one of two things:
1) Remove enough detail so that PCS can still convert it. This would mean most of those indents would have to go, you'd have to re-structure the extrusions so they aren't actually connected to the model (because when they are they may as well be indents), and you'd probably have to split off the engine pylons as a separate subobject so FS can actually open it.

2) Split it up into subobjects of around 10 000 each, get it into 3ds Max, and convert it from there. Other than splitting it into subobjects, I doubt you'd have to do much more to it if you use Max as a start point. I'm currently learning max for a similar reason.

[Raptor]

Well, as I have no clue about Max, it'll have be the first option.

Remember the total turret number I told you about?  That's how I got that figure of 122.  Didn't mean to have that many...  When I was doing 'back-of-note-book' cal's, it came out a lot less.  I'll certainly cut some to get it to work, though it pains me to...   Can you just imagine what a full broadside would look like?

Most of the indents were so that when a turret is destroyed, you get a hole in the ships hull rather than a smooth surface that looks like ther never was a turret there.  Some of the others were for sets of windows.  I already recessed large areas for the larger banks, so...

I'll most likely remove the escape pod protrustions, and have a rethink on the turret indents.  Adding the extrusions on as a submodel is a good idea, and as I've already started doing that ( the turret rings and the engines are both in that set)  That would also allow me to get the textures to match the geo correctly (something that has been bugging me)

I just got to hope that it doesn't screw up the UV mapping... 

As the main hull (including those soon to be removed extrusions/indents) is 'only' 6.4k, I think I can leave it intact.  I will trianglate the engine spars though, to deal with those bad normals (if it is them)  And off course I'll have to remodel the guns.  It's mainly the mutli-part ones that eat up the polys.  Those big ones are 740 polys each

Course, that'll mean I'll need to redo the turet UVmap...    At least the gunport bits will be untouched...

[Vasudan Admiral]

It's a pain, yeah - and though it will break parts of the UV map, reapplying it should be fairly easy because you're not changing the overall shape of the polygons. Ie, they'll still 'fit' in the texture area you've assigned them.

Also, of those big 740 poly turrets, definitely reduce the number of polys they use, and if I were you, I'd take the number down from 20 to 8 at the most - remember that if this is going in game, there may come a time where the player or even the AI has to attack the ship, and having 142 firepoints on the ship would mean that's practically impossible.
Even juggernaughts are far outclassed - it has 5 and a half times the total firepoint count of an Orion, and twice that of the Colossus, all on a ship only 500m longer than an orion!
It's just a bit overkill really.

[Raptor]

I wouldn't say it has more firepower than the Big C... that had twelve(thirteen) big beams.  This only has six...

It's more the secondary dual purpose weapons and anti-fighter weapons that it has loads off.

Full List:

6 BBlue (inproved BGreen/TerSlash)
4 MBlue (weaker than above)
20 Turboplasma (mid power dual use gun with bolts fired at much higher speeds)
20 AAABlue (weaker version of original ULTRA Anti-Fighter Beam)
26 Standard Flak
42 Plasma pulse (about Terran Turret grade)
2 Heavy Cannons (huge plasma cannons)
2 Gatling turrets (these are to the Prometheus what a minigun is to an Uzi  )

I've already dropped the Heavy Cannons.  I'm aiming for 96 turrets by the end.  And surprisingly the UV mapping on the hull, after removing the turret inserts and the escape pod extrusions, has remained the same.  Need to redo a little bit on the bow to account for the removed cannons.

I think I will remove the bars on the engine spars, and instead have them as part of a 'Detail' subobject, which is layered on top of the LOD1 hull to create LOD0 (It's what I'm doing with the BSG capships).  Might also bump out some the textures on the bridge spars too at the same time.

We'll see how many polty it will be after I do all that.  Currently we're at 5544 polys.

[Vasudan Admiral]

When TS adds new polys, it tries to estimate their UV mapping by looking at the surrounding polys. For me it _always_ gets it quite wrong.

Anyways, what I mean with the guns is that if the player will ever have to disarm it, he'll die of frustration before half the guns are off.
Have you ever tried completely disarming a juggernought? It takes ages of sitting in one spot shooting, and in this case you'd have to worry about all the dozens of weapon banks either side of the one you're shooting at too.

You need to consider what you want, what's realistic and what will be playable to make a balanced armament. (Of course, that's assuming you want a balanced armament, and don't already have a campaign role in mind that requires huge turret counts.)

[Raptor]

Well, remember this is coming from the chap who thinks the Orion should have over 3 dozen turrets... not the pathetic sixteen it has ATM   Fighters are for killing other fighters.  If Command needs fighters to kill a destroyer, then something is seriously furbar.

I know what you mean about the TS texture UV mapping issues.  Fortunately in this case I only needed to do minor tweaking in lith.

Got it down to 3824, almost half the old count.  Currently rebuilding the MP turret models to be less poly hungry (modelling done, now working on the UVmap)

Also, I've cut 26 turrets, and down graded 8 of the beams a notch (2 big, 4 medium, 4 small now)

Besides, capships only ever fire 3-4 turrets at one target.  I've mentioned this to the coders, but I've seen no idecation that thet've taken it onboard...

[Mongoose]

Regarding the polycount being too high, how exactly did Omni (I believe) manage to get that 50k-poly Galactica in-game?  Was he using a different program than Raptor is?  Or was it some other model issue I'm not familiar with?

[Vasudan Admiral]

Omni was using Styxx's 3ds Max POF exporter. I don't think it has any set total poly limit as PCS does, since it has apparently managed to convert Omni's 100 000 poly death star at one stage. PCS chokes when the total polycount of the scene you're trying to convert hits somewhere between 15 000 and 20 000 polys.

Hopefully PCS2 won't have the same problem.

[Raptor]

Omni is insane isn't he?  Even if he is a professional...

[Vasudan Admiral]

His battlestar is one of the few models I've ever seen that not only gets away with texture tiling, but gets away with it beautifully.
Actually, all the stuff I've seen from that fella is absolutely phenomenal.

[karajorma]

Looks even better in-game too

*backs away from thread before he gets murdered*