Q3A textures

I'm working on my own Q3A BSP rendered, and I have two minor problems reguarding textures.
I extracted all of the contents of pak0.pk3 and mapmedia.pk3 to the base directory of my binary and it still can't find some textures, especially patch textures, is there any other place Q3A stores textures there?
My other question, how are skyboxes implemented in Q3A? My renderer displays faces, meshes and patches right now, and I still can't see the sky, is the sky a billboard (though I doubt it) ?
thx

The textures are in the textures folder of the pk3s. They do not neccessarily need to be in the same pk3 as the map / bsp file.

"texture" names in a bsp file also are not real texture file names. They are shader names. The shader specifies which texture-files to apply. In most cases however, the shader name is equivalent to the texure name, so most textures will display properly. However, to display all textures, you need to process the shader files in the /scripts directory.

There is also a shader command reference available here

edit: as for the sky: It's a normal polygone box. However, the sky texture is a shader in almost any case (because you need several texture files for the front, left, right, back and top of the box [there is no texture for the bottom of a sky box] as well as several cloud layers). Thats probably why you can't see it. I guess your renderer does not display poly's that don't have a valid texture or maybe it defaults to black so you can't see it ?

thanks for the info, it was really very helpful :)
yep, my renderer doesn't support shaders till now, so this is the reason I can't see some textures or the skybox.
it defaults to a white texture when the texture isn't found.
I guess I need to implement shaders.
thanks again.

It should be rendering something, mine does, it just doesn't render it as a real sky yet (in fact to make it look really realistic I've seen a guy calculate texture coordinates for a sphere and use those to texture the polygons). What you should do is render the normal world first, then turn off the depth buffer and render the extruded skybox with all of its layers.

EDIT:
after translating to the player's position

Turn of the depth buffer ? You realize that would overwrite the entire scene, do you ? ;)

I assume you mean to turn off depth writing (?) - why would you - unless you simulate texturelayers by "polylayers" :confused: :confused:

doh that's what i meant, it is so it doesn't clip world polygons

you can do that with glDepthRange can't you?

well, maybe, I haven't used that command yet.

Simpler however would be glDepthMask(GL_FALSE);

I haven't used it either. The author of the diesel engine (He is God) told me to pass 1,1 to glDepthRange, but I'm trying yours first (less params :) )

seriously though he knows how to do pretty elaborate things, and his renderer kicks ass, it IS quake3, like, there are few obvious differences from the programmer's point of view (obviously there aren't quake3 bots)

Well thats at least what I use for all alpha tested/blended textures. Depth testing is required when you draw stuff like flares to make sure that you don't see them through walls (you always would, because you have to draw them after everything else has been drawn) and depth writing needs to be disabled, otherwise overlapping blend effects look really weired (because the one closest to the camera prevents underlying effects from being drawn, but only if they haven't already been drawn. REALLY ugly;) )

By the way, once you know about this problematic, you will discover quite a lot of games which don't do this stuff properly. Dark Age of Camelot is one of them. One alpha blended effect cancels out all effects and dynamic models behind that one (not the static world however). Also they don't draw alpha tested texures (textures with "holes" in it, chains, crates etc) last. Pretty ugly stuff if you watch out for these "details" ;)

I'm not entirely sure what you mean...as long as you leave depth testing/writing on it shouldn't matter what order you draw things in, correct?

Quote:

---

Originally posted by Silvercord
I'm not entirely sure what you mean...as long as you leave depth testing/writing on it shouldn't matter what order you draw things in, correct?

---

yes but you dont want to alpha blend something with a poly that should be blocking it. Like a fire effect on the opposite side of a wall (opposite the camera), you dont want to blend the flames with the wall, rather, you want the wall to block the flames.

Quote:

---

Originally posted by Silvercord
I'm not entirely sure what you mean...as long as you leave depth testing/writing on it shouldn't matter what order you draw things in, correct?

---

Take a blended object (i.e. a flare) with distance 1 to the camera. Draw it with enabled depth writing and testing. Then draw a wall behind it with a distance of 2 to the camera.

The background will be drawn all around the flares' poly, but not there where it is behind the blended poly because that one already wrote to the depth buffer (it is in front of the wall).
If you cleared the colorbuffer with black before drawing, the result will be a flare on black background where it's poly spans.

Thats why you have to make sure that all blended effects are drawn last - after everything else is already there (so there is something to blend with).

Also depth *writing* should be disabled at that point, because if you didn't sort the flares by distance, a flare with a distance of 1 to the camera might prevent more flares in the background (i.e. z=2, 3, 4...) from being drawn. Depth testing however needs to be enabled, otherwise you might renderer flares that are behind a wall etc.