broken skybox when one of the face have a different size than the others

[illwieckz]

This a bug I first faced while porting maps from Tremulous for my InterstellarOasis initiative. At this time I workarounded the bug by modifying the skyboxes, but it's just a one-shot workaround and not a fix.

So, what's the issue? Sometime some skyboxes have one face with a different size than the others, usually the bottom one is smaller since it's unseen from the player point of view because of the floor of the map itself. Quake3 mods looked to rely on this trick to save file space (especially when pictures where shipped uncompressed and bandwith was low).

Have a look at the alamo skybox by Joe Kari from Smokin' Guns:

The skybox rendering is broken:

To reproduce the issue it's possible to download some preview dpks of Smokin' Guns assets this way:

wget -O- http://gg.illwieckz.net/dl/smokinguns/dev/SmokinGunsAssets.get | xargs wget

and load the dm-alamo map this way:

/set g_neverEnd 1
/devmap dm-alamo

There is no such issue in idtech3 derivated games like Tremulous or Smokin' Guns so this looks to be a regression (it can even predate Unvanquished if introduced by XreaL/ET:XreaL, I don't know).

[bofh80]

so after a bit of digging around here comes a link again. http://www.dersaidin.net/xreal/docs/ seems dersaidin took the time to archive the wiki contents. Textureguidelines Shadermanual etc. Not sure if you had access to them before. they might help. it might just be that the shader needs corrected for the skybox to work.

[illwieckz]

it might just be that the shader needs corrected for the skybox to work.

If we have to edit the shader or the image (we have verified that editing the image works), it's a regression. Fixing the asset is not an option at this point, the issue is not that the engine is not able to render skyboxes, the issue is that the engine is not able anymore to render skyboxes that worked before.

Thanks for the link, I also knew https://tremap.xtr3m.net/__Games/Xreal/Manual_Shader_1/ShaderManual.htm :-)

[bofh80]

The only extra remark that might help explain some things was that for a lot of testing, especially normal q3a assets you had to use the compatq3 or similar switches. I'm not sure that was true for etxreal though. When i ran into issues like this (with q3a assets) i was basically told xreal wasn't designed to be backwards compatible so to remake the assets/shaders as required. again disparity between etxreal/xreal this might not be true :) (as i still can't remember which engine got ported for this)

And while this isn't exactly helpful, in sorting it out, it might explain other odities you've noticed.

[illwieckz]

Yeah, knowledge is helpful in any way. And yes XreaL did not care so much about upstream compatibility, especially in the end with doom3 stuff. Btw this is the kind of simple feature we must be ok to take care.

as far as I know Dæmon as lineage on etxreal, there is wolf:et bits and some doom3 related stuff (like surface keywords) in it.

[illwieckz]

See #179 for a PR implementing a fix:

ping @gbougard