help completing an engine

[revelator]

Hey peeps.

Im fixing up some lose ends on my realm engine but need some help on a few features, so if anyone is interrested in helping fixing the code the credit is all theirs

things to do.

Bumpmapping on alias models (works fine on surfs) pointers on how to do it was in mh's Q2 engine but it turned out a mess when i tried to adapt it so if someone could pitch in with a hand on this part id be happy.
Menu system. My plan is removing it completely and replacing it with a csqc based one. Hud models are ok allthough it should be replaced by a later model from mh.
Bloom renderer. mh's version preferable to the one im using currently. My version works but its a bit to colorfull hehe.
Code for loading skyboxes. Completely missing atm, the plan is using something ala tenebraes version with tile textures for scrolling clouds.

other parts that could use a workover.
vertex arrays on some parts of the engine uses a non native adaption from early phoenix quake, while they do work fine id prefer not to have a load of seperate arrays.

The wm in realm is based on bengt jardrups work and as such suffers from the same bugs his engine has.
Most notabley some mods behaving weird or not loading at all. I used it because it handles extreme mods better but it does have some drawbacks.
I fixed some of incompatibilities but some still remain.

write here or PM me if you want to lend me a hand.

Best wishes reckless.

[Spike]

bumpmapping of any kind requires a light direction. good luck getting it to match.

csqc is not a good choice for engine-based menus. mods provide their own csprogs.dat which means no more menus. also, csqc is not running when a map isn't loaded (unless you want to do some halflifeesque a-map-is-always-loaded thing).
of course, your implementation is your implementation.

bloom... can't help you with that. the stuff in fte is shite.

skyboxes. use a cubemap. its easy enough (the awkward part is getting your texture loader to load the images into cubemap sides instead of regular 2d textures). also check to ensure the seamless cubemap extension is active... With a cubemap or two you can just use a texture matrix and rotate it to rotate the clouds. then there's no per-vertex maths and you can push your sky polies through with one glDrawFoo call (ignoring state changes). or use a cubemap with glsl - you probably want to use glsl to stop the annoying sky warps in glquake anyway, which would make skyboxes merely trivially different from regular skies.

vertex arrays are deprecated. Use VBOs, and glsl when you need to animate them (like water).

why does your engine need a window manager?
I'd pimp fte's qclib, but I'm too lazy to support it properly. but on the plus side it does give a nice 'compile' console command.

[revelator]

realms bumpmapping is not standard its a special version made by mh based on an idea by me it does not use light direction but player direction on the plus side its way way way faster than normal dot3 bumpmapping.
ok was not aware of that restriction in csqc for menu use ill see if anything else can be cooked up (xml menues ?).
cubemaps for skyboxes sounds ok ill look into it.
vBO hmm i might but my engine is allready among the faster ones so im not sure how much i would gain.
glsl was dumped early as the modifications nessesary would be to much and the system i use currently emulate shaders quite ok but maybe in time (its definatly something i want to look into).
oups wm should have been vm

the bloom code i use is allmost the same fte uses heh.
Mh's only apply bloom to textures with luminance.
qclib might be of interrest

[revelator]

For the interrested this is the bulk of mh's bumpmapping implementation.

Code: Select all

void R_InitBumpyTMUs (GLenum MHGL_TEXTURE0, GLenum MHGL_TEXTURE1)
{
	// TMU0 writes the normalisation cubemap as the default primary colour
	glActiveTexture (MHGL_TEXTURE0);
	glDisable (GL_TEXTURE_2D);
	glEnable (GL_TEXTURE_CUBE_MAP);
	glBindTexture (GL_TEXTURE_CUBE_MAP, r_normcubemap.gltexnum);

	// now rotate the texture matrix by the same transforms as the modelview matrix to get the correct orientation
	glMatrixMode (GL_TEXTURE);
	glLoadIdentity ();

	// rotate around Y to bring blue/pink to the front
	glRotatef (90.0f, 0.0f, 1.0f, 0.0f);

	// flip axes
	glScalef (1.0f, 1.0f, -1.0f);

	// alter the up/down rotation by 180 to ensure proper alignment of the cubemap
	glRotatef (r_refdef.viewangles[2], 1.0f, 0.0f, 0.0f);
	glRotatef (-r_refdef.viewangles[0], 0.0f, 1.0f, 0.0f);
	glRotatef (-r_refdef.viewangles[1], 0.0f, 0.0f, 1.0f);

	// now scale the texture matrix linearly to ensure that we always have valid texcoords
	glScalef (666.0f, 666.0f, 666.0f);

    // back to the modelview matrix
	glMatrixMode (GL_MODELVIEW);

	// basic replace texenv
	glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);

	// set flags for this TMU
	TMUFlags[MHGL_TEXTURE0 - GL_TEXTURE0] = (TMU_ACTIVE | TMU_CUBEMAP | TMU_TEXMATRIX);

	// we need this so we can support drawing the cubemap only for testing
	if (!MHGL_TEXTURE1) return;

	// TMU1 holds the normal map
	glActiveTexture (MHGL_TEXTURE1);
	glEnable (GL_TEXTURE_2D);

	// combine and scale the texture matrix we use the color matrix here.
	glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
	glTexEnvf (GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_DOT3_RGB);
	glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_PREVIOUS);
	glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_TEXTURE);
	glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR);
	glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR);

	// we scaled down the normal maps when we created them so there's no need to reduce LOD
	glTexEnvf (GL_TEXTURE_FILTER_CONTROL, GL_TEXTURE_LOD_BIAS, gl_picmip.value);

	// set flags for this TMU
	TMUFlags[MHGL_TEXTURE1 - GL_TEXTURE0] = (TMU_ACTIVE | TMU_PICMIP);
}

Its pretty simple by the looks but ofc theres more to it than this one function the main thing is that it does not use ppl in any way form or other.
A newer version which also supported alias models was in mh's Q2 engine using a more complete backend.
I managed to get the alias model code working but it was a mess so im currently trying to adapt the Q2 code from mh completely.
The above function is comparably the same though but with a different angle calculation that does not work for Q1.

[Spike]

yeah, if you use a deluxemap instead of that cubemap, you can get bumpmapping which does respond to light directions. The issue comes between separate lights, as it flattens out. But you can get some decent enough bumps that way, you just have to ensure that the normals are not full unit length to retain the same lighting intensity across the surface. Then you get per-pixel lighting without the expensive multiple passes.

VBO is great for situations where you have a lot of vertex data, or slow pci busses or whatever, but otherwise its mostly a pain. If you're implementing VAs, you should consider going the whole hog and using VBOs instead. They're mostly the same really, but VAs are not part of gl3's core profiles. If you're generating data on the cpu each frame, then vbos probably won't be a gain, which is something to get annoyed at... Otherwise they're the fastest way to get data to the gpu, and the only way in d3d.

GLSL is awesome. nuff said. If it means less texture lookups then you've gained from it. various things become less hacky. entity vertex lighting stops being so inefficient, etc.
mh is a fan of the earlier arb programs, if only because of intel being utterly useless.
glsl isn't all that complex, other than to learn exactly what fixed-function stuff becomes unnessecary.

[mh]

skyboxes. use a cubemap. its easy enough (the awkward part is getting your texture loader to load the images into cubemap sides instead of regular 2d textures). also check to ensure the seamless cubemap extension is active... With a cubemap or two you can just use a texture matrix and rotate it to rotate the clouds. then there's no per-vertex maths and you can push your sky polies through with one glDrawFoo call (ignoring state changes). or use a cubemap with glsl - you probably want to use glsl to stop the annoying sky warps in glquake anyway, which would make skyboxes merely trivially different from regular skies.

This. Just so much this. It also clips correctly against other geometry, has no overdraw issues, you can have multiple layers scrolling against each other, using the texture matrix and some alpha blending to get nice effects. You'd be mad not to.

mh is a fan of the earlier arb programs, if only because of intel being utterly useless.

Ran into trouble on ATI too. There's just too many incompatible versions of GLSL, with weird syntax differences and lots and lots of fun extensions to check for and fallbacks to have to write. The old programs are at least far more tolerably consistent across platforms (if only vertex attrib arrays were too a lot more pain and suffering could be resolved). Overall they also need much less boilerplate in your own code to support them (C++ weenies and paid-by-the-line code grinders would hate them), and they can pull a few neat tricks that never really made it into the GLSL spec.

[Spike]

yeah, I had fun with GLSL+ATI vertex attributes. attribute 0 is stated to be gl_Position. Enabling and disabling it also enables and disables GL_VERTEX_ARRAY or whatever it is on ati, but not on nvidia. If you go fully into glsl then its not a problem, but you do need to enable that bit of fixed-function state if you stop using glsl. You also have to be careful with nvidia and float foo = 0; type statements, because glsl isn't meant to allow you to do implicit type conversions between floats and ints but nvidia allow you anyway. Nvidia have cleaned up their act and behave much more strictly if you explicitly state #version 110 right at the start (if you do so, make sure its above any #defines because certain implementations are strict about that too), and doing so can reduce compatibility issues because everyone does agree on what version 110 is meant to mean, even if they do allow ambiguous things like defines before stating the version (which is actually not meant to be allowed).
The worst glsl implementation is mesa(linux+intel hardware), because they abort() on my shaders, and I can't even reproduce that on my machine. Damn you mesa/intel!
Anyway... cubemaps for skyboxes, even if you don't use glsl.

[revelator]

cubemapping it is then

The deluxemapping idea is interresting ill see what i can dig up about it.
Atm only implementation i seen was in tenebrae2 but i suspect darkplaces to have it also.

Also amen to the way vendors treat the glsl spec is fubar, i hope they settle on some standard soon.
vBO's are still on the backburner for now atleast untill i get something im happy with but after that all bets are off hehe.

[mh]

Go cubemapping!

One of the big problems I had with attrib arrays was that I'd found a driver that Just Did Not Like writing from vertex.attrib[anything] to result.texcoord[anything other than 0]. As it was an older driver the possibility of it ever being fixed was pretty damn low.

Beware of (ab)using the color registers; they can be interpolated at much lower precision on some hardware, so unless you're certain that this lower precision is OK you risk huge loss in fidelity.

It's a shame that GL_ARB_vertex_blend never got wide uptake, and never made it into core. You could do a static VBO plus interpolation setup for MDLs with that and not need shaders at all. The hardware is definitely capable and the D3D version of it (D3DRS_VERTEXBLEND) is widely available.

One of the really really nice things about shooting for more modern graphics hardware (say, SM3+) is that a lot of old crap that you needed to worry about just goes away.

[revelator]

Im definatly shooting for newer hardware while my current gfx card 560gtx handles older rendering code quite ok i noticed more and more problems these later years.
Also newer gfx perform horribly with older rendering code (really horrid).

One of the big problems I had with attrib arrays was that I'd found a driver that Just Did Not Like writing from vertex.attrib[anything] to result.texcoord[anything other than 0]. As it was an older driver the possibility of it ever being fixed was pretty damn low.

Aww :/ was that an intel or ati gfx card ? ati's latest drivers seem to be getting better and better so id suspect the intel card but theres still some stuff ati seems to lack compared to nvidia. Not performance wise though
Need to refresh my knowladge a bit before i go apeshit on these changes its been some time since i last coded anything 3D, my heads still buzzing from modifying gnu functions for the new msys2 compiler
Still not done either so it may take me a while when i have to divide my work between these two.
Tbh im leaning a bit on doing the changes on my TQX engine instead of realm cause the code changes will be pretty hefty and TQX is a bit more basic codewise to start on.
Also it has the added benefit of a shader system (rscript) which could be modified to work with glsl and a scripted particle system with decals.

[mh]

Also newer gfx perform horribly with older rendering code (really horrid).

I've done some benchmarking with GPU Shark - not entirely certain how reliable it is, but it does indicate that old-school rendering (immediate mode, fixed pipeline) will get you maybe 40% GPU usage on a typical ID1 map, whereas the newer stuff (VBOs and shaders) hits 97%. There's obviously a lot of GPU power going to waste with the old-school stuff, as well as bottlenecking on API calls/etc.

Aww :/ was that an intel or ati gfx card ?

Intel. Despite what you might think from what Spike says, I'm not in love with Intel graphics ( ) but I do find them very useful for testing stuff on. The theory is that if it runs well on Intel it will run well on anything, and their driver is so bad that you're really forced to do things in as efficient a manner as possible.

[revelator]

I'm not in love with Intel graphics

What a horrible thought

I use gpu shark as well and furmark for stability testing my gfx cards (after i had the pleasure of buying one to many unstable gfx cards these crappers do cost money!).
i have to commend MSI for my current card though newer goes above 60" and is 30" idle. The card has an aftermarket cooler of there own design and its a blast
its also pretty cheap and next month im buying my second one for SLI which confirmed by testers will beat even an 580 gtx by quite a margin.
The idea of using the worst driver to make code for is pretty sound as one should expect it to run on pretty much anything if it runs on that.

Still got me ol trusty (NOT) 285 gtx black edition. But with the stability problems it has on vista/win7 i doubt i could sell it so ill keep it as a doorstopper for the lols

[mh]

Still got me ol trusty (NOT) 285 gtx black edition. But with the stability problems it has on vista/win7 i doubt i could sell it so ill keep it as a doorstopper for the lols

2.8x driver? Roll back to 2.75.33 and all will be well.

I'm not in love with Intel graphics

The honourable exception is the Intel 945. I've seen a 945 outperform a recent Mobility Radeon for certain rendering tasks, and not by a small margin either - up to 3x or 4x faster. And in D3D too, where you'd expect both to be good. That's an awesome chip.

[revelator]

all drivers unfortunatly though some have been better than others :/ only way i could get it stable was dropping the factory overclock back to standard gtx 285 values and even then it did occasionally crash the whole system but atleast not every two minutes.
the strange thing was that i could murder the card with furmark (on highest) for days and it didnt crash once untill i loaded a game. The cards been living in two machines now and the stability didnt improve with different hardware
so my best guess is that the card had some sort of fault. To bad this experience only cost me about 10 grand in hardware and thats in dollars

doesnt matter the card was pretty hefty for its days but the 560 blows it totally out of the water (allmost 50% faster) and i get dx11 support so im happy.

[revelator]

an intel outperforming an ati preposterous! hehe no i heard something similar but i guess intel has made to much of a bad name for itself with there previous gfx chips so it stuck