[Bobboau]

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. I tried to make it expand subobject bboxes around children.

[Kazan]

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);

[Bobboau]

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.

[Kazan]

that would work too.. just need a little extra space around it for safety

[Bobboau]

localy, I just removed the scaling factor leaving the +/- 0.1 it seemed to work.

[Kazan]

kk

[Bobboau]

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.

[TrashMan]

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.

[Bobboau]

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 is updated

[TrashMan]

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....


EDIT - converted model with normal PCS and tested. Everything works normally...so it is PCS2

[Bobboau]

now just to be clear, this happens with all versions of PCS2 or just the recent experimental ones (this thread)?

[TrashMan]

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

[Kazan]

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

[Bobboau]

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?

[Kazan]

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

[Bobboau]

oh, didn't know that, well lets give this a shot...

[Bobboau]

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?

[Water]

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.

[Vasudan Admiral]

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 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?

[TrashMan]

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.