[Kazan]

oh getter.. gmail blocked your email.. but don't worry about it - see if the next version i release fixes the bugs

[Kazan]

holy crap.. i'm hitting polygons where the magnitude of the cross product of the two lefts of the polygon is ZERO!!!!!

wtfh!

[Kazan]

oh man.. it's a rounding error due to the precision of float

[Bobboau]

not completly sure if splitting the poly is needed (or wise) but the basic algorithm should be basicly

have two output polies, and one input poly

start at the first point in the input poly,
check the distance from the plane, if it's positive put it into the first output poly, if negitive the second, if the next point is not on the same side of the plane find the point on the line segment that intersects the plane and add that point to both lists, do this for each point untill all points are done.

(if applicable)remove the input poly from what ever list it's in and replace it with the two output polies.

or at least that's the way I always do it.

models should not be triangulated, in fact it might be worth the effort to add code that finds polies that can be untriangulated (this would be more messy than it first seams because you'd need to make sure the texture space would be uniform across all of them).
untriangulated models do faster colision detection.

[Kazan]

the splitting code is commented out now.. it was causing problems.

I have rewritten the BSP generator completely from scratch and i'm debugging the flaws in the output right now

[Bobboau]

I would recomend just putting the intersected polys (or should I say the sortnorms that lead to polys on the split plane) on the onlist, that's probly what I'd do if writeing the BSP generator myself.

currently the BSP isn't used at all (I tryed to use them in decals, but I don't think it does any good, and in a while this'll get changed), in the not to distant future this will probly change, but it won't need to be 100% acurate. if it's used for poly sorting for front to back and back to front rendering it won't realy be that bad most of the time if it isn't absolutely perfict.

the only thing that the sortnorm chunck gets is

if (!mc_ray_boundingbox( vp(p+56), vp(p+68), &Mc_p0, &Mc_direction, NULL ))   {
   return;
}

in model colide, everything else just skips on through pre->front->on->back->post without doing any checking

and as far as I have been able to tell the only thing the pre and postlists do is specify sections of the BSP that should be processed before the current one, no idea why this would be done, but it is, and it seems like they are used.

and you do know of POFdview, yes? it would probly come in REALY handy trying to reverse engeneer V's BSP ideas.

[Kazan]

i have it writing a BSP tree that PCS 1.x and 2.x will both read.. modelview and fs2open refuse to load it - fs2 open gave me a malloc failure.. but having two MSDEVs open and one huge app in the debugger caused my puter to freak out.. reboting it right now as i type

[Kazan]

ooh.. it's crashing in the IBX generator...

[Kazan]

it shoots the smooth phong shading all the hell... but the new models will load in model view and fs2 open

it think it's just associating the wrong normals...

apparently the BSP walker in fs2_open and in modelview are kinda flakey -- they're iterating across the tree instead of recursing on it -  mine was the only one implemented prperly according to the theory - inserting some extra terminators into the data fixed that up.

[Goober5000]

Originally posted by Kazan
rebooting right now as i type

apparently the BSP walker in fs2_open and in modelview are kinda flakey -- they're iterating across the tree instead of recursing on it -  mine was the only one implemented prperly according to the theory - inserting some extra terminators into the data fixed that up.

Is it possible that yours is the only one not implemented properly?

And incidentally, you don't need to make 10 posts in a row to give hour-by-hour updates.  Editing is A-1 SUPAR.

[Bobboau]

you know that the normal indecies are for the total list of them, not the per vert list, as stupid as that is.

[Kazan]

Originally posted by Goober5000
:lol:Is it possible that yours is the only one not implemented properly?

yes and i got out the POF BSP/IDTA specs and a reference on BSP theory and found mine was right and that the new IBX one in the game along with the Modelview ones are wrong.

making them work is simply a matter of using the prelist_offset to immediately shove a BSP::EOF right after the sort norm so that they terminate looping

[Kazan]

Originally posted by Bobboau
you know that the normal indecies are for the total list of them, not the per vert list, as stupid as that is.

yeah.. i know.. but it was still not coming up right..... *plays with the code again*

[edit]
code blocks unneeded.. FIXED

[Kazan]

i submit this image for p1mpage



Current Todo List:

• Implement Progress Bars for loading/saving
• Implement Error Messages for loading/saving
• Implement standard editor windows
• Implement PMF::LoadFromCOB
• Implement PMF::SaveToCOB
• Implement Context Renderer
• Impelement Geometry Editor

[Bobboau]

/*pimpage accepted*/

post new build now.

no editing yet?

[Getter Robo G]

Curious, what are the limits for PCS2 going to be meshwise as in Poly Count, Rexture Map number, Turrets, and subobjects?

[Kazan]

the internal format doesn't have limits.. and the new BSP gen code precalcuates the size of the BSP instead of dynamically allocating a fixed 4meg scratch pad.. so theorectically... there are no limits

[Bobboau]

I thought you said that it was impossable to precalculate?

[Kazan]

with the old code which a spruced-up copypaste of the cob2fs2 code

i completely rewrote my BSP compiler from scratch

the only real difference that i've noticed is that the new code generates a greater number of SORTNORM chunks, but i think that is related to me not having a 2s-only shortcut in the compilation [i have that commented out right now as it was causing problems]

[DaBrain]

Great!

I got a model here, that really refuses to convert. I hope PCS 2 willbe able to convert it.