[Scooby_Doo]

Oh now I remember why I need to use PCS1, if i load a model into pcs2, import some stats, then save, the app simply quits without saving.  Hence I convert the model in pcs2, save it, load it in pcs1 and import the settings.

[Bobboau]

ok, try the build in my sig, see if it works better now.

[chief1983]

Man, the date of that build in the zip is set to 2002, is your computer set right?

[Scooby_Doo]

Well it fixed the problem, and I like the red bullets 

[chief1983]

Well, I re-saved some models I think were causing some crash issues with recent HEAD builds.  During re-cache, it took a _really_ long time, to cache a several thousand poly fighter.  Does this seem right?  I mean, like 30 seconds or something, on a 2GHz machine.

[Bobboau]

Man, the date of that build in the zip is set to 2002, is your computer set right?

no, no it is not.

Well, I re-saved some models I think were causing some crash issues with recent HEAD builds.  During re-cache, it took a _really_ long time, to cache a several thousand poly fighter.  Does this seem right?  I mean, like 30 seconds or something, on a 2GHz machine.

yeah, I can see that.
though there might be other problems, I found an infinite recursion issue and tried to implement a solution, though it might be causeing problems, but at least I figured out what the problem was.

[Kazan]

well i'm back from belegarth Oktoberfest... i will try to get some work done too

[chief1983]

Yay!  Can't wait for 2.0 Final!

[Bobboau]

ok, I think I fixed the infinite recursion issue that was causing problems, without causing new problems. in new models look in the model comments section and check 'most polys in a single node' it should be a small number like 2, it it ever gets bigger than 10 I think we might have a problem, I doubt it'll ever get bigger than 5 though. there was a bug in the statistic code for this so if you see some huge number like 4000 in older models don't panic.

also the 'max BSP depth' should be some ware in the neighborhood of log2(polycount of most complex subobject). to calculate this type
log(polycount)/log(2)
into google. if it's more than twice what google gives you (it will rarely be as low as the theoretical limit) then there is a potential inefficiency that needs to be worked on. general rule of thumb is it should never get deeper than 20 (unless you have a model someware in the range of a million polys)

and on the subject of the statistics, Kazan if you still read this you should look at the last two statistics which have to do with the time it takes to compile a model, it can take several minutes to take care of the overhead involved with setting up the geometry and less than a second to actually generate the tree, I think we will need to do some major reorganization of stuff so that overhead is no longer needed in the future. I think I've mentioned this before, but I was just reminded of it.

[Kazan]

i believe most of the overhead is converting to FS2 coordinate space, and then compiling the points list

best theoretical performance of those is O(n) and O(n*n) respectively.

[Bobboau]

I'm prety sure it's th n^2 part that's causeing the problem.

[Kazan]

probably.. but there isn't much you can do... now that i think of it best theoretical performance is like.... O(n!) not O(n^2)

[Bobboau]

we could not store the polygons in our geometry as a list of independent points, but as a list of indexes to a list of shared points. that would be more like all geometry formats we are going to work with, make editing geometry easier, and solve this problem. the best theoretical performence for BSP generation is nlog(n).

[Vengence]

I'm pretty sure this was already said but when I save my POFs the meshes get slightly corrupted. Collision detection on capital ships seem dead. I passed right through my Typhoon! Not to mention the barrels were nearly gutted. I'll try some other models and see if the same thing happens.

[Bobboau]

no, no it wasn't said, we've been working under the assumption that the BSP compiler has been working all this time because we have been asking people to try and break it for six months and no one has said anything.

now what do you mean 'nearly gutted' are polys missing? you are useing the most recent version? have you used other versions? did any of them work ok?

[Kazan]

all the models i tested were working fine.. but that was under the 1 polygon per leaf mode

[Vasudan Admiral]

Hmm, whoops. It occurs to me that I've not actually tested _saving_ many (if any) capships once they're converted, because I'd forgotten that the BSP compiler only runs during POF save. A lot of what I'd been doing only involved just opening SCNs. Only half the story. :\
(I had taken much simpler test meshes and occasionally fighter meshes further, but nothing as complex or as large as a capship)

I recently did try a capship though, and encountered that holes-in-mesh bug Bob describes. It would only show once the POF is saved and reopened. I assumed those errors were because of bad COB data, because I hadn't built that particular mesh, but they sound like that missing polys bug. I'll give it a test now with some of the known working SCN files of past ships and see if they have missing polys once POF-ified. If so I'll post a bug report with as much info as I can get.

[Vasudan Admiral]

Double post, but whatever that bug was, it is apparently gone now. I just converted, saved, reopened and carefully examined 8 big models, including the one that had the weird missing poly bug previously.

I redownloaded the most recent PCS build from Bobs sig before testing though, so my only guess is that those latest changes squashed it.

I was checking the BSP depth and node polycount data this time too. Most had a BSP depth of 15 or 16, but the node polycount was all over the place. The TC-Tri had a count of 16, the Aeolus 10, and the Triton 8. The others (fenris, loki, lucifer and zeus) all had counts between 1 and 4.

Do you want me to upload the TC-Tri's source SCN?

[Vengence]

no, no it wasn't said, we've been working under the assumption that the BSP compiler has been working all this time because we have been asking people to try and break it for six months and no one has said anything.

now what do you mean 'nearly gutted' are polys missing? you are useing the most recent version? have you used other versions? did any of them work ok?

Oh. Ok then, here is what I have:

PCS 2 says it is Jan 4 2002 00:14:16. I recall somewhere that said the 2002 thing was not right. By gutted I mean triangles are missing. One of my models had an entire engine removed! And by engine think Earth Alliance Starfury without one. When I used PCS2 on my Typhoon Cruiser I passed right through the hangar and weapons can't hit it.

I don't exactly know where a PC2 repository is but I SORT of found a way around the model corruption problem. I use PCS2 and 1 together. I set up the model in PCS2 and export a wrecked mesh and take a copy of the original and use PCS1 to transfer the data without harming the mesh.

I'll see if you have a newer version in your sig. I can't remember where I got my pcs2.

EDIT: I got the Oct 9 version and resaved a model that would've gotten the errors. The mesh error appears to be fixed. I'll test it on other models and see if the problem was fixed.

[Kazan]

i released a pcs2 build in 2002? whhaaaa?