Forum

Compatibility Benchmark Mods

Post tutorials on how to do certain tasks within game or engine code here.

Moderator: InsideQC Admins

Re: Compatibility Benchmark Mods

Postby Spike » Mon May 04, 2015 8:59 am

what's wrong with just calling D_DrawZSpans after drawing your skybox, like the software renderer does for regular sky/walls/etc?

by the way, the amd64 instruction set should have enough registers to draw both colour+depth in one pass, if you enjoy asm nightmares...
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Compatibility Benchmark Mods

Postby mankrip » Mon May 04, 2015 3:01 pm

Spike wrote:what's wrong with just calling D_DrawZSpans after drawing your skybox, like the software renderer does for regular sky/walls/etc?

D_DrawZSpans is always called, but only for the same surface that's being drawn on the screen. Different spans cannot exist in the same screen space, even if they're used for different purposes, because of how the clipping algorithms works. The color spans from the skybox and the depth spans from the regular skies cannot be rendered in the same rendering pass. So, what D_DrawZSpans draws when a skybox is enabled are the depth values of the skybox surfaces, which are infinitely away.

An easy solution would be to do almost the same thing that my translucent surface approach does, reinitializing almost the whole BSP renderer. But that's not optimal.

A proper solution would make the resulting code cleaner and easier to work with, while also being faster, so I'm not taking the easy route. Figuring out a proper solution for this may also end up helping implement, fix and speed up several other features like mirrors, "fence textures" and translucent surfaces/liquids.

… Alright, I admit that a proper solution would also make Portals® possible (minus the physics). But I don't like to announce such ambitious features before actually implementing them.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Compatibility Benchmark Mods

Postby Spike » Mon May 04, 2015 5:10 pm

I'm not sure that I understand.
which clipping algorithm do you refer to? the software renderer clipping polys to the screen/each other to avoid overdraw, or the opengl-esque workaround for the lack of fragment programs/cubemaps? if the former then you've completely lost me, if the latter then WHY?!?!?

as I see it, its just a single cubemap lookup. these things are fully opaque, there's no need to use additional passes (assuming that colour and depth writing are conceptually different aspects of the same pass).

presumably if you splice D_DrawSkyScans8 a little, you should be able to determine the s+t+face values for the start+end pixels for each span, and subdivide until they're the same skybox face, and then just sample from that face as you would any other texture (subdiv 16 or whatever for perspective correction). there's no scrolling textures/dual layer textures to contend with either. really all you need is the screenspace coords and the worldspace-eye coords, and the cubemap/2d texture array that you're sampling from.
zero overdraw (well, unless you have shamblers, anyway).

Ages ago, before I even started FTE, I had a software renderer that would simply not draw colour for skies (still drew depth). This meant that I could draw a skyroom, then the regular room, and you'd have a portal type thing you could see the skyroom through.
fun times.
q3 has 'RT_PORTALSURFACE' entities. if you had the same you could pvs+frustum check them in advance so that you'd know whether you need to generate that skyroom first or not.
If you want to get all fancy, you can clip (viewport or whatever) that skyroom to the portal's bounding box to avoid excessive overdraw. you can then figure out the viewmatrix required to transform the far side according to the viewing angle+relative position to the portal surface. you do tend to need to generate an extra frustum plane for the far-side scene in order to avoid weird geometry entering the near side.
and if you want to get even more fancy, you can draw that view to some texture, figure out the texture coords for the view and then reuse them any other times you see that portal through another portal.
the physics is a different matter, as you need some kind of csg subtraction for collisions, such that your view is allowed to actually cross the portal plane gracefully (FTE has solid_portal for this sort of thing, which provides both the csg thing and automatic teleports for engine physics when the central point of a trace crosses the plane).
*cough*
urr, yeah, skybox = simple cubemap. yup. that's all I have to say.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Compatibility Benchmark Mods

Postby mankrip » Wed May 06, 2015 12:56 am

The software renderer has two kinds of clipping: polygon clipping, and spans clipping.

Any overlapped spans are clipped by the renderer. No exceptions. I already figured out how to deal with the polygon clipping, but understanding the spans clipping is harder.
The planes, vertices, surfaces, edges, etc are completely ignored by the spans clipping algorithm. The code gets the chained list of spans and process it raw. Spansets have no data telling which surface they belong to, so I have to learn the whole process that generates them in order to figure out how and where to change their behavior.

Reverse engineering the regular sky spans from D_DrawSkyScans8 in order to project the skybox would work, but is not a clean solution. And it would be slower, because it would effectively split the polygons of the skybox into the polygons of the regular skies.

Q3A-style portals and render-to-texture effects are a possibility, indeed.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Compatibility Benchmark Mods

Postby mankrip » Sun May 10, 2015 11:58 pm

Expanding my previous reply a bit:

Quake's software BSP renderer uses two kinds of polygon clipping, plus the spans clipping.

First, polygons are clipped against the frustum.

Second, intersected polygons are clipped using an algorithm that strongly resembles Newell's algorithm. This step mainly ensures that BSP entities' polygons don't intersect with the BSP world's polygons, and is the reason why software-rendered Quake engines have no BSP overdraw problems. (However, BSP entities' polygons are only clipped against the world, not against other BSP entities, which is why BSP entities can have Z-fighting against each other.)

Since the second clipping step ensures that no polygons are intersecting each other, there's no need for per-pixel Z-buffer check. This is why Carmack introduced the per-spans clipping. All the engine needs to do is to check the beginning and the end of each surface's spans against the beginning and the end of the nearer polygons' spans, and clip them accordingly.

The combination of both methods not only eliminates the need for Z-buffer reads, but it also almost eliminates the need for Z-buffer writes.
My guess is that at the time, the spans generated from MDL models' triangles were usually too small for those clipping algorithms to be more effective than Z-buffer checks in them (however, the lack of alpha masking support in MDL models suggests that Carmack may have considered using the clipping algorithms in them instead). And SPR models can't use those clipping algorithms because of their alpha-masked texels (i.e. sprite's spans can include more pixels than the ones that will be effectively drawn).
If someone were crazy enough to make a game using only BSP models (no MDL, no SPR, no particles, no alpha masked/blended surfaces), D_DrawZSpans could be eliminated completely. It would be really fast, and maybe really ugly.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Compatibility Benchmark Mods

Postby frag.machine » Mon May 11, 2015 1:16 am

mankrip wrote:If someone were crazy enough to make a game using only BSP models (no MDL, no SPR, no particles, no alpha masked/blended surfaces), D_DrawZSpans could be eliminated completely. It would be really fast, and maybe really ugly.


You mean like a more primitive form of Minecraft ?

Sure, that would be unbearable for today's standards. But back then, the novelty of a pure 3D world with 6 DOF surely would forgive anything.
Specially if we are talking about a multiplayer game.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
User avatar
frag.machine
 
Posts: 2069
Joined: Sat Nov 25, 2006 1:49 pm

Re: Compatibility Benchmark Mods

Postby mankrip » Mon May 11, 2015 2:45 am

Maybe something with more elaborated assets, like a racing game in an empty urban city (with no people, no trees, and so on) or a shmup with simple ships. Anything that can be made with just a low amount of big polygons.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Compatibility Benchmark Mods

Postby qbism » Tue May 12, 2015 5:19 pm

mankrip wrote:Maybe something with more elaborated assets, like a racing game in an empty urban city (with no people, no trees, and so on) or a shmup with simple ships. Anything that can be made with just a low amount of big polygons.
Preach's mapgen with my 'playable mapgen' modification. Explore peaceful random mazes :D
User avatar
qbism
 
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am

Re: Compatibility Benchmark Mods

Postby mankrip » Fri Jun 19, 2015 6:46 am

mankrip wrote:My guess is that at the time, the spans generated from MDL models' triangles were usually too small for those clipping algorithms to be more effective than Z-buffer checks in them (however, the lack of alpha masking support in MDL models suggests that Carmack may have considered using the clipping algorithms in them instead).

Holy crap, I was right:
Michael Abrash wrote:when we tried adding polygon models to Quake’s global edge table, edge processing slowed down unacceptably. This isn’t that surprising, because the edge table was designed to handle 200-300 large polygons, not the 2000-3000 tiny triangles that a dozen triangle models in a scene can add. [...] the basic problem is that the edge table requires a considerable amount of overhead per edge per scan line, and triangle models have too few pixels per edge to justify that overhead.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Compatibility Benchmark Mods

Postby ericw » Thu Sep 17, 2015 7:44 pm

Here's a good one.. Got an email saying that progs/bolt.mdl wasn't rendering in the Scourge Done Slick mod in the latest Quakespasm release.

I downloaded http://quake.speeddemosarchive.com/quak ... dSmega.zip and launched with "-hipnotic -game sdsmega"
Press '9', '1', '4' to play the "research facility" demo. About 30 seconds into the demo there are some shamblers attacking the player, you should see the lightning bolt model.

What seems to be happening is, "progs/bolt.mdl" isn't included in the list of model precaches in the svc_serverinfo that the client receives when playing back the demo. Quakespasm's new mdl renderer uploads all of the mdl precaches sent in svc_serverinfo into a VBO, and fails when asked to draw an mdl that wasn't precached. (this architecture and a good portion of the code I borrowed from RMQEngine, but I imagine other engines that load mdl's into a VBO might have the same behaviour.)

So it seems that for strict compatibility with the original engines, a client should be able to render an mdl that wasn't mentioned in svc_serverinfo. Still thinking about what I should do to fix this.
ericw
 
Posts: 91
Joined: Sat Jan 18, 2014 2:11 am

Re: Compatibility Benchmark Mods

Postby mankrip » Mon Sep 21, 2015 5:56 am

That means Quakespasm should also be incompatible with the console command "viewmodel", which can load non-precached models into a "viewthing" entity.

I actually used that functionality to implement a player model selection feature in my JoyMenu mod. All the player had to do is to set the number of available models in a cvar, and then the menu is able to cache the selected model into the viewthing entity through the viewmodel command, store its .modelindex somewhere else, remove the viewthing and use the stored index to make the player and the bots use that model.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Compatibility Benchmark Mods

Postby qbism » Mon Sep 21, 2015 5:16 pm

What if the client automatically precaches EVERY mdl it finds in path? What's the worst-case RAM? Many large maps use almost every monster and item, anyway.
User avatar
qbism
 
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am

Re: Compatibility Benchmark Mods

Postby ericw » Mon Sep 21, 2015 10:23 pm

Mankrip, good catch, I hadn't thought of the 'viewmodel' command, and you're right it was broken.

I applied a fix which is to just to create a VBO per mdl model, which is set up in Mod_LoadModel. Specifically, the VBO is uploaded within GL_MakeAliasModelDisplayLists. I guess this is less optimal in terms of OpenGL use than having all of the models in one buffer, but it should still be a lot faster than immediate mode.

qbism - the only flaw I can see with that is it wouldn't handle the case of adding a new mdl while the engine is running, and then loading it with 'viewmodel'.

Another thing I wanted to support is using the "flush" command to reload mdl's from disk, so you can replace an mdl and see the change immediately in game. By doing the VBO upload inside GL_MakeAliasModelDisplayLists, this automatically just works.
ericw
 
Posts: 91
Joined: Sat Jan 18, 2014 2:11 am

Re: Compatibility Benchmark Mods

Postby mh » Wed Nov 04, 2015 7:34 pm

"progs/bolt.mdl", "progs/bolt2.mdl", "progs/bolt3.mdl" and "progs/beam.mdl" are loaded on-demand in CL_ParseTEnt. With hindsight the "single big VBO for all MDLs" approach is a bad architectural choice for the Quake engine.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
User avatar
mh
 
Posts: 2287
Joined: Sat Jan 12, 2008 1:38 am

Re: Compatibility Benchmark Mods

Postby Baker » Sun Feb 07, 2016 7:38 pm

Anyone know if there are any mods that have color pink 255 in .mdl model?

I'm sure there are, possibly even in normal Quake, but I can't think of one right now.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

PreviousNext

Return to Programming Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest