[Bobboau]

it's still produceing holes in the model?

[TrashMan]

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.

[Bobboau]

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.

[TrashMan]

I'll give it a try then...

[Vasudan Admiral]

Bob; this one has killed the bounding box offset problem that was causing the poly trimming from the previous page. Awesome!
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.

[Kazan]

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

[Bobboau]

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.

[Bobboau]

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.

[Bobboau]

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.

[Kazan]

so what was the verdict? this test is producing stable, better balanced, POFs?

if so then it should no longer be expirimental

[Vasudan Admiral]

Not encountered any problems with it thus far.

[Bobboau]

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.

[Water]

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. 

[Bobboau]

not at this moment but there will probably before too long

[Kazan]

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

[Bobboau]

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.