q3map2 generates suboptimal collision planes for .ase models

(motorsep) #1

Hi all,

Below I will quote Maik “SavageX” Merten from Alientrap (Nexuiz team). I join them in report and request. Ydnar, please, don’t leave us hanging without properly functioning essential toolset.

Hello,

over at Alientrap.org we’re trying to embed .ase terrain into q3bsp files but
encounter severe collision issues (falling through the floor etc.) doing that.
We’re using the DarkPlaces engine for our projects (Nexuiz and Zymotic) and this
problem is a possible blocker for future releases.

This is what LordHavoc, author of the DarkPlaces engine, told me about the problem:

“q3map2 generates two slightly different collision planes from .ase model
triangles that may intersect (producing a brush that clips off half or all of
itself), which breaks the DarkPlaces collision brush builder because it needs to
reconstruct qhull data for rotated box collisions (Q3A does not allow rotated
box entities so the point reconstruction is not an issue there), this problem
would go away if the backside plane was just a flipped version of the frontside
plane, which Q3A’s traceline should be able to handle (an infinitely thin brush
generated from a polygon)”

Thanks,

Maik “SavageX” Merten - lead maintainer of Nexuiz

Thanks.

(kamikazee) #2

You’re not Ydnar, but you could try to do something about it by yourself. The Q3Map2 source can be found in the GTKRadiant trunk on id’s Zerowing server.

You can just download the code and try to fix it, as it could be faster than waiting for Ydnar to show up.

(motorsep) #3

kamikazee,

I am not a coder. If I would be one, I wouldn’t bother asking maybe.
Another thing is when some very skilled coders (don’t want to mention any names :wink: ) looked into q3map2’s code, they said that there is no way they can fix anything cos the code is very hard to read and work with.
So I would rather wait for Ydnar :wink:

(kamikazee) #4

Seems Ydnar did indeed “hack” some code together:
From model.c, void InsertModel(…):

/* ydnar: giant hack land: generate clipping brushes for model triangles */

So I guess the code will be bugged.

A bit further down:

/* find nearest axial to plane normal and push back points opposite */
for( k = 0; k < 3; k++ )
{
	if( fabs( plane[ k ] ) > fabs( plane[ (k + 1) % 3 ] ) &&
			fabs( plane[ k ] ) > fabs( plane[ (k + 2) % 3 ] ) )
	{
		backs[ j ][ k ] += plane[ k ] < 0.0f ? 64.0f : -64.0f;
		break;
	}
}

I haven’t analysed what it exactly does, but this does seem to calculate the backface by adding or substracting 64 units.

(DerSaidin) #5

Could you just use separate clip brushes?

(motorsep) #6

You are funny :smiley:
Imagine terrain made out of alot of polygons in 3D app.
Now tell me please how can I create same terrain with brushes to match ASE mesh? (otherwise there is no purpose for using ASE files)

(Q.) #7

Hi.
I’m a workarounder rather than a coder.

To get an equivalent collision brushes you need to decompile the bsp in which autoclipped ase model was merged.
Now you can check the hole and fill it manually then merge the collision brushes into the original source.
Disabling the autoclippling, you can compile the same map again to restore the same result or better.