Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on October 17, 2007, 06:23:55 pm
-
It's time to find bugs and get ready for release! Report all bugs in the PCS2 Mantis (http://ferrium.org/mantis/)
RC1 2008-1-13 Exec: http://ferrium.org/media/pcs2-rc1-20080113.zip
DLL Pack: http://ferrium.org/media/pcs2dlls.zip
PS: if you PM either bob and I about a bug, but you don't put it in Mantis, your bug won't get fixed - same goes for posting it in a thread without putting it in mantis.
Build Last Updated: 2008-11-3 10:30 PM
-
About how long should it take to save? Because I've had it open now trying to save this X-Wing model, and it's been on Submodel 2: detail-2 for about an hour. I think I need to mantis it.
-
email me that model - [email protected]
-
your x-wing has way more polygons than any fighter should EVER have
the problem is it's going into an infinite loop due to a floating point error
[edit]
detail 3 managed to cause an infinite recursion in the thread... i dunno how.. but it did...
-
updated build, should have less memory leaks, has a fix for the bsp depth counter - it had an accuracy issue, 2 identical polygons will no longer send it into infinite recursion, the anti-infinite recursion check is active on tree generation again and will now also give you an error dialog if it detects a bsp compilation error
-
Finally! :yes2: :) :yes:
So I hope it solves one of my problems...
I had a slightly upturreted Ravana, but converted with the latest PCS 1, it'd crash FS on random occasions (read: randomly at any time between mission start and mission end :ick: )
-
About how long should it take to save? Because I've had it open now trying to save this X-Wing model, and it's been on Submodel 2: detail-2 for about an hour. I think I need to mantis it.
there is a floating point error that can cause an infinite recursion error, I have been trying to resolve this issue for a few weeks now, try the build in my sig and tell me if it helps your situation any.
-
it only happens in cases where the geometry is bad anyway as far as i can tell... though the source of the error i cannot find precisely
-
we should be able to handle geometry problem gracefully though.
and it's basically caused by floating point errors, we might be able to virtually eliminate it if we used doubles. and had comparisons check for differences too small to be held by floating point numbers.
-
that floating point error only happens in cases of bad geometry that we shouldn't handle.
in 2.1 i'll be putting in a system that shows where bad geometry is (lights up the bad polygons in red) and then it's up to the modeler to fix.
-
that floating point error only happens in cases of bad geometry that we shouldn't handle.
in 2.1 i'll be putting in a system that shows where bad geometry is (lights up the bad polygons in red) and then it's up to the modeler to fix.
:eek2: Wow
Although a few instances of bad geometry won't be visible from the exterior. (wireframe mode? - transparent mode?)
-
initially the "bad geomtry detection" will only be
Compile a BSP Tree
Visit every leaf node and record every polygon found in "foundlist"
highlist any polygons not in "foundlist" red.
The way the BSP tree compile in PCS2 works - bad geometry is simple truncated (not included). This won't catch inverted normals, etc. Though i may be able to catch things like that by comparing to adjacent polygons - ie if all 8 surrounding polygons are +x,+y+,z but this polygon is -x,+y+z then mark it "suspect"
-
like I was saying, we should handle bad geometry as gracefully as possible, giving the user a notice that there is bad geometry and showing ware and how bad is a good idea, but sometimes it is just unavoidable. truncation is the worst possible way of handling it, dumping unseperatable geometry into a single node is much better, as it will still work, just not as efficiently, but lets face it, when there is bad geometry it's usually something like two polygons, so if the collision test for that node is twice as expensive, it's hardly going to be noticeable, on the rare occasion that one node is hit.
-
it doesn't silently truncate anymore.. it warns. I also put in code for contained.size()==2 to check if contained[0] centeroid==contained[1] centeroid and if so kill the s-node currently in progress and return a p-node containing the two polygons
that right there fixed compilation of atleast 1 of chief's models (though the hierarchy is still wrong on the model)
-
I never really expected any of these to be production ready :) but if you needed models that were going to break it, I figured why not go with some of the really crazy stuff we had laying around. One is an XWA port, another is some ancient cob conversion, and the third, well, Tura's redoing that anyway :P
Knowing there's something wrong, but still being able to get some kind of useful info about it, or a temporary conversion, will be very useful, thanks a bunch Kaz and Bob.
-
I am a very sad camper, I made a change to POF storage in memory that would fix a bunch of memory leaks, and introduced a crash bug that would happen every time with every model when saving to POF... and it took four days for anyone to notice.
New Build posted
-
People don't just have a big pile of models ready to run through every version of PCS2 to test every aspect of it you know. ;)
I mean, I had just done one such big test in the pre-RC1 build and it took quite a few hours for the relatively few features I was testing. My time is really limited at the moment already as we're approaching uni exam period with assessments still due, and I'm mid backup, format and reinstall of my whole HDD, so repeating the same test on a build that is only a little different from the previous one that worked perfectly isn't terribly high on my priority list. I haven't even had the time to build a simple test model I promised for Taylor yet. :(
Also, if the time it takes to fix bugs is an issue, consider that as coders you're the ones who know what has changed and so where new bugs might pop up, you know exactly what _should_ happen, and are then in a position to test for them way faster than it is for a tester to go wandering through checking all the features and writing up bug reports with as much info as they can every time they *think* they've found something. ;)
If you can't/don't want to do that, that's fine - but you'll have to be willing for it to take a good deal longer for those bugs to be reported.
That aside, I'm really excited by PCS2 getting to this stage. Well done. :D
-
Oh i've noticed, but don't have any models ready to converty, just yet.
-
I am a very sad camper, I made a change to POF storage in memory that would fix a bunch of memory leaks, and introduced a crash bug that would happen every time with every model when saving to POF... and it took four days for anyone to notice.
New Build posted
Oh you fixed that allready? Kewl!
DL ing now...
-
If it's the 10/18 build, I just thought it was crashing because of my broke-ass models again.
-
yeah that build, and your models shouldn't crash it anymore
-
Ok, it does spit out the error message saying that the model has bsp compilation errors, but it still generates the pof. Does that mean it just generated a pof without BSP info, or is it using some other recover method to generate a hacked tree or something like Bob was talking about?
-
it's generating the pof without the bad geometry section - so it'll be missing polygons
-
I haven't had much time sofar to play with PCS2, but now that I'm more active and back again, I would also like to learn it (and help you fixing the bugs :) ).
But first off, I have quite some problems with the programm itself. I can open nearly all my cobfiles (by simply using file/open) and they render good in the PCS windows.
However, do I see this right that for creating the pof I simply have to say "File/save" ?? Because when I do that, PCS2 crashes with every model I try, and I only get the windows error message, nothing specific at all.
Any help appreciated (especially since I have a model to convert, and PCS1 can't handel it :) )
-
check the date on the build you're using and post it
and yes
open cob, save as pof
-
OK, I also had the 18/10 build installed. With the 22/10 build it works. Thanks :)
-
nice :yes:
-
I'm getting a crash when saving ships such as the loki or the media VP orion to cob. It runs through all the subobjects and crashes when the status bar reads 'saving cob'. I've tried erasing all the pof data by global importing a cargo containers data, but that doesn't help.
The only hint I may have found is that it only seems to be crashing on ships with lods/debris - it's worked on a couple of simple test ships that lack them.
I'll put this in the PCS mantis as well for redundancy. :)
-
ok, as soon as school let out work decided to consume all free time, I'm hoping to get a day for work on this soon, I'd like people to start compiling for me a bunch of models with known problems. if you can post them publicly do so, I will try to make all models work even if they have 'bad' geometry (even though bad geometry will require less efficient trees). things I'm looking for are missing polys and collision holes, if you could maybe mark where collision holes show up in a picture it would make testing faster. also I will be getting back to working with mantis.
-
AFAIK Scooby and some of the SWC devs have had problems, but I've still not had any collision mesh problems with the latest build that I can remember.
(The ones I can remember were because I was using an older build by accident.)
-
I think I figured out my collision issues. Not sure if it really solves the problem or just bandages it. The newer build taylor (1207) fixes it.
-
I take that back somewhat.... I've found other issues. When trying to convert one of my models, one that I had already converted earlier with pcs1, pcs2 locks up and practically freezes the entire computer.
-
The lockup issues were supposed to have been fixed, it was at least handling them gracefully now I thought.
-
The bounding box problems were creating such a headache that I committed a workaround to CVS. That's probably why the models work in the 12/07 build but not in the earlier ones. But the workaround is only for that one particular problem, and is not guaranteed to fix other bugs with the same underlying cause.
-
on that note: we know what the problem is thanks to goob noticing it.. i just need to pull myself away from vanguard long enough :P
-
was it actually swapping the bounding boxes? I haven't had time to look at it since last night, but what I read I wasn't sure if it was just showing as reversed or if it was actually reversed.
-
actually reversing because goob says they'd swap each load&save
-
I just noticed why it does this to mean. When you want to paste values into a text box in pcs2, like subsystem properties, not only does that text box have to be active (obviously), but the mouse has to be over the text box. If it's not it won't get pasted.
-
well it doesn't need to be over the text box, just not over the renderer.
-
Ahhh yup, you are correct. I was jumping back and forth betwen the subsystem properties and the subsystems (pcs1 forgot to put the subsystem properties in the turret objects).
Ok kinda stuck in a situation. I've imported launch paths from one of my models to another. But I need to rebuild the paths. Autogen will delete all existing paths. Possibly an append would be helpful (either on import or auto-gen) Sweet it saved it.
-
does anyone have a problem model? I think I'll be able to work on this today
-
I've sent most of mine to Kazan, I can forward it to you if you want.
-
that would be nice. :)
be sure to tell me what's wrong with them.
-
Alas, is there any news for the colission detection bug?
I so wanted to get the new Galaxy out before christmas that I converted it in PCS1.. all looked well. Then I Re-edited all POF data in PCS2 and the colision problem returned. :(
-
I once mentioned my problem with copying/adding turrets in PCS2, well, I tried the actual release candidate and, guess what:
Oh my GOD it's so HORABLE!!!
*ERROR*:Array out of bounds!
That's BAD!
(well, at least the error message is funny ^^)
This happens whenever I copy a turret-subobject, no matter what I do with the copy (renaming, relocating, doing nothing...). Well, there're some models that work, it's just random if they work or not. Whatever, here's a list of models that work and don't work, perhaps it's useful to know this when tracking down the bug.
Working:
GTD Boreas from Inferno R1
GTBC Blade by Trashman
Not Working:
GTCar Fury by Trashman
GTCa Galaxy v.1/2 by Trashman
Cobra Class Frigate by Trashman
GTD Sirona by c914
GTFg Retribution by Trashman
Blade v2 by Trashman
NTCv Echelon by Trashman
GTCv Reyena by c914
-
thanks for the bug report.. please put it in mantis
i promise i'll make an effort to drag myself away from vanguard: saga of heroes and work on PCS2.... but we have 50% XP bonus until jan 3rd so i'm working on my crafters
yes.. yes. i sold my soul to MMOs.
-
Sweet... I just realized you can add/delete subsystems now. :nod:
...and you can move them between levels.
-
yes.. yes. i sold my soul to MMOs.
Frak. We'll never get PCS2.
-
nah.. you will - i must make myself code more for FS2 in the next year because i need to learn Taylor-fu and other gaming greatness as i should be graduating next december
-
/me imagines a monkey walking across the stage, pausing, turning to the audience and going, "I know Taylor-Fu".
-
*slams head against the table...again...and again*
Damn...collions..detection...damn...go-trough...faces!
-
Ok.. so i'm looking through the code trying to find the cause of why the bounding boxes are switched..... needless to say it couldn't have been something easy like me swapping min/max on an asignment in conversion *Sigh*
-
New build posted - any model with fux0red bounding boxes will need to be reconverted from COB - the bad bbox problem should not come back
-
You're my hero Kaz. :)
-
Cool. :) What was the problem?
-
Cool. :) What was the problem?
could not reproduce - but i had some stuff from trashman that let me compare models from old builds vs new and it seems that the older builds had a missing coordinate space conversion somewhere
-
So, does this only fix problems introduced by older PCS2 builds, or can we use this new build to fix POFs with faulty collision detection produced by the 3DS Max exporter ?
-
you have to recompile the old ones
and PCS2 has always recompiled the 3DS max exporter's models.. it doesn't recognize that exporter as "valid" (ie it won't cache BSP from it)
-
By recompiling you mean via COB in TS ?
Using COB means no smooth groups, which is the main reason I use the 3DS max exporter.
-
no.. when PCS2 opens a POF it decompiles the BSP into PCS2's internal format, PMF.
While it's opening the POF it checks to see if it recognizes the compiler that generated the POF as valid (last version of PCS1, latest PCS2 compiler, or [V]'s compiler) if it recognizes the compiler it "caches" the BSP data, otherwise it discards it and recompiles the BSP on save.
-
So, opening a Max exported POF in PCS2 and resaving as POF recompiles the BSP data without changing any smoothing data of the polies ?
*Goes of testing*
EDIT: Oh yes, it works ! Perfect collision detection with the perfect shading of Max exported models. :yes: You just made my day, I can now finally throw Turdspace back down to the lowest pits of hell from where it came.
-
Kazan. Just a note to say well done for getting PCS2 to RC1. Maybe they'll unmonkey you now as a sign of gratitude?
-
Well, thought i'd try it out and see what all was different. only one problem. Crash to desktop on launch...doesn't even finish loading. Do i put the error report on the mantis or here as a file?
-
I'm finding it likes crashing when writing to cob.
@ skygunner58203
Did you put the dll pack files in the same dir as the pcs exe file?
-
yep. Running XP pro on a 1.2 GHz system with a GeForce 4 MX440 AGP card and 389 megs of ram....yeah...my compy is a piece of work....doesn't even have a proper case. its using my desk as a case until i get a new one.
-
You just made my day, I can now finally throw Turdspace back down to the lowest pits of hell from where it came.
*Burs Col.Fishguts on a pole for heresy*
-
I'm finding it likes crashing when writing to cob.
@ skygunner58203
Did you put the dll pack files in the same dir as the pcs exe file?
send me the offending model pls
Well, thought i'd try it out and see what all was different. only one problem. Crash to desktop on launch...doesn't even finish loading. Do i put the error report on the mantis or here as a file?
most likely bad video drivers
-
Well i checked my drivers....they are the best i can get for this card. 81.98 nvidia drivers. If i install any higher my card doesn't work.
-
doesn't mean the drivers aren't the problem. no reason for it to be CTDing other than something wrong with your system's openGL
-
I'm finding it likes crashing when writing to cob.
send me the offending model pls
The ones I noticed were all SteveO pof files
http://www.mediafire.com/?4njyauxjruw (http://www.mediafire.com/?4njyauxjruw) (mig343)
They all seem to crash at the last stage -
So I tested some FSport models 3_0_4.vp
The ones that seem to cause the crash are the bigger ones
cruiser01b
karnak
capital01-repulse
capital01-myrmidon (didn't test more)
So then I tried the V original Sath supercap2s-01 - also crashes
-
2008-1-13 build posted
please check if inverted bounding boxes still exist - to check this your MUST compile from .cob to .pof and then use that .pof to open/save open/save several times
any pof with the error already present will probably continue to show the error - i need to make sure the error isn't being introduced into good models.
-
Just curious, do you know if Bob committed everything in his most recent 1-13 build, and is there anything additional you've added on top of that build's stuff, or should they be pretty much the same?
-
it should have everything I've done untill just before he posted, there is very little I have that isn't in CVS.
-
I'm afraid this one appears to undo all the speed improvements Bobs latest one has, and takes approximately twice as long to load up pofs. (22 seconds for the loki vs the previous 12)
And how do I tell if the bounding box problem is present or not? Open a suspect model up in debug fred?
-
that's be cause he disabled them because he doesn't "know where this 'dismal render performance complaint' is coming from".
well it seems as if that's going to have to wait untill after we make our official release, as per the loading issue, he probably didn't disable the VBO creation code which is slow as hell due to there not being a good way to approximate the size of the buffer (and no way to precache our vector class). I should probably go turn that off so he isn't tempted t delete everything.
-
I should probably go turn that off so he isn't tempted t delete everything.
at most i would #ifdef
-
2008-1-13 build posted
please check if inverted bounding boxes still exist - to check this your MUST compile from .cob to .pof and then use that .pof to open/save open/save several times
any pof with the error already present will probably continue to show the error - i need to make sure the error isn't being introduced into good models.
I still get this very same issue. (http://www.hard-light.net/forums/index.php/topic,41648.msg1041108.html#msg1041108)
But I haven't compiled from cob. As I say in that post:
- I open Comm2S-01.pof from Mediavps 3.6.10 beta.
- I insert an Enter in Special Points > $core > Properties.
- I save the pof again.
- I watch the model in F3 Lab. (Xt1207 debug).
My favourite question :p : Do you want me to Mantis it?
Nevertheless OGL warnings are gone and textures and submodels are outlined again. :yes:
-
look at the model in the lab or modelview or PCS1 - not them
open it in PCS2 - are they flipped from what they were before
if no, the problem does NOT persist and you MUST recompiled from .cob
-
look at the model in the lab or modelview or PCS1 - not them
open it in PCS2 - are they flipped from what they were before
if no, the problem does NOT persist and you MUST recompiled from .cob
I don't know if I've understood you but I cannot see any difference because:
- There's a damm not-so-invisible invisible texture in the middle.
- Comm2S-01.pof has spherical symmetry from its centre. You can't see any mirroring effect.
I know it seems being a bit lazy but, please check it yourself who are much more expert. It shouldn't take you much time. I feel myself like I'm blind-testing ...
-
you don't have to look at the model - it's all values in the header editor.
three coders cannot replicate this error: it's fixed. any models corrupted by it will have to be recompiled from .cob
-
you don't have to look at the model - it's all values in the header editor.
three coders cannot replicate this error: it's fixed. any models corrupted by it will have to be recompiled from .cob
OK, I'll PM DaBrain (who made the model) while giving him the info about what caused the Mantised error (ie the missing Enter code).
-
We've moved to RC2! http://www.hard-light.net/forums/index.php/topic,51649.0.html