Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Raptor on September 13, 2006, 07:29:36 am
-
My PCS woes continue, but now things have gone weird...
I just converted the latest version of my GTD Hera hull (without turrets), sorted the engine glows and was going to see how it looked in game.
Only thing is just like the Cylon basestars I've converted over the last mont or so, it caused FRED and FS to hang(but not modelview)
For a laugh, I pointed the tbl entry to the older model... and I got this!
(http://img133.imageshack.us/img133/1097/shilloutesa4.jpg)
See the hard edged outline? That's the ships stern! :mad: :lol:
The ship is psyically there, since I can shoot it and run into it, but it is completely invisible! Aside from the thruster glows.
The ship has a jpg and a standard pcx map to draw on...
I just wish I knew what is happening with these two models. I can't see anything wrong with them. I'll have to try converting a couple of other ships (and pray that the old ones stop working like the Base Star did...)
-
Check the textures names against the textures and locations..........
They're obviously not getting drawn for some strange reason,...................Stealthy though. :)
-
Use DDS on the textures for a start. :)
As for the versions that hang Fred and the game - send me the cob/scn files and pofs if you like, and I'll have a look at them - since it really could be anything.
-
Check the textures names against the textures and locations..........
They're obviously not getting drawn for some strange reason,...................Stealthy though. :)
I think I've been modding long enough to check that (I started before SCP began)
No offence intended :)
Use DDS on the textures for a start. :)
Wish I could. I know I'm supposed to add a dll file somewhere, and then do something with Paint Shop Pro 7 to get it to recognise the format... but I can't remember what/where/how... :nervous:
As for the versions that hang Fred and the game - send me the cob/scn files and pofs if you like, and I'll have a look at them - since it really could be anything.
Thanks for the offer. 8) Mail sent. I really am not an expert on the whole cob->pof thing. I model and table... then muddle through the rest. :shaking:
-
To allow PSP to open DDS, just stick the attached .8bi file into your plugins directory in PSP's main folder (if it doesn't exist, add it).
Anything else to do with DDS can be found here: http://developer.nvidia.com/object/nv_texture_tools.html so just look through that for whatever takes your fancy. I got the thumbnail viewer and WTV.
[attachment deleted by admin]
-
Come to think of it, that's a pretty neat cloaking effect. I wonder how it would look with some kind of transparency distortion texture?
-
Thanks VA ;)
Come to think of it, that's a pretty neat cloaking effect. I wonder how it would look with some kind of transparency distortion texture?
That's what I thought, hence the title
-
...hold on a second....it hangs in both Fred and FS?
That's not actually a crash kinda hang. That's the Fred or the game building the cache files (the IBX's) for the first time!
Since both models are quite complex, it's taking a while to build the cache files. I have an AMD 3800+ with 2 gigs of RAM, and it took me 1:43 to finish on the basestar, and a minute to do the hera. Both work in Fred now* - and though I can't test right now, I'd expect they work in game too.
Here's the cache files mine generated: http://sectorfiles.net/ti-file-dump/VasudanAdmiral/RaptorsIBXs.zip
Whack them in your FreeSpace2\data\cache folder, and see if you can then place them in fred and view them in FS. However, these cache files will only work as long as the pofs you have in your models directory match the ones in the zip you sent me. If you've updated them in any way, it will 'hang' again.
If it does, or in the future, just let it run for at least 5 minutes before killing it, since chances are that it's still working. :)
* - I do however get an error when loading the Hera for a first time in Fred: "Serious problem loading model Hera2.pof, 66 normals capped to zero"
I found the spot in modelread.cpp which spits out this message, but couldn't figure out where the int "Parse_normal_problem_count" is set, so I still don't really know what it means. :(
Could a coder help there?
-
* - I do however get an error when loading the Hera for a first time in Fred: "Serious problem loading model Hera2.pof, 66 normals capped to zero"
I found the spot in modelread.cpp which spits out this message, but couldn't figure out where the int "Parse_normal_problem_count" is set, so I still don't really know what it means. :(
Could a coder help there?
It's from bad normals in the model (though FRED is the only thing that reports this), but you know that much already. Bad normals are identifed as any xyz vector value being out of range (ie. "(x * x) < 0" would be a failure), or any xyz vector value being NaN.
-
...hold on a second....it hangs in both Fred and FS?
That's not actually a crash kinda hang. That's the Fred or the game building the cache files (the IBX's) for the first time!
Since both models are quite complex, it's taking a while to build the cache files. I have an AMD 3800+ with 2 gigs of RAM, and it took me 1:43 to finish on the basestar, and a minute to do the hera. Both work in Fred now* - and though I can't test right now, I'd expect they work in game too.
Here's the cache files mine generated: http://sectorfiles.net/ti-file-dump/VasudanAdmiral/RaptorsIBXs.zip
Whack them in your FreeSpace2\data\cache folder, and see if you can then place them in fred and view them in FS. However, these cache files will only work as long as the pofs you have in your models directory match the ones in the zip you sent me. If you've updated them in any way, it will 'hang' again.
If it does, or in the future, just let it run for at least 5 minutes before killing it, since chances are that it's still working. :)
Okay, I'll try that. Doesn't really surprise me that it would take forever to build said files, considering the size of the pof files themselves. :rolleyes:
Maybe Kazen can get PCS2 to generate smaller pof files? [/retorical]
Not sure about the bad normals thing though... The only things with normals are the engine glows and the eyepoint (if it has it)
-
Thanks 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?)
Either way, it sounds like it might warrent a reconversion. I'll try that now on the Hera cob I have and see if the same error crops up.
Raptor: I'm pretty sure it's refering to the normals of polygons, considering there are 66 of them that get 'capped', and you have 32 thrusters total. ;)
-
Either way, both ships work flawlessly now. Thanks VA ;)
Almost. I have a set of old glow masp for the Hera. Standard style of pure black except where I want glows (ie lights)
With glowmapping set to 'on' those maps vanish again. Only those maps without glow maps are visible. Still shootable.
That might have caused the invisible ship thing from before... :doubt:
And I realised I need to use a Faceted build of PCS. The smoothing on the two of them is not good :ick:
Got a version that handles that VA?
Would renaming the ibx and pof files to the exact same name also cause it to 'hang'? (thinking drop the 'x' from 'basestarx'...)
-
Why is all your writing Blue?
Is this a gimmick, that anyone can get in on?
-
It probably would cause it to rebuild the IBX, but it's still just a 2 minute wait. Give it a try, but if it doesn't work, just do something else for 2 mins. ;)
There's a link to the autofacet build in the wiki entry: http://www.hard-light.net/wiki/index.php/POF_Constructor_Suite
As for the glowmaps, what format are they? DDS - (dxt1 no alpha)? And can you actually see the glows he maps are supposed to create, or do those areas of hull just become as transparent as in your first screenie?
-
As for the glowmaps, what format are they? DDS - (dxt1 no alpha)? And can you actually see the glows he maps are supposed to create, or do those areas of hull just become as transparent as in your first screenie?
They are DDS (made before computer upgrade), but I can say exact format...
Back then the pop-up for saving as DDS was a lot smaller, and it was so long ago now I can't recall what I set them too.
And no, can't see the glows at all.
-
Hmm, could you attach one (or all if they fit) to HLPs file uploady thing? (in additional options during a reply) Cos it sounds like whatever the problem is, it has something to do with the map files themselves.
-
Attached , See rar. I'll be making some new ones anyway(the maps in question are for an older version of the Hera's maps)
Say, is there a way to have a ship split vertically when it dies? (thinking about Base Stars dieing, and how cool it would look if the two disks split apart instead of the normal death routine)
[attachment deleted by admin]
-
Add a split in the pof.........See Karajormas F A Q....... :ick:
-
Do the split subsystems even _have_ an effect in-game? I've never been able to achieve any noticable difference with them.
Anyways - yeah, the glowmaps compression was your problem. It called itself '16bit-X1R5g5B5'. I just opened them both in PSP and resaved them as perfectly normal DXT1 DDS files with no alpha, and tharrrr she glows!
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/TharrrrSheGlows.jpg)
The lights make it look beautifully huge. Well done. :D
One more thing, definitely use the autofacet PCS version in the future. ;) (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/TheHorrorsOfSmoothingAnAngularShip.jpg)
-
It wouldnt be if it didn't........ ::)
-
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? :p
-
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.
-
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.
-
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 :D 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... :shaking: And I can't tile map at all.
-
1) how do we find out which normals are bad?
&
2) how do we fix bad normals?
Don't have a f'ing clue. :D
That's what all of the POF/model experts are supposed to know, I'm just a code monkey. :)
-
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)
-
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.
-
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 ;)
-
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]
-
Crikey - that's a lotta guns. :p
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 (http://sectorfiles.net/ti-file-dump/VasudanAdmiral/SpaceBall1-WIP1.jpg). ;)
-
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... :shaking:
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 :eek2:
Course, that'll mean I'll need to redo the turet UVmap... :sigh: At least the gunport bits will be untouched...
-
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. ;)
-
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. :pimp:
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 :p )
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.
-
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. :p
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.) ;)
-
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... :sigh:
-
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?
-
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. :)
-
Omni is insane isn't he? Even if he is a professional...
-
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. :)
-
Looks even better in-game too :)
*backs away from thread before he gets murdered*
-
Looks even better in-game too :)
*backs away from thread before he gets murdered*
I wouldn't say the GINO is good looking, but I have to agree he's done a great job getting it in game (though how he expets those of us with 'mortal' PCs to run that beast is beyond me!) :rolleyes:
Personally, I would prefer it if he had applied that skill and talent, which I do not doubt at all, to the original (and true) Galactica. But each to their own tastes as I've always said.
I've always thought that tiling, if done right, can look good. It's just so hard to do right... :sigh:
The rag-tag fleet I could use, if he let me. They ripped all of them (save the odd new ship) from the original series you know...
Indeed, I think the CGI people knew what they were doing, and had a laugh at themselves while they were at it. In one shot a Firefly (from Joss Whedon's show of the same name) flies past a window, and in one of the wide angle fleet shots the Enterprise (as in NCC-1701, that Enterprise) can be seen! :lol:
-
Indeed, I think the CGI people knew what they were doing, and had a laugh at themselves while they were at it. In one shot a Firefly (from Joss Whedon's show of the same name) flies past a window, and in one of the wide angle fleet shots the Enterprise (as in NCC-1701, that Enterprise) can be seen! :lol:
I recall seeing that Firefly class, but I didn't notice it until the 4th or 5th time I'd seen the mini-series. I was in fact showing my wife (girlfriend at the time) the Mini-series, after giving her a run-through of the original series (and SELECT episodes of Galactica-1980 :ick: ), in anticipation of showing her the new BSG series. I suddenly caught sight of it as it flew by the window and had to rewind and watch it twice more to fully appreciate it and get a successful pause on the image. It wasn't until getting the Season 1 DVD (with Mini-series) and booting it up on my PC, before I could get a better look at the "Enterprise" shot, to confirm to myself that it wasn't just something someone added into the image afterwards.