View previous topic :: View next topic |
Author |
Message |
Team Xlink
Joined: 25 Jun 2009 Posts: 320
|
Posted: Sun Sep 27, 2009 4:34 am Post subject: |
|
|
Yeah, your right Downsider.
The Server/s I will be hosting our going to have professional Quality Connection, but most of them will be running our official stuff.
The Fans who want to run modified servers are who I am worried about, some people still try to host on Dial-Up.  _________________
Anonymous wrote: | if it works, it works. if it doesn't, HAHAHA! |
|
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Sun Sep 27, 2009 5:34 am Post subject: |
|
|
the 64 can be set as a cvar i used it cause on dm3 certain areas had flashing players, increased to 64 fixed it. A timer would atleast create a base time to draw so all servers update at the same rate. |
|
Back to top |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Sun Sep 27, 2009 7:19 am Post subject: |
|
|
r00k wrote: | the 64 can be set as a cvar i used it cause on dm3 certain areas had flashing players, increased to 64 fixed it. A timer would atleast create a base time to draw so all servers update at the same rate. |
The timer isn't to make things consistent, it makes players flicker less than they would otherwise.
Each time a trace succeeds, it renews the timer, it still does the trace even if the timer is in the future, constantly renewing it. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Sun Sep 27, 2009 7:03 pm Post subject: |
|
|
LordHavoc wrote: | r00k wrote: | the 64 can be set as a cvar i used it cause on dm3 certain areas had flashing players, increased to 64 fixed it. A timer would atleast create a base time to draw so all servers update at the same rate. |
The timer isn't to make things consistent, it makes players flicker less than they would otherwise.
Each time a trace succeeds, it renews the timer, it still does the trace even if the timer is in the future, constantly renewing it. |
OK, if I'm getting this straight the logic seems to be:
Trace is always done irrespective of timer value, but a lower number (I'm thinking 8 or even as low as 4) of traces can be done.
If the trace hits the entity, the timer is incremented by 0.2; the result of the trace has no other purpose.
If the timer is in the future the entity is sent.
So in other words what we're really doing here is splitting a large number of tests across a number of frames, and reusing recent results (up to a certain limit).
Yup, that seems to make sense to me.
_________________________________________
Edit: yeah, it works.
I got the number of traces down to 4 (my own tests indicated that the vast majority of entities will get a successful hit in the first 1 or 2 traces, so 4 seems reasonable). No visible flicker, the only artefact is that an entity which should be culled will remain visible for a very brief time period after it goes behind a wall, which I don't consider a big deal as you will have already seen it before it went behind the wall and will therefore know where it is anyway.
Here's the new code for the relevant part of the function:
Code: | for (i = 0; i < 4; i++)
{
end[0] = seen->v.origin[0] + offsetrandom (seen->v.mins[0], seen->v.maxs[0]);
end[1] = seen->v.origin[1] + offsetrandom (seen->v.mins[1], seen->v.maxs[1]);
end[2] = seen->v.origin[2] + offsetrandom (seen->v.mins[2], seen->v.maxs[2]);
tr = SV_ClipMoveToEntity (sv.edicts, start, vec3_origin, vec3_origin, end);
if (tr.fraction == 1)
{
seen->tracetimer = sv.time + 0.2f;
break;
}
}
return (seen->tracetimer > sv.time); |
tracetimer is a float member of the edict_t struct, and gets initialized to -1 in the ED_ClearEdict function. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Team Xlink
Joined: 25 Jun 2009 Posts: 320
|
Posted: Mon Sep 28, 2009 2:14 am Post subject: |
|
|
Alright I have noticed some odd things.
If I set sv_cullentities to 0 the FPS is really fast. If If I leave it at 1 or set it to 2 it is a lot slower.
So, is that supposed to happen?
Also one more thing.
Is it possible to edit this so it works on brush's as well?
Like in this Five Minute paint drawing.
 _________________
Anonymous wrote: | if it works, it works. if it doesn't, HAHAHA! |
|
|
Back to top |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Mon Sep 28, 2009 5:23 am Post subject: |
|
|
Team Xlink wrote: | Alright I have noticed some odd things.
If I set sv_cullentities to 0 the FPS is really fast. If If I leave it at 1 or set it to 2 it is a lot slower.
So, is that supposed to happen?
Also one more thing.
Is it possible to edit this so it works on brush's as well?
Like in this Five Minute paint drawing.
 |
You can trace against bsp models (use SV_Move) so that a closed door blocks view, but it's slower (because it has to check for entities along the ray, not just the single world model).
This is a general purpose visibility solution that is a complete alternative to pvs (potentially visible set) tests that Quake does on entities, and is surprisingly not much slower than them (at least for one trace - for multiple traces it can be quite a bit slower).
But bsp models tend to be large and players really notice when they disappear, so I disabled trace tests on them in my code, but you can use trace tests on them, you simply need more traces, I simply did not care because I use it solely as an anti-cheat / network bandwidth reducer, and the bsp models are pretty cheap to render.
Yes fps is lower with trace culling, but how much lower depends how many traces you use (64 is way too many to justify).
However what you are illustrating in that drawing is culling of world geometry, not entities, which would be far too expensive with trace culling, pvs works well for that and that is why Quake uses pvs. |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Mon Sep 28, 2009 7:55 am Post subject: |
|
|
is there a discrepancy for latency? |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Mon Sep 28, 2009 8:45 am Post subject: |
|
|
LordHavoc wrote: | Yes fps is lower with trace culling, but how much lower depends how many traces you use (64 is way too many to justify). |
There is a trade-off though as it reduces the number of entities you render, so what you lose on doing traces you can potentially gain back by rendering less. A lot of entities will actually "early-out" after only 1 or 2 traces, whereas the full 64 traces will only be performed for an entity that is occluded by geometry. In a scene with lots of entities occluded it's gonna hurt, otherwise it's probably 50/50.
For occlusion by brush models one potential approach might be to (1) only perform it on entities that pass the above test, and (2) use pre-transformed bounding boxes rather than traces for the occlusion test. It's not perfect (it won't deal with a case where a brush model has a great big hole in the middle, for example). Overall I'm of the same opinion as LH - it ain't that big a deal. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Mon Sep 28, 2009 3:51 pm Post subject: |
|
|
LordHavoc wrote: | r00k wrote: | the 64 can be set as a cvar i used it cause on dm3 certain areas had flashing players, increased to 64 fixed it. A timer would atleast create a base time to draw so all servers update at the same rate. |
The timer isn't to make things consistent, it makes players flicker less than they would otherwise.
Each time a trace succeeds, it renews the timer, it still does the trace even if the timer is in the future, constantly renewing it. |
Ya I see what you mean. SV_ClipMoveToEntity is the bottleneck and adding a trace timer throttles the call. The flicker is inevitable, the timer just skips the culling. I still get >50 hits on start map, zombies if facing the pillar to lava. |
|
Back to top |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Mon Sep 28, 2009 5:43 pm Post subject: |
|
|
mh wrote: | For occlusion by brush models one potential approach might be to (1) only perform it on entities that pass the above test, and (2) use pre-transformed bounding boxes rather than traces for the occlusion test. It's not perfect (it won't deal with a case where a brush model has a great big hole in the middle, for example). Overall I'm of the same opinion as LH - it ain't that big a deal. |
It's a routine that culls more the worse your testing is - a pretty backwards scaling behavior
More importantly, DarkPlaces does one trace to the nearest point on the bbox (just take the eye position and clamp it to the absmins/absmaxs of the entity), this deals with a lot of "looking around a corner" cases where the leading edge of a bbox is visible but the rest isn't, reducing flicker - of course it doesn't always help.
Then it does another trace to a random point on the bbox, from a FUTURE eye point (trace ahead the velocity of the player for 0.2 seconds), if that sees something it also renews the timer.
So two traces are done per frame, one using the most direct approach, and one using a statistical approach that also considers momentum (this usually gets rid of the "items popping up" bug as you come up a ramp or go around a corner).
It only does two.
P.S. if you want a test map to see how much bandwidth savings you can get, try dpdm2 on the DP site (or get it out of dpmod), it's a fully quake compatible map and has that rarest of properties - an outdoor environment - this map usually has most stuff visible according to pvs, but only 9% of entities in real gameplay are visible (according to trace culling)... so depending on your network protocol (QuakeWorld for example has delta compression, normal Quake does not) this can be a major bandwidth savings. |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Mon Sep 28, 2009 8:32 pm Post subject: |
|
|
After testing more this is working better. I've added a visual cue in developer mode to show where the traceline goes and red is the fastest, yellow is more labor intense. I get more than 50% of the lines are red.
Code: |
qboolean SV_InvisibleToClient(edict_t *viewer, edict_t *seen)
{
//coding by LordHavoc, Spike, MH, and someone else...
trace_t tr;
vec3_t start;
vec3_t end;
extern void QMB_CullTraceHightlight (vec3_t start, vec3_t end, int color);
if (seen->v.movetype == MOVETYPE_PUSH )//dont cull doors and plats :(
{
return false;
}
if (seen->tracetimer > sv.time)
return false;
if (sv_cullentities.value == 1) //1 only check player models, 2 = check all ents
if (strcmp(pr_strings + seen->v.classname, "player"))
return false;
memset (&tr, 0, sizeof(tr));
tr.fraction = 1;
start[0] = viewer->v.origin[0];
start[1] = viewer->v.origin[1];
start[2] = viewer->v.origin[2]+viewer->v.view_ofs[2];
//aim straight at the center of "seen" from our eyes
end[0] = seen->v.origin[0];
end[1] = seen->v.origin[1];
end[2] = seen->v.origin[2];
if (SV_RecursiveHullCheck(cl.worldmodel->hulls, 0, 0, 1, start, end, &tr))
{
seen->tracetimer = sv.time + 0.2;
if (developer.value == 1)
QMB_CullTraceHightlight (start, end, 4);//Draw a RED line to the ent
return false;
}
if ((!strcmp(pr_strings + seen->v.classname, "player")) || (sv_cullentities.value > 1))
{
end[0] = seen->v.origin[0] + offsetrandom(seen->v.mins[0], seen->v.maxs[0]);
end[1] = seen->v.origin[1] + offsetrandom(seen->v.mins[1], seen->v.maxs[1]);
end[2] = seen->v.origin[2] + offsetrandom(seen->v.mins[2], seen->v.maxs[2]);
tr = SV_ClipMoveToEntity (sv.edicts, start, vec3_origin, vec3_origin, end);
if (tr.fraction == 1)// line hit the ent
{
seen->tracetimer = sv.time + 0.2;
if (developer.value == 1)
QMB_CullTraceHightlight (start, end, 12);//Draw a yellow line to the ent.
return false;
}
}
return true;
}
|
|
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|