[Bobboau]

if you recoded the BSP to use an actual tree structure, and wrote code to rebuild that tree structure on the fly, you could put this in FSO.

note: this is actually not as hard as it sounds.
but for performance reasons you would have to run this in a separate thread.

[Aardwolf]

It looks great:



But there's lots of slivery triangles I gotta get rid of:



...preferably without screwing up my UV coordinates or vertex normals. There's a few other things I oughtta fix up, too.

[Nuke]

pretty cool, but is there any way to stop all the new tris from sharing the same vert? aparently it causes some smoothing and normal maping issues. on the other hand it looks ok from your renderer.

[Galemp]

Nope, not unless you add more vertices in the parent mesh for them to link to.

[Aardwolf]

Well, I could possibly make some sort of polygon reduction algorithm. Or I could add some more verts along the edges... it'd make more triangles total, but they'd be less squashed.

I think the reason mine still looks good is because I'm not re-generating the vertex normal vectors. All of the vertex normals are either the ones from the original meshes, or are those but interpolated (specifically, taking a weighted average of the verts of the original mesh's triangles, and renormalizing it). A model editing program would probably generate the vertex normals after-the-fact, and probably as a flat (i.e. not weighted) average of the face normals surrounding the vertex, thus making it looks stupid. But that's just speculation on my part.

Edit: Or I could somehow combine the added verts with the poly-reduction thing... somehow.

[Aardwolf]

Hm, idunno what to do next with this. There's a bunch of things that still need to be done, and I'm not entirely sure what order to do it, etc.

My un-ordered "TODO" list looks like this:

• Speed up existing functionality
• Rearrange the existing functions/classes (there's a bit of redundancy, I think)
• Mesh optimization... Adding more verts to eliminate slivers? Removing unneeded edges? Keeping references to the original triangles/geometry (i.e. quasi- N-gons)?
• Allow more kinds of generalization (without breaking existing stuff)
• Support for more than two operands simultaneously?
• Other stuff?

Advice is welcome!

[Aardwolf]

Thread-bump!

My interest in this project is somehow renewed. I've asked a bunch of people I know if they're interested in collaborating on this. Obviously no replies yet.

Edit: Oh hey, I put it on Google Code.

[Bobboau]

just as a stress test, why don't you code up a test where a bunch of random objects are placed randomly then added subtracted from each other.

also a feature you might want to look into is determining if an object has been split into two objects.

multithreading is also another thing you should be making sure is safe.

[Aardwolf]

Checking if it's been split into more than one piece? Actually, I think that's almost already in there. That is, it's already finding regions of contiguous faces (stopping when it runs into a cut), and then determining whether those regions are on the correct side of the other object. It probably wouldn't be too hard to modify the code to check for that.

But there's still some major refactoring that needs to be done, and I'm not sure whether that feature is something that should come before or after the refactoring.

By the way, since it's now on Google Code, anyone can check it out. So if anybody wants to become a contributor¹ or a committer², shoot me a PM.





¹Lets you comment on the Wiki, Issues, etc. (I think)
²Lets you commit SVN changes