shithub: nanobsp

Info  •  Files  •  Log  •  Branches

changed the `cost` calc, dramatically reducing # of nodes/subsecs.

The cost assigned to splits is a *lot* more important than I thought.
Increasing the cost of splits (relative to the left/right difference)
helps to make the BSP tree smaller, which I find counter-intuitive.

This commit also increases FAST_THRESHOLD, so that better partition
selection can kick in earler.  Doubling it from 64 to 128 had a big
impact, but doubling it again not really, hence kept it at 128.
Naturally the larger the value, the slower the build takes.

--- a/nano_bsp.c

+++ b/nano_bsp.c

@@ -37,7 +37,7 @@

 #define DIST_EPSILON  (FRACUNIT / 64)

-#define FAST_THRESHOLD  64

+#define FAST_THRESHOLD  128

 #undef MAX

@@ -439,8 +439,8 @@

 	if (vert_ok && horiz_ok)

 	{

-		int vert_cost  = abs (v_eval.left - v_eval.right) * 100 + v_eval.split * 17;

-		int horiz_cost = abs (h_eval.left - h_eval.right) * 100 + h_eval.split * 17;

+		int vert_cost  = abs (v_eval.left - v_eval.right) * 2 + v_eval.split * 11;

+		int horiz_cost = abs (h_eval.left - h_eval.right) * 2 + h_eval.split * 11;

 		return (horiz_cost < vert_cost) ? horiz_part : vert_part;

 	}

@@ -468,7 +468,7 @@

 		if (BSP_EvalPartition (part, soup, &eval))

 		{

-			int cost = abs (eval.left - eval.right) * 100 + eval.split * 17;

+			int cost = abs (eval.left - eval.right) * 2 + eval.split * 11;

 			if (cost < best_cost)

 			{

-- 

⑨