Lightmap size limitations

[bbmario]

Does anyone know where exactly are the lightmap size limitations placed? Is it just a define or something more complex?

[fromhell]

The map compiler itself i'd imagine.

[grey matter]

You might be interested in the Using hi-resolution external lightmap post on the Smokin' Guns forums.

[bbmario]

Yes, i've seen it, but that's external. I wanted to patch my fork of ioquake to accept higher-resolution lightmaps natively. However, i'm not sure that cranking up #define LIGHTMAP_SIZE would be enough.

[fromhell]

I wanted to patch my fork of ioquake to accept higher-resolution lightmaps natively.

I'd also like something like this as well to avoid the terrible necessity of q3map2 needing to output a bunch of shaders to have external lightmap images.   I do like hi-res lighting, but the way q3map2 does it doesn't allow for normal 128x128 lightmap detail, which I still want to support, since 128x128 is a nice size for the common texture cache

[Gig]

Sounds interesting, but how to obtain that without having to fork q3map2?
(Disclaimer: I talk without any tech knowledge!!!)

I mean:
- Probably updated OA binaries only would not be enough, because if the bsp does not include the detailed shadows infos, what can the game do? Real-time calculating or loading-time calculating lighting would be something different than what id Tech 3 was meant for, and may slow down framerate or loading speed, respectively (of course, if with an option disabled by default, we may allow users to decide to trade speed for shadows detail). I don't know if that would be feasible, and sounds like a lot of work. And considering q3map2 compiling includes many options which give different illumination results, how to be sure the realtime/loding time illumination would be similar to what map author intended?
- Then, we would need to fork q3map2, to include the extra lightmap infos in the .bsp. But if we need an updated engine to use such hi-res lightmap (just guessing: if higher lightmap resolution would have been natively supported by Q3A, q3map2 author would have not created that complicated external lightmap trick - however I don't know if ioquake3 already changed something about that), we should preserve backwards compatibilty to prevent the map from crashing when playing on older OA engine versions. So, should the new q3map2 include both "standard" and "hi-res" lightmaps in the bsp, with newer engines loading the hi-res one (possibly with a cvar to enable/disable) and older engines loading the standard one? And even then, maybe the mapper should test the results in both modes, to be sure the map would look good on all systems...

Maybe such changes should be done working with (or then submitted to) q3map2 developers and ioquake3 developers, so then may be accessible for a larger base of users and a larger base of games?

Please correct me if I'm wrong.

[Suicizer]

Gig - "we should preserve backwards compatibilty to prevent the map from crashing when playing on older OA engine versions"

Wut? Such people should stop whining and download the latest version of OA. Updates aren't being done for nothing.

[Gig]

Wut? Such people should stop whining and download the latest version of OA. Updates aren't being done for nothing.

A few considerations (some PROs and some CONs)...

- OA3 will be the chance for major changes which will require new binaries (protocol version change maybe?). If we have to do "breaking" changes, the first OA3 release (OA 3.0.0?) would probably be the best moment.

- While "game logic (qvm)" and "game stuff (maps, textures, etc.)" can be spreaded relatively easily thanks to automatic download features, the same does not apply to "engine (binaries)", which cannot be autodownloaded. It is possible to play OA 0.8.8 using 0.8.1 binaries (although missing a few features).

- I don't know if the only changes required to support this hi-res lightmap thing would be in the engine (and q3map2 compiler) or something should be done also in game logic (game code)... in the second case, although spreading a new game logic version is easier, keeping backwards compatibilty would be a must, otherwise the "new" maps would not work with any previous mod (further breaking mod compatibilty is NOTTODO).

- Not all OA binaries (and OA packages) are managed by Fromhell. There are many, many forks around (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Ports_and_markets]ports of the game under several Operating Systems or DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Install#Linux]Linux distros repositories). Some are build starting from OA engine sources, and some starting from ioquake3 engine. I don't know which of them will be updated by their authors when OA3 will be released (and if they will create separate "OA3" apps or will replace the old "OA" app)... those not updated may not be able to run the "new" maps. It's true that "they" should follow "us" and not vice-versa, but...

[Neon_Knight]

I agree with both.
People playing the older versions have never done a favor to the game, nor they will ever do.
On the other hand, one of the objectives of OA (if not one of the MAIN dev objectives of OA) is to keep backwards compatibility not only towards older Q3 maps but also towards older OA maps.