Hi all,
Would it be possible to add these functions to ioquake3 ?:
The idea is that by allowing low-res textures, and supporting .mtl’s, the texture resolution can be reduced significantly (to a level,
unsupported by either ioquake3 or netradiant) yet the model
quality can be kept high, and “per zone” model coloring can be used. All in all, this would make the game run much more quickly (and require a less performant pc) yet maintain reasonably good graphics quality overall. This is very important for games that use very large q3 maps (battlefield-type games such as MilitaryForces/MilitaryForces 2).
1 Like
Should loading 2x2 images be fixed if broken? Yeah. However rendering prefers fewer meshes. There is better performance when using a single texture for all of a model’s meshes instead of separate 2x2 textures for each region of the model.
Textureless coloring should be per-vertex not separate meshes. For OBJ models this doesn’t require MTL (unless I’m confusing it with IQE/IQM behavior).
Vertex colors for non-mapobjects can be saved in IQM models and accessed by ioquake3 test builds in shaders using (untested)
models/something
{
{ // Model vertex colors
map $whiteimage
rgbGen vertex
}
{ // Add world environment light and dynamic light colors
map $whiteimage
rgbGen lightingDiffuse
blendFunc filter // Might be wrong blend? It's what lightmaps use though.
}
}
The downside is that there are two rendering passes. Using a single texture for all colors (single rendering pass) will most likely be faster (less geometry to draw). I guess it would probably be possible to combine the white rgbGen vertex and lightingDiffuse stages in the engine though.
Using vertex colors for world mapobjects may be possible with a single rendering pass. However this requires changes to q3map2 to combine misc_model vertex colors with environment light vertex colors. Also need support for light bounce off vertex colored misc_model?
textures/common/vertexlit_example
{
surfaceparm vertexlit
surfaceparm nolightmap
// Need a way to tell q3map2 to combine misc_model colors.
{
map $whiteimage
rgbGen exactVertex
}
}
2 Likes
Yes, I guess that using fewer meshes is preferable, however the texture resolution then needs to be way higher. So if you have say 1 mesh of 128 x 128 then that would be better than say 64 meshes of 2 x 2. However, if you’re replacing a single 128 x 128 mesh with 4 meshes of 2 x 2 I think the smaller meshes would speed up things considerably (you don’t really need that much colors anyway and I also like the cartoony “Battlefield Heroes” type look. I used this technique when making my textures for the media pack for MF2 (untested as I never got MF2 to run).
Besides the game engine speed however, there’s another advantage: it gets a lot easier to color models using this (per zone) coloring (or actually coloring “per mesh group in the model”), so for developers it could be a big improvement. When using vertex coloring, you wouldn’t get this advantage btw.
PS: for why I used 2x2 rather than 1x1. Actually 1x1 was also my preference. However as I figured that the system required powers of 2, I used 2x2. So, I might have been wrong there but as I made all MF2 models in 2x2 I still think that additional support of this would be beneficial (to me, and others which have made 2x2 textures).
1x1 textures is fine for power of two texture OpenGL games. 2 to the 0 power is 1. Though I haven’t tested loading 1x1 TGA in ioquake3.
If Q3 shader has mip maps enabled, images are resized to half size repeatedly until it’s 1x1 and uploaded to GPU as mip levels for better sampling far away. So a 2x2 image would also be uploaded as 1x1.
I tested TGAs of size 1x1, 2x2, 4x4, and 8x8. They work in ioquake3, ET:Legacy, and Xonotic NetRadiant. They probably work in original Quake 3 and all derivatives, such as MilitaryForces. In NetRadiant you need to go to the texture area open View on menubar and enable “Fixed Size” for the textures to be large enough to click on.