Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Bobboau on July 01, 2007, 11:59:29 pm
-
ok, I desperately need people to do a few tests for me,
http://freespace.volitionwatch.com/blackwater/pcs2_BSPEX.zip
there are two builds in that zip, I need people to compare the in game performance, especially making sure there are not collision holes in either one of them, but also seeing if the game seems to run any faster or slower with one over the other, try to use your hungriest most polytastic models, (only do comparison tests between models that compile on both builds, the non-EX version has the fix-infinite-recursion code disabled amung other things, do mention if a model fails to compile on either build though) and put a lot of them into a test mission fighting each other with infinite waves. give me mean framerate differences and if you notice one causes framerates to be less consistent than the other this is also important. also in the "model comments" section, there are two stats I am very interested in, max BSP depth, and max polys per node, please relay this information along with the polycount of your largest submodel as soon as posable.
Please, the fate of _all man kind_ lays in your very hands! Go on! save the day! Get the girl! Do not let us down!
and do it quickly...
-
Save the cheerleader!
-
I'll start testing when I get home in 4 hours time. I have 2 massive models I can test this with, one of them being a 230 000 poly test model which has no detail boxes. If that doesn't cut down the framerate, I don't know what will. ;)
What sort of trends are you expecting and/or hoping for?
Oh, and also while I'm here, does PCS2 or FS2 have a maximum polycount per object limit? PCS1 seemed to have one at about the 15 000 poly mark, above which it would fail to convert. Is that limit (or any other important limits for that matter) still in force with PCS2?
-
well with my modifications I was hopeing to get log2 complexity in the tree, that is for however many polygons there are in the tree it would take no more than log2(howevermenypolys) steps down the tree to get to them, most of my tests have shown slightly better than that, it won't make it compile much-if-any faster but it should make colision detection more eficent.
for a model with 230000 polys I would expect a max tree depth of 17 or thereabouts. which would make it 3 time slower than a model with 230 polys.
PCS is limeted by how much ram you have, FSO is limited to models with about 4.2 billion unique verts (verts than have the same position, lighting normals, and UV coords).
but in a practical sence I'd say about 50,000 is were the technology will let you go today.
-
Do you have a preference for which FSO build it gets run under?
-
not realy, the most recent/stable one you have handy.
-
I may have just thought of a way to use the BSP's structure to help build it'self faster.
-
ok, I have updated the zip in the first post, I have included a third exeuteable which has an optomiseation which should help speed up compilation, though I figured out a large portion of the time spent is actually in creating a unique vertex list, which seems odd to me considering both the cob and pof formats have one to begin with.
-
First build test only
115023 poly -- 40 objects -- smallest 4, largest 15810 poly -- radius 5726
----------------------------------------------------------------
pcs2 -- max Bsp depth 37 --- most polys in a single node was 1
Freespace xt build crash
pcs2_BSPEX -- crash with no error message. Didn't exit on the 15k object but a 9k object. (B2)
----------------------------------------------------------------
Split 15k object into 2 objects
Pcs2 -- max Bsp depth 32 --- most polys in a single node was 1
Freespace loads ok - missing faces and stuff like previous pcs2 builds (with this model)
FPS - approx equavalent to pcs1 (didn't test too hard)
Collision detection -- FPS - less drop with this one (firing weapons at it)
previous was a 75% drop - this one less than 50% drop
pcs2_BSPEX -- crash with no error message. Still crashed at same object (B2) (I actually reduced it to 8k for this test)
--------------------------------------------------------------------------
Note:
both builds stop loading if they encounter a group containing no mesh but 2 sub groups with mesh
----sub Group
--------sub group with mesh
--------sub group with mesh
Pcs1 didn't have a problem with this. I think previous pcs2 was ok as well, but didn't check to confirm
-
third executable fails even earlier.
-
ok, I'm making an update if the third one still fails email me a cob.
-
First build test only
Freespace loads ok - missing faces and stuff like previous pcs2 builds (with this model)
the hell? is this a problem with the model or PCS? can you give me the cob or a screen shot at least?
FPS - approx equavalent to pcs1 (didn't test too hard)
slightly disapointing, but not totaly unexpected, FSO doesn't currently use the BSP tree for rendering
Collision detection -- FPS - less drop with this one (firing weapons at it)
previous was a 75% drop - this one less than 50% drop
good, it does have a noticeable improvement. were there colision holes you could fine?
-
Freespace loads ok - missing faces and stuff like previous pcs2 builds (with this model)
FPS - approx equavalent to pcs1 (didn't test too hard)
Collision detection -- FPS - less drop with this one (firing weapons at it)
previous was a 75% drop - this one less than 50% drop
Ignore this part from previous post.
Just tested using pcs1 - both have similar missing faces and collision detection. I scaled the whole model up instead of using pcs cob scaling - not sure what else I changed.
Going to see if i can find an earlier model that was stable under pcs1
-
Found an earlier file
pcs1 - didn't spot any missing faces in a quick fly around.
pcs2 - missing faces - bsp depth 29
pcs2_bspex - crash.
Edit: that was the first version of pcs2_bspex.
-
I just caught a crash bug, I'm going to do a little more testing then upload a new zip then passout on my keyboard.
-
Ok, given them all a pretty thorough testing with that huge model, and well...it doesn't look too great. :(
In this model there are sixty 3840 poly spheres arrayed around a parent object - a cube. All the sphere's are set up as separate subobjects of that cube.
COB scale factor in all programs was 1.00.
Each test involved opening from the SCN and then saving as POF, closing and reopening PCS2 to get the in PCS2 results, then going in-game to get the in game results.
Here's the source SCN file these came out of: http://sectorgame.com/ti-file-dump/VasudanAdmiral/test2.zip (copy & paste link)
====PCS1:====
==Model Comments:==
Input was: 61 Materials, 61 Groups, 64 Lights, and 61 PolyGroups.
Started with 115328 and ended with 115328 points, in 230412 and 230412 faces respectively. Compile time was 228.656000 seconds.
==Results:==
In PCS2:
- Correctly displayed
- BSP debug mesh (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/BSP_Debug_PCS1.jpg)
- 61Mb POF file
In game:
- Consistant 47FPS (though it was slowly dropping, I suspect a memory leak in FS there)
- Fully collidable mesh
- All visible polys were shootable
- No holes
====PCS2 Normal Build====
==Model Comments:==
PMFSaveToPOF: Compiled on PCS 2.0 Beta with PCS 2.0 Compiler Version 1 RC2
max BSP depth was 22
most polys in a single node was 1
==Results:==
In PCS2:
- Incorrectly displayed - massive holes all over model. ("Holy Snowballs Batman!!") (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/HolySnowballsBatman.jpg)
- BSP debug mesh (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/BSP_Debug_PCS2.jpg)
- 42Mb POF file (probably smaller due to massive holes)
In game:
- Consistant 47FPS again
- Nothing but the cube in the centre was collidable
- All visible polys were shootable
- Huge holes visible in PCS2 are also present in-game
====PCS2 BSPEX Build====
==Model Comments:==
PMFSaveToPOF: Compiled on PCS 2.0 Beta with PCS 2.0 Compiler Version 1 RC2
max BSP depth was 16
most polys in a single node was 1
==Results:==
In PCS2:
- Incorrectly displayed - massive holes all over model again
- BSP debug mesh (looks leaner) (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/BSP_Debug_PCS2_BSPEX.jpg)
- 38Mb POF file
In game:
- Consistant 45FPS
- Nothing but the cube in the centre was collidable
- All visible polys were shootable
- Huge holes visible in PCS2 are also present in-game
====PCS2 BSPEX2 Build====
==Model Comments:==
PMFSaveToPOF: Compiled on PCS 2.0 Beta with PCS 2.0 Compiler Version 1 RC2
max BSP depth was 16
most polys in a single node was 1
==Results:==
In PCS2:
- Incorrectly displayed - massive holes all over model again
- BSP debug mesh (almost same as previous) (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/BSP_Debug_PCS2_BSPEX2.jpg)
- 38Mb POF file
In game:
- Consistant 44FPS
- Nothing but the cube in the centre was collidable
- All visible polys were shootable
- Huge holes visible in PCS2 are also present in-game
-
posted while I was again...will give that a look.
[edit] that scene you posted is forbiden[/edit]
[more edit]oh, copy paste, nevermind then[/more edit]
ok, I am uploading a new zip with a new version of EX2 with a crash bug fixed and sevral other improvements over the first few itterations. it should be genorateing exceptionally effectent BSPs now, make sure there are no holes. and it should be compileing it a lot faster. we may have to do a rather large restructureing of how geometry is stored.
eehh man I've been up for like 24 hours.
I think the no colideing with anything but the middle bit is because we arent takeing subobjects into ac**** when calculateing bboxes, unless I screwed that up, but I never messed with that...
you might want to try makeing the sphere's in the corners part of the main hull, that would work around that for the moment.
what the hell the bounding volumes are like shifted out...
...that would explain those holes, I think I know what's causeing that...
-
ok, I MUST go to sleep now, but I think I may have fixed the missing poly issue, the won't colide with children outside it's own bbox issue remains. so be aware of that.
http://freespace.volitionwatch.com/blackwater/pcs2_BSPEX2.zip
I think that build should rock very hard.
-
unless you changed the behavior bob before you started tweaking on this "missing polygons" in the POF meant "****ing A! you tried to make me go into infinite recursion, screw that!"
IE "Bad geometry" was simply truncated
PS: inside a single BSP tree all a sortnorms children MUST fit within it's bounding box - hence in GenerateTreeRecursion the calls to grow node's boundbox to make sure they include node->front and node->back
[edit]
*faceplant* what did you do to my bounding box functions! there was a reason there were two seperate ones (one for an individual polygon and one for multiple)
-
i've reverted your changes to the bounding box functions
MakeBound(vector3d &Max, vector3d &Min, kaz_vector<int> &polylist, kaz_vector<pcs_polygon> &polygons) is for making a bounding box that fits around an entire group of polygons
BoundPolygon(vector3d &Max, vector3d &Min, int polygon, kaz_vector<pcs_polygon> &polygons) is for a single polygon
MakeBound(...) uses BoundPolygon(...)
there is quite a large possibility that what you did broke bounding boxes
-
I figured out what was causeing the missing geometry, it was when the top level parent bbox got scaled up in MakeTree, the *1.1. when an object is not centered at the origen this causes the sides of the bbox faceing the oregen to move away from it. and sence the parent bbo is shifted so that it no longer has some polygons in it, those polygons are no longer found when recurseing.
for example, you have a subobject who is positioned at z=40, there max z would be 50 and min z 30, so the smallest z value of any polygon would be 30, but if we multiply 30 by 1.1 we get 33, so there is now three meters of geometry that is sitting outside the bbox.
and the change to that function reflected a change in the data it was working on, poly_num became a vector of ints rather than just an int.
anyway I updated this build (http://freespace.volitionwatch.com/blackwater/pcs2_BSPEX2.zip). I tried to make it expand subobject bboxes around children.
-
good call bob...
i think i know a solution do
vector3d center, Min, Max;
Max = center+((Max-center)*1.1);
Min = center+((Min-center)*1.1);
-
that was my first thought, but isn't this going to make the bboxes TOO big? (on larger object) your going to have an extra 100 meters of empty-but-still-getting-tested space. I think we should just add a simple fudge factor.
-
that would work too.. just need a little extra space around it for safety
-
localy, I just removed the scaling factor leaving the +/- 0.1 it seemed to work.
-
kk
-
other stuff I did locally was I made the tree balance it'self so either side of the node would have about the same number of polys in it (resulting in a more efferent shallower tree). and I also used the results of a poly culling in the generation of the next node (i.e. I passed contained, and it only checks the polys listed in there. so the deeper you go things get twice as fast, especially with the previous thing). I also removed degenerate nodes (nodes with only one child). oh, and I made bboxes fit tighter (but still gave them the fudge factor, they had huge swaths of empty space in them). currently the biggest time eater in BSP compilation seems to be in the generation of unique def points.
sense I woke up I was working on expanding subobject bboxes (not BSP) to fit around children.
-
I have no idea if this is PCS related or FSO related, but I ran across two strange issues:
1. It happens when you target the ship for the first time (no subsystems selected). Aside from the normal targeting bracket, I see another one..a big that looks like something the size of a engine subsystem is also selected.
Once I cycle trough subsystems it's gone...strangnes...
2. Subsystems and turrets have HUGE explosions..half hte size of the ship.
Models have been converted with PCS2 BSP build..using FSO 3.6.9.
-
sounds like we have a radius issue somewhere, is this just with these builds or does my sig build do this also?
and on a seperate note, I just found and fixed another ininite recursion (well it wasn't truely infinite, but big enough to crash, was able to iterate through the problem rather than recurse)
and the experimental zip (http://freespace.volitionwatch.com/blackwater/pcs2_BSPEX2.zip) is updated
-
Tried it with another veriosn of PCS2...still happens..and upon closer examination it only happens with TURRETS.. subsystem targeting boxes apepar normal and subsystems blow up normal...so it's related
Oh - and it doesn't go away by cycling trough subsysttems..it only appeared so to me since I didn't havea turret targeted then..
Here's screenshot - note the big bracket - that one belongs to the turret....
(http://img239.imageshack.us/img239/4905/screen0036df5.th.png) (http://img239.imageshack.us/my.php?image=screen0036df5.png)
EDIT - converted model with normal PCS and tested. Everything works normally...so it is PCS2
-
now just to be clear, this happens with all versions of PCS2 or just the recent experimental ones (this thread)?
-
So far I went trough 3 verions of PCS2...so I'd say all of them.. Kaz told me he thinks he knows that it is
-
it happened in my build from yesterday - i thought i knew what it was and put in something that makes POF object radius setting safer and had TM try it just now .. but it's still wrong so i dunno
-
just looking at a few radiuses it seems like the subobject's offset is getting added to the verts when you calculate it. objects further from the center have a larger radius than otherwise identicle subobjects near the middle of the model.
[edit]
subobject bounding boxes are in local not global coordinants, pcs_pmf_cob.cpp line 607
tempobj.radius = FindObjectRadius(tempobj.bounding_box_max_point, tempobj.bounding_box_min_point, tempobj.geometric_center);
should be
tempobj.radius = FindObjectRadius(tempobj.bounding_box_max_point, tempobj.bounding_box_min_point, vector3d(0,0,0));
[edit2] yup that fixes it.
if you want to test it check the experimental 2 build as that's my current code base.
hey kazan do you think I could have a branch for this?
-
you have all the access needed to create that branch
and that would a DOH moment... forgot bounding boxes are in local space - just a problem introduced by spliiting two seperate things done at once in PCS1 into their proper seperate parts in PCS2
-
oh, didn't know that, well lets give this a shot...
-
crap, it commited to the wrong branch, were the hell is the revert button...
oookkk.... I don't think I did it the right way, but I'm prety sure I just undid the changes of that commit...
ok, so I made a new branch, it wouldn't let me make the new branch with modified files, so I used my backup directory. then I used update specal to udpdate my branch code and suposedly redirect it to my branch, but it isn't, and when I tryed to comit that it went to the wrong one...
there is no commit specal or option to commit to a diferent branch, what the hell...
ok, so I have now made ANOTHER branch thinking I screwed up the first time, how the hell do you comit to a branch?!
and how do I undo the crap I just did?
-
pcs2 --- lab 39-50fps --game 20-22 fps -- max bsp 29 -- some missing faces
bxp_2 - lab 17-20fps --game 18-19 fps -- max bsp 24 -- very accurate bounding boxes (shoot test)
-------------------------------------------------------------------------------------------
new pof with b2+b2a (23k poly) merged and slighta+b merged (19k poly)
pcs2 -- fso crash --- max bsp 33
bxp_2 -fso crash** -- max bsp 24
** tested 3.6.9 + C05202007_r + 3_6_9-Xt_0615
--------------------------------------------
Same debug after each crash
Loading model 'baseline.pof'
IBX: Warning! Found invalid TSB file: 'baseline.tsb'
IBX: Starting a new IBX for 'baseline.pof'.
IBX: Starting a new TSB for 'baseline.pof'.
BMPMAN: Found EFF (fire-trans.eff) with 26 frames at 50 fps.
-
Sorry, it's bit unclear - is there a new build you want us to test? I gave the one in this post a try:
sounds like we have a radius issue somewhere, is this just with these builds or does my sig build do this also?
and on a seperate note, I just found and fixed another ininite recursion (well it wasn't truely infinite, but big enough to crash, was able to iterate through the problem rather than recurse)
and the experimental zip (http://freespace.volitionwatch.com/blackwater/pcs2_BSPEX2.zip) is updated
but it seemed to produce the same error.
If the situation might have changed with the errors in that long report on the previous page, I can re-run it for any new builds if needed?
-
Yeah, I'm also wondering if a new build will be available... I have to re-convert my Hybrid now, as apparently it suffers from the same problem. :sigh:
-
it's still produceing holes in the model?
-
I was reffering to the giant explosion and targeting boxes...
I converted the Hybrid with an older PCS2 build, so that's why I'm asking if a newer one has this fixed.
-
ok, well it should be fixed if it was the radius thing, I'm not sure if I had updated after I fixed it, so I just updated with what I have now to here
http://freespace.volitionwatch.com/blackwater/pcs2_BSPEX2.zip
which is were I will be putting the most recent experimental BSP builds.
and I am trying to ifdef all my experimental code, so I can commit it without compromising the existing code, if kazan likes any feature of the experimental stuff he can import it back to the stable code path.
ok, there was a second radius calculation when saveing to pof that I had missed the first time, it should now be fixed.
-
I'll give it a try then... :nod:
-
Bob; this one has killed the bounding box offset problem that was causing the poly trimming from the previous page. Awesome! :D
It doesn't yet take into account the children subobjects when calculating total bounding box area, which means I can only ram the cube in the middle.
Thinking about that issue though, as well as correctly caluclating it on POF save, might it be possible to allow the modder to change the values of the subobject bounding boxes as they are displayed in Subobject Info?
I'm remembering when you were trying to implement subobject translation in FSO, at least one of the issues was that if a subobject translated outside the collision detection bounding boxes of it's parents, the game had no way of knowing. What I'm wondering is that if you left it up to the modeler to make sure the bounding boxes in his model allowed for any and all possible subobject translation they wanted present in the model, you wouldn't have to make the game worry about it?
In fact, custom bounding boxes would allow for that visible but non-collidable geometry that is needed in some rare circumstances, so it wouldn't just be useful for subobject translation situations either. ;)
-
a SOBJ's bounding box doesn't have to contain that's SOBJ's children*
a POF's HDR2 bounding box has to contain all SOBJ's
[edit]
* atleast i didn't think so..... though... if PCS1 disagrees with me then i'm wrong
-
awww crap your right.... just looked into the FS source. why did I think that...
well... then why don't those sphere's colide?
I'm currently planning on moving the animation data to a subchunk of the subobject, so PCS can calculate maximum bounding boxes.
-
heh, I just noticed, after all that, it commited to the branch! HA!
ok, anyway, I'm going to let this simmer for a while as I fix main branch bugs and whatnot, do not think I am abandoning this, quite th opposite, I'm shifting my attention else ware to give people time to realy test this code without me putting up a new build every five minutes, I think it's in a prety good shape right now, so hopefuly there won't be too many huge bugs to worry about and it'll just be tweaks when I get back to this.
-
ok, I've gone about and manually copied the experimental code into ifdef blocks, there is only realy one function difference between them, and since neither I nor kazan seems to now how to use branching properly, I'm just going to use ifdefs, I so added some more statistic tracking and it seems that not only does the experimental BSP produce more balanced trees, but it does it 11 times faster than the regular BSP code (that was from testing one very complicated model).
I updated the zip, though there should not be any major diferences other than a few recent bugs have been fixed.
-
so what was the verdict? this test is producing stable, better balanced, POFs?
if so then it should no longer be expirimental
-
Not encountered any problems with it thus far.
-
I think it's working better, if you want to give it a test yourself I have it ifdefed with the _BOB_BSP_ preprocessor directive in the current codebase. it has three big advantages, the first being the trees it makes are typically a lot more balanced (and it usually has fewer multi-poly nodes too, second it is A LOT faster in terms of compilation speed (an order of magnitude faster, unfortunately tree construction is by no means the bottleneck), and third I have tried to feed it geometry to make it fail it simply will not crash. most importantly, baring things unrelated to BSP generation like submodel radiuses getting set to zero, I have not encountered any collision holes and a test mission with about 50 of some of the most ridiculously complex models I've got rarely dips below 30 fps.
I was planning on waiting until we got the 1.0 version officially released before trying to make it standard, but if you think it's good to go, making it the standard now sounds good to me.
-
In fact, custom bounding boxes would allow for that visible but non-collidable geometry that is needed in some rare circumstances, so it wouldn't just be useful for subobject translation situations either. ;)
Is there a way to tag a sub-object non-collideable and exclude it from the bsp tree? ^^ what VA said but less work. It's for a ground vehicle shadow, which bumps into the road kerb before the vehicle does. There are other places where it would get used. ;)
-
not at this moment but there will probably before too long
-
well it sounds like it's doing a better job (those radius bugs were unrelated right?) - so make it standard and bump the PCS2 compiler version number
-
yeah, the radius bugs were in the old code as well as the new, about as unaffected as you can get.
ok, I'l make it standard, as soon as I get done messing with the open texture externally thing.