Everything is super low poly, no smoothing on polygons yet. Just base mesh to start with. So - what makes me think now is - how to approach UV mapping on this?
Those are dozens of elements (separate objects) - how to texture them consistently in terms of scale of textures? In radiant I just copy texture and its attributes and paste on another brush. In modelling apps I have to do unwrapping. It's not a big deal when there is 1 object - but Rocket Launcher area itself is made of couple of objects that combined together create whole area.
Love these images, had to look up the map only to find I actually did know it.
Just my observations from other games, not necessarily correct:
The trick, e.g. with Unreal engine games, seems to be that brushes are basically only used as caulk hulls (blocking vis), everything else are pretty much model based inserts. So your ceiling grate would be one and the JPs etc. And the rest, and here it really seems to get tricky, is a clever form of LEGO, flexible enough to create different rooms with the least set of models. These building blocks then can be textured the way you would any object. (Not that I ever did that mind you.) ...
So I fear "randomly" hacking apart (e.g. by room) an existing Q3A map, will be pretty much the worst case trying to cut it up into reusable LEGO-like model blocks. I.e. every wall will be slightly different in dimension, stairs in all shapes and sizes etc. Trouble is most Q3A maps are inherently non-modular. Why? Because it is so outrageously easy to do.
I think you really need to run the process the other way around, creating the LEGO blocks first, putting them together in some form of map, to then build a caulk hull around all that.
Hope I got the concept right here.
Thought: It only now occurred to me you are trying do so something like idTech5 Megatextures, i.e. covering "large" areas turned into models with a separate texture.
Quake levels are irregular, because Quake levels are completely focused on gameplay. Every dimension counts - how long particular ramp is, or how wide the doors are or how much space particular area offers. This is imo really nice element of Quake level design in general - this is: gameplay comes before visuals.
We encounter problem - as you said - Quake has irregular levels, so "lego method" is not best approach. Imo in Quake - where gameplay is so important and everything is done to emphasise that - smart UV mapping is really needed.
I always wanted to use the LEGO-method, but then found out I needed to connect areas in a non-large-grid way and out the window went that concept. Also, a modular approach using the Q3 engine is of no real advantage, e.g. you cannot use it to insanely up the detail. Whereas on the modern Unreal engine you could. Usually the modular mapping also looks very monotonous.
Sorry for going off tangent, I am sure Obsidian can help you very much more specifically.
Still love the untextured screenshots in your first post, they very nicely show how ingeniously simple the brushwork was to create that map. A thing of beauty.
Fact is - Quake is nightmare in terms of Level Design - always much work is needed - as inability to fully use Lego method proves
I would like to UV map it and just texture it simple - each color with texture - brown>brick, white>marble, green>green? and floors with some wood maybe.
just to see result - how Q3 would look with 21st century graphics.
After that I could load it into some modern game engine ofc.
It takes a different set of skills, and I have learned that the hard way. I did a map for Far Cry, a terrain engine... and building something out of modular parts was a complete nightmare for me... I really hated having to click through the tons of folders and sub-folders trying to find the parts to build something.
Concerting ludicrous amounts of detail, you are right, not happening with Q3A. But on the other hand someone does have to create those detailed models first.
Hope you can get the "conversion" done, that certainly will be interesting.
As I see it you need a converter which could do the conversion with the texture data, there might be one to do that. I don't know any converter so that's all I can say.
By the way, I like how it looks with that lighting.
I never properly played Q3A ... (as I recall when that map was all the rage in competitive gaming, I had long since stopped playing online)... I am just a mapper :-P... once per decade... or so.
Actually...there are a number of maps that are pretty much model based.
Kat sort of pioneered the approach, way too long ago to remember. I've used the technique a couple of times too.
UVWmapping objects is the time consuming part. These days (if I actually do map), my maps are a hybrid and brush work and meshes. For axial brushwork, I really can't see any point in using models, as GTK is faster. A good time save if you really want to do it, is the build and texture in GTK, convert to ase, then export into Blender with UVWmaps already there. Then its just a matter of adding materials and applying textures. Getting the ase back into GTK is a pain as submaterials are not handled properly. Kat's site has articles on how to do this.
My workflow these days is to export a my simple level hull into Blender for purposes of scale, then create the meshes I want (terrain features, trees, whatever), then export them to use in GTK.
The great advantage of models is they are so easy to manipulate, rotate etc. They really help to dress the level and break up the axial monotony of a brush based engine.
I really like the style, though you would need to clean up all the patches if you want it to look really clean. That's the biggest concern, but as for how you would actually go about doing it, I haven't the slightest. I tried retexturing my own tiny Q3 map a while ago, and it took hours for me and a somewhat experienced modeler friend just to figure out one texture. Texture mapping outside of Radiant is so hard x_x
