Page 3 of 6

Posted: Wed Jul 14, 2010 7:15 pm
by mh
I wouldn't mind a copy of it, just to test that my fix actually does work with it, before you make any changes to your own engine.

(deleted stuff that wasn't actually needed; mental note to self: read the original code first!!! :oops: )

Also note the nifty "sv_novis" cvar. ;)

Posted: Wed Jul 14, 2010 7:41 pm
by Baker
goldenboy wrote:That sounds like the cleanest possible solution, but it's probably above my skill level to implement that.
My bsp understanding is limited, but I'd guess it is probably just commenting out this in SV_WriteEntitiesToClient in sv_main.c

Code: Select all

			for (i=0 ; i < ent->num_leafs ; i++)
				if (pvs[ent->leafnums[i] >> 3] & (1 << (ent->leafnums[i]&7) ))
					break;

			if (i == ent->num_leafs)
				continue;		// not visible
mh wrote:Also note the nifty "sv_novis" cvar. ;)
Hmmm :D

Posted: Wed Jul 14, 2010 7:50 pm
by mh
It's BSP entities only isn't it, so you'd need to get the model name (something like pr_strings + ent->v.model), check if the first char is '*', then ignore the PVS test if so.

It's a solution to this problem for sure, but one I'd be dubious about as there is a possibility of alias or instanced brush models also being big enough enough to need a fix. Add enough models to the mix, take a map that's well stocked with even just inline brush models (like ne_tower for example) and you're entering a world of hurt. I just prefer the more general fix, it seems cleaner overall.

Edit: my code works with this one.

Posted: Wed Jul 14, 2010 9:48 pm
by goldenboy
Confirmed, adapted mh's fix to FitzSDL/QS/RMQ engine. Works like a charm. Giant rotating bmodels, here I come.

Posted: Wed Jul 14, 2010 10:19 pm
by mh
Oddly enough, it also works perfectly with Enhanced GLQuake (aguirRe's engine) and he doesn't seem to have done anything to particularly fix this one - although I haven't looked too far yet. It does suffer from a "keyname too long" Sys_Error when parsing globals though, on account of the fact that he reduced the max key name length to 32 (from 64).

Posted: Wed Jul 14, 2010 11:20 pm
by goldenboy
Yeah, but I guess it doesn't rotate there.

There is also no flicker when the offending thing is turned into a simple func_wall.

The problem only appears if the thing rotates, and the engine actually supports the rotation, I think.

Posted: Wed Jul 14, 2010 11:25 pm
by mh
Of course, you're right (and you had mentioned it before now that I check back).

Posted: Wed Jul 14, 2010 11:47 pm
by Spike
if (ent->v.solid == SOLID_BSP &&
(ent->v.angles[0] || ent->v.angles[1] || ent->v.angles[2]) )
{ // expand for rotation
float max, v;
int i;

max = 0;
for (i=0 ; i<3 ; i++)
{
v =fabs( ent->v.mins);
if (v > max)
max = v;
v =fabs( ent->v.maxs);
if (v > max)
max = v;
}
for (i=0 ; i<3 ; i++)
{
ent->v.absmin = ent->v.origin - max;
ent->v.absmax = ent->v.origin + max;
}
}


that code will pick the biggest axis and assume that all are that large.
On a long thin (bridge) thing, your absmin/absmax is huuuge. It also extends up and down too, by the same distance...
This is even worse if you didn't change the origin in qbsp.

This is why a func_wall is fine, but anything bsp with rotation will flicker, and also why you need so many leafs.

Posted: Wed Jul 14, 2010 11:59 pm
by mh
It really should rotate the bbox, then build a new bbox around the rotated coords instead. I wonder though, would it still be possible for an entity to exceed 16 leafs even if that was done? I had originally put my code in to fix the very same problem with an elevator in apsp1.

I wouldn't dispute that handling the bbox better is one way of fixing this specific problem (and should probably be done anyway), but I would argue that it is more of a general problem which needs more of a general solution. It's perfectly possible to construct a huuuuuge brush model that exceeds 16 leafs without even having it rotate, for example, and we haven't even touched on huge alias models yet.

Posted: Thu Jul 15, 2010 6:35 am
by r00k
For some odd reason i have MAX_ENT_LEAFS at 256 ?!?!
i thought it was added for something in the HL map support addition some time ago... overkill?? BTW the model's mins/max are validated in the loader code.

I've reverted to 16 leafs, and implemented MH's code for testing. (seems to work on normal maps).

@GB: do u have your rotating ent in a small 1 room map that i can test this rotation with?

Posted: Thu Jul 15, 2010 7:56 am
by Spike
from memory, halflife has a limit of 64 leafs.

the more complex the map (detail), the more leafs you need for the same sized object.

Posted: Thu Jul 15, 2010 5:55 pm
by goldenboy
rook, no, but I can send you the map. Will PM you.

Posted: Fri Jul 16, 2010 2:28 am
by r00k
Cool, thanks. I would want Qrack to definitely support your mod out of the box when its available.

Posted: Fri Jul 16, 2010 2:56 am
by Baker
r00k wrote:Cool, thanks. I would want Qrack to definitely support your mod out of the box when its available.
To get phat map capacity, take FitzQuake 0.80 and FitzQuake 0.85 and WinMerge (or whatever you prefer).

Metlslime documented it very well.

Posted: Fri Jul 16, 2010 3:32 am
by goldenboy
r00k: Like Baker said, start with phat map capacity, skyboxes, fog, alpha, support -sndspeed 44100, raise static entities limit to like 1024, raise max_channels, modify Read/WriteCoord for higher map size limit and include this rotation stuff with the smooth angles fix and the flicker fix.

RMQ's engine source is available at my blog. We declared our collection of hacks protocol 999.

We have this evil plan to add csqc support, so be warned. ;-)