BSP file: a couple of question linked to geometry

[Immortal_BLG]

Hello!

Is it possible to correctly shift planes?
If so - how to do this?
I need to shift the clip-planes so that their distances was the same distances of the point-hull planes.

I do so:

const Math::Vector3D hullSizes[Hull_Total][2u] =
{
	/* Mins */                                /* Maxs */
	{Math::Vector3D (  0.0f,   0.0f,   0.0f), Math::Vector3D ( 0.0f,  0.0f,  0.0f)},	// Hull_Point (0x0x0)
	{Math::Vector3D (-16.0f, -16.0f, -36.0f), Math::Vector3D (16.0f, 16.0f, 36.0f)},	// Hull_Human (32x32x72)
	{Math::Vector3D (-32.0f, -32.0f, -32.0f), Math::Vector3D (32.0f, 32.0f, 32.0f)},	// Hull_Large (64x64x64)
	{Math::Vector3D (-16.0f, -16.0f, -18.0f), Math::Vector3D (16.0f, 16.0f, 18.0f)}		// Hull_Head  (32x32x36)
};

const Math::Vector3D offset
(
	plane.normal.x >= 0.0f ? hullSizes[hullIndex][0u].x : hullSizes[hullIndex][1u].x,
	plane.normal.y >= 0.0f ? hullSizes[hullIndex][0u].y : hullSizes[hullIndex][1u].y,
	plane.normal.z >= 0.0f ? hullSizes[hullIndex][0u].z : hullSizes[hullIndex][1u].z
);

plane.distance -= Dot (offset, plane.normal);

but this won't work for some planes (for example floor) - this conversely shifts plane to opposite side.

Please help.

[SamPlay]

My guess is that what you implicitely want is to shift FACES.
Shifting their supporting planes does not work if the face and its plane have opposite normals, which cannot be always avoided.
I think it is not possible to get a proper thickenning of the world based on PLANES alone.
You may want to have a look at Zoner's Half-life tools ( qcsg and qbsp i believe) to see how they do it.
But actually, the right way to do that is by performing a tweaked Minkowsky sum of the hull and the map.

[Immortal_BLG]

Hello SamPlay!!
Thank you for helping!

My guess is that what you implicitely want is to shift FACES.

No. I want to shift clip-planes. My goal point-trace(not trace hull) trough clip-nodes. Now with clip-nodes I can trace only hulls (human, large and head).

But actually, the right way to do that is by performing a tweaked Minkowsky sum of the hull and the map.

Sorry stupid me, but can you give some links to examples in C++ of Minkowski sum.

[The Storm]

Quick google: http://mathworld.wolfram.com/MinkowskiSum.html

[Immortal_BLG]

I read it but did not understand how this relates to the clip-planes - sorry

[The Storm]

Me too.

[SamPlay]

How does Minkowski sum relate to collision? : google for"Minkowski sum bsp".
Almost all references on the first page are interesting.
I am using it to (re)create bsp's for hulls (obviously..) different than the "point-hull".
After thought: maybe "minkowski sum collision" would be better...

[SamPlay]

Originally Posted by Immortal_BLG

Hello!

Is it possible to correctly shift planes?
If so - how to do this?
I need to shift the clip-planes so that their distances was the same distances of the point-hull planes.

I do so:
...
but this won't work for some planes (for example floor) - this conversely shifts plane to opposite side.

Please help.

To be sure I understand what you are looking for:
1. the point-hull bsp provided in the bsp file, as opposed to the 3 others bsps ( human, head,..) is used in HL for drawing, not for movement( ie collision detection); so some clipping ( blocking) faces are not taken into account when building the point-hull bsp tree because they are not drawn.
I assume you want a COLLISION bsp tree for the point and not a DRAWING bsp tree; so you use one of the other bsp trees as a starting point ( because it takes clipping faces into account), and "moving back" its (clipping) planes so that the "thickness" resulting from the hull is reduced to zero, reducing implicitely the hull to a point.
Is that right?
If it is right, I do not see how you can guarantee that you will get all the original planes.

As regard your code, I cannot see how the code itself can be right in some cases and wrong in some others.
I mentionned FACES instead of planes because in general the normal of a clipping plane alone cannot tell if the SOLID ( or move-blocking if you wish) side is in front of the plane or in its back. On the contrary, the "contents" data of a face always describes what is in its back ( but the face normal maybe equal or opposite to its supporting plane one).
My conclusion is that your code is right ( providing plane.distance has the right signing!), but you make an assumption on the meaning of the plane normal relative the SOLID side which is sometimes right,sometimes wrong.

EDIT I forgot: your code is ok in principle but there is a tweak in the way the bsps are build: the planes are actually shifted horizontally by a CONSTANT value, as if the hulls were vertical CYLINDERS.

[Immortal_BLG]

google for"Minkowski sum bsp"

I have found your site in search results (the fourth under the account) - so, I am bad with it have familiarized, since knew about it long before have learned about Minkowski

Is that right?

Yes - that's what I want

Thanks for the detailed response!

		//add the offset non-axial plane to the expanded hull
        VectorCopy(current_plane->origin, origin);
        VectorCopy(current_plane->normal, normal);

		//old code multiplied offset by normal -- this led to post-csg "sticky" walls where a
		//slope met an axial plane from the next brush since the offset from the slope would be less
		//than the full offset for the axial plane -- the discontinuity also contributes to increased
		//clipnodes.  If the normal is zero along an axis, shifting the origin in that direction won't
		//change the plane number, so I don't explicitly test that case.  The old method is still used if
		//preciseclip is turned off to allow backward compatability -- some of the improperly beveled edges
		//grow using the new origins, and might cause additional problems.

		if((g_texinfo[current_face->texinfo].flags & TEX_BEVEL))
		{
			//don't adjust origin - we'll correct g_texinfo's flags in a later step
		}
		else if(g_cliptype == clip_legacy || (g_cliptype == clip_precise && (normal[2] > FLOOR_Z)) || g_cliptype == clip_normalized)
		{
			if(normal[0])
			{ origin[0] += normal[0] * (normal[0] > 0 ? g_hull_size[hullnum][1][0] : -g_hull_size[hullnum][0][0]); }
			if(normal[1])
			{ origin[1] += normal[1] * (normal[1] > 0 ? g_hull_size[hullnum][1][1] : -g_hull_size[hullnum][0][1]); }
			if(normal[2])
			{ origin[2] += normal[2] * (normal[2] > 0 ? g_hull_size[hullnum][1][2] : -g_hull_size[hullnum][0][2]); }
		}
		else
		{
			origin[0] += g_hull_size[hullnum][(normal[0] > 0 ? 1 : 0)][0];
			origin[1] += g_hull_size[hullnum][(normal[1] > 0 ? 1 : 0)][1];
			origin[2] += g_hull_size[hullnum][(normal[2] > 0 ? 1 : 0)][2];
		}

		AddHullPlane(hull,normal,origin,false);

- From zhlt hlcsg brush.cpp ExpandBrush() function.

Maybe is possible to find 'origin'(also known as point0 for computation hull plane normal) from code above by some equation - if possible?

[SamPlay]

well if you do
'origin[0]-=' instead of 'origin[0]+=' , you should get what you are looking for.
Now that I understand your goal, Minkowski sum will not help you! Zhlt should have use it instead of their code you show, and the problems mentioned in the top comment of zhlt code would not haved occurred ( when creating and displaying faces from non-pointhull bsps, it really looks silly!).
Also, forget about the EDIT ( about 'vertical CYLINDER'), it is a mistake.