WorldSpawn Texture Atlas

[MadGypsy]

Your words were definitely not glossed over, nor are they gibberish but, they take some processing. Trying to shove your knowledge into my brain comes with effort. However, I do think I have just about parsed your script. Give me a cigarette to think about it, I'll realize what the one thing that is not obvious is actually pointing to.

[Baker]

Detail oriented boredom ...

npot has been standard fare since gl2.
quite frankly, engines that still don't use it are laughably obsolete.

Mark V uses npot and has for almost 2 years. Even on model textures (Quakespasm doesn't AFAIK because FitzQuake 0.85's gl_mesh.c was written to output padded coordinates and would be a bit of work to reverse out.).

Edit = yeah, Quakespasm doesn't npot model textures Current code for gl_mesh.c

It's also part of the reason Quakespasm/FitzQuake 0.85 can't do external textures for .mdl models.

void GL_MakeAliasModelDisplayLists (qmodel_t *m, aliashdr_t *hdr)
{
	int		i, j;
	int			*cmds;
	trivertx_t	*verts;
	float	hscale, vscale; //johnfitz -- padded skins
	int		count; //johnfitz -- precompute texcoords for padded skins
	int		*loadcmds; //johnfitz

	//johnfitz -- padded skins
	hscale = (float)hdr->skinwidth/(float)TexMgr_PadConditional(hdr->skinwidth); <---- here
	vscale = (float)hdr->skinheight/(float)TexMgr_PadConditional(hdr->skinheight);
	//johnfitz

even gles2 guarentees support for some npot, on the condition that you use clamp-to-edge and no mipmaps.

^^ That. And it's annoying.

[Adam]

Apologies for asking a slightly off-topic question but seeing as all you guys are here and are talking about texture sizes...

If I am making a texture set to use in a project, utilising a modern Quake engine, what is the most efficient size to use?

Taking into account that the artwork will be low resolution pixel art, so large sizes wouldn't be required.

Would it always be the smallest like 8x8, 16x16, 32x32 etc..
Or is it more the case that modern engines prefer larger sizes like 256x256 and upwards?

As a sidenote to this question, I always convert the Quake palette that I am using into a 32x32 texture set. It would be handy to know if that is the best size to use for this task, as resolution-wise they could be 1x1 for just a colour (I think 8x8 is a minimum tho', right?).

Also, this thread is interesting.
Is atlasing textures a process of collecting a set of smaller textures, like 32x32 and placing them into a much larger sheet (like a sprite sheet as mentioned by Spike) and is this more efficient in some way (or not as seems to be the case)?
If this process is beneficial, is there a nesting* algorithm that slots mismatched texture sizes into one sheet in the most efficient manner?

*(in case you use another term) Nesting being making the most efficient use a of a standard-sized sheet of supplied material, by moving the pieces required around, till you fit the most in.

[Baker]

If it is Quake and you want it to work with anything from DOSQuake/WinQuake to GLQuake to DarkPlaces ...

The specs are here:

Making Textures For Quake

Written by metlslime

But the short version:

"All texture dimensions must be multiples of 16."

Except liquid (must be 64x64) and sky 256 x 128.

[MadGypsy]

I found something that will bring me a step closer to better performance. It is specifically designed for flash.
Introduction to ATF Textures | Away3D Tutorials Wiki

I'm sure that tech, plus what spike said, plus atlasing lightmaps is going to make some big differences. Just as a note, the performance of my engine isn't terrible. I just want to get rid of the "first visit stutters".

[MadGypsy]

Yesterday was a backwards day. I spent much of the day making something that is not what I should have been making, due to confusion (I suffer from this...lol). Today is a wiser day.

I need spikes solution. I also need to merge meshes, there is no way around this. I have told my map not to draw any lightmaps... be fullbright, and there is still a subtle stutter when first visiting semi-dense geometry. My next step is to turn my parser into a re-compiler cause the next steps shouldn't have to happen every time the game starts.

1) build a fat pvs
2) merge all faces of the same texture (breaking them from the current mesh)
3) gather all new geometry,uv's,etc from all combined face meshes and rebuild into a new mesh
4) save that mesh data

some a)'s and b)'s in there would be to take the original images and convert them to ATF, ignoring bsp miptex_t altogether and maybe even dump lightmaps entirely. I need to run some tests but I'm pretty confident I could "bake" rtls across entire meshes as soon as the leaf is created or even just use rtls.

@ bake - maybe even save that lightmap as one big texture or maybe even smaller textures within an atlas...in ATF format.

Oh, I noticed something a little while back. The only maps that overflow the lightmap length, in my engine, are those that have colored lights.

[MadGypsy]

I wanted to convert the entire qrp to atf. That's almost 700 textures. Which means I would have to write almost 700 lines of this (png2atf -c d -r -q 0 -f 0 -i ptextures/wood1_7.png -o gameTex/wood1_7.atf) or I could be real smart and write a dynamic version of that line 1 time. Accompanied by a multi file selector that not only assigns the dynamics but does it in a loop for every file. Whereas that may sound complicated to some, you can see in my code there are only like 5 lines that are doing anything. That's my current document class, ie..that's all the code. I mean obviously the packages I imported are doing a bunch but, I didn't have to write that code.


However, running that command line is taking a loooong time. It's been about 10 minutes and it's finally on the c's.

[MadGypsy]

real replacement textures

ie...not this


oh whoops I had my other display on, sorry so big...on the pic.

side thought: QRP.pk3 is over 400mb, the exact same images converted to atf format (which is already compressed) is about 70mb. Also the images in atf are supposedly designed for specific gpus. Currently I am using mac and win.

edit: The first-visit-geometry-stutters are completely gone since I switched to this texture format and I haven't even started merging faces yet.