Pages: [1]
  Print  
Author Topic: Lightmap size limitations  (Read 4156 times)
bbmario
Nub


Cakes 0
Posts: 21


« on: March 09, 2014, 05:46:53 pm »

Does anyone know where exactly are the lightmap size limitations placed? Is it just a define or something more complex?
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14478



WWW
« Reply #1 on: March 09, 2014, 08:45:55 pm »

The map compiler itself i'd imagine.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #2 on: March 10, 2014, 01:14:57 pm »

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

This space is for rent.
bbmario
Nub


Cakes 0
Posts: 21


« Reply #3 on: March 10, 2014, 09:10:15 pm »

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.
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14478



WWW
« Reply #4 on: March 12, 2014, 01:49:50 pm »

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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #5 on: March 17, 2014, 02:21:30 am »

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.
« Last Edit: March 17, 2014, 02:25:49 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Suicizer
Member
Member
*

Cakes 2
Posts: 400


WWW
« Reply #6 on: March 17, 2014, 06:04:30 am »

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.
Logged

I'm good at everything but can't do anything...
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #7 on: March 17, 2014, 06:42:57 am »

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 (ports of the game under several Operating Systems or 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...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3656


Trickster God.


« Reply #8 on: March 17, 2014, 07:00:45 am »

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.
Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Pages: [1]
  Print  
 
Jump to: