I guess last one depends on hi-res textures feature in sourceport. 

I for one would find it a welcome feature. Some of my current levels would go from bsp2 to bsp with this. 

i think 3d skyboxes would be an appropriate feature for quake. 

Here's some reference on Valve's implementation: https://developer.valvesoftware.com/wiki/3D_Skybox

video:

https://www.youtube.com/watch?v=hSJdlTlWOIA&ab_channel=3kliksphilip 

i would like 3d skyboxes
if anything, because they can be animated
imagine a unrealistically big moving planet like those unreal tournament skyboxes.

or some void maps with structures floating in the distance.

or a giant cave like that awesome blue mushrooms cave in skyrim

or huge machinery working in the distance

i don't think it's necessary to use hi-res textures at all for this to work 

I'd use this too! I've had fun toying with it in Source, but it's not just "that other engine does it so Quake should too"; I think things like topher's suggestions, giant caves and distant, floaty Unreal islands, are well suited to Quake's hook of hopping through eldritch fantasy dimensions. I certainly don't expect anyone to jump through hoops to add features just because they'd be cool, but this is something that strikes me as theme-appropriate, assuming of course the effort required isn't unreasonable. I've only recently started getting a handle on 3D graphics development, mind you, so I couldn't tell anybody else how easy or hard the job would be.

But as I just proved to myself with a quick test, you can do some of this already with Quakespasm and ericw's compile tools, kinda sorta maybe a little bit.

Build your main map, and set its borders (that would normally be sky textured) to SKIP. That makes them solid, and seals the level, but lets you see through them.

Build your skybox as a separate .map file, constructing everything in miniature like you would for other engines that support this feature.

Back in the main map, place a misc_external_map entity, and set its path to that of your skybox .map file, its classname to something like func_illusionary, and the scale to something crazy, 32, 64, something like that. Then just compile, load in game, and make sure gl_farclip is high enough to show the distant geometry.

As I understand it, although sv_protocol 999 is required to allow actually visiting areas outside the +/-4096 unit bounds of your typical Quake level, certain engines like Quakespasm will still draw at least world geometry outside that limit even with the usual protocol 666. So if all you care about is monolithic background visuals, and have no plans to let players reach those areas, it works just fine. 

The animation possibility is a really good point about the full 3D-skies feature.

ItEndsWithTens, I think I followed along with your post... that's pretty cool. Bottom-line it for the peanut gallery though. :-) So with that approach, the sky geo needs to be static, but other than that what would be the drawbacks? 

For now there is only one skybox allowed, so it can be combined with a sky texture. Then there were two.
Also 3D sprites would be welcome.
captlog 

Sorry, Johnny, I do tend to get carried away with myself. This tweet, and its follow up, might explain it better? I'm not sure.

As far as drawbacks, the only ones I can think of right now are:

1.) I don't know what engines beyond Quakespasm support rendering geometry outside the usual Quake map extents.

2.) Even in QS, if your backdrop is so grand that it requires modifying gl_farclip, you'll need some way to trigger changing that automatically so players don't have to fiddle with it themselves. I think Quoth and AD have entities for that sort of thing, but don't quote me on that. Even if you have a way of working around that, you of course have to worry about the impact of changing players' console variables, since those changes will persist beyond just your map.

3.) You're limited to using ericw's toolset. I don't personally find that to be a limitation, his tools are fantastic, but if you prefer other compilers you're currently out of luck. I have my little func_instance wrapper that I keep going on about, but it doesn't support scale, and that's some ways off if it ever happens.

This technique only occurred to me today, when I read this post, and I slapped together the test map I showed in those tweets in about ten minutes; I can't say it's a carefully considered, deeply thought out approach, so take my ideas with a grain of salt. 

If you release your map as its own mod directory, you could set things like gl_farclip in a custom quake.rc.

But yeah, it does sound like a trick that might not work in other engines.

Neat though. It does demonstrate that the idea is not technically out-of-question for current engines, especially with static geo. 

Nice investigation, ItEndsWithTens. It's cool, that its already working. I guess modifying variable is reasonable price to pay for this. Thank you for detailed description, would test it myself. 

We know the map bounds, we know the player position, it's just a simple distance calculation. Pythagoras had this figured out over 2500 years ago, it shouldn't be difficult for people today. 

Sweet! ItEndsWithTens, that idea rocks! Thanks for the quick demonstration. Sad that it can't have moving bits as easy as Source, but for what I am doing I think I can easily just add them in at the right location using qc, such as chimney smoke, particles, etc.

For the record, it would be great if the skybox method from soyrce were implemented but for now I think IEWT's method is just what I need!




Wait...wouldn't having skipped walls negate vis? Ah who am I kidding, as open as my maps are atm vis isn't really mattering anyway. 

You're welcome for the demo! I'd mentioned 3D skyboxes before, back in the "what do you want for Quake in 2018" thread (and alongside animatable sky cameras, to get e.g. the rolling pirate ship in UT99, though that's maybe a bridge too far), but at the time it didn't occur to me to try eric's misc_external_map thing. This thread came along at the right time and somehow reminded me that that entity supports scaling, so it seemed worth a test.

Do keep in mind, however, that I didn't actually test entities. I know the player's position is limited under protocol 666, but I'm not sure if that applies to point or brush entities as well. I would imagine it does, but you'd need to try it to be sure.

Another drawback I hadn't considered when doing this yesterday: Source or Unreal style 3D skies will by their nature display models as scaled up too, so if you want a gigantic Combine soldier, or Skaarj, to be in your skybox, those games let you do it. Here, the compile tools scale up the brush geometry, but can't do the same for the models, so no mountain-sized Spawns I'm sorry to say.

On the topic of SKIP borders, to be honest I didn't think too hard about that one, because I now realize that since the external map's contents get collapsed into the main map before the actual compilation process, you could technically just build a map with no sky or skip textures at all, leaving it open to the void, and just trust that the external map geo, when brought in, will seal the map.

The drawback to that being that if you want to disable the backdrop on a temporary basis, by hiding or temporarily deleting the misc_external_map, your main map won't seal. But that's for the individual mapper to decide, really. The bottom line being that if you plan to always compile with the external map in place, then you don't need the SKIP-textured borders at all, really.

One last thing: you also need to make sure that the entity your misc_external_map is set to become (see the tool docs for details on that) has its origin inside of your map. If its origin is outside of the collapsed map's interior spaces, you'll get leaks. This one's a little hard to explain properly, but if you start experimenting with this stuff you should get the idea quickly enough.

Good luck with your project, Qmaster! 

Of course I didn't bother to try this before my last post, because I'm dumb, but in about two minutes of testing I've found the backdrop shows up in Darkplaces and Mark V too. 

what are the implications of VIS for this method, though? since it's merged into one giant map and then that merged map is run through the compile tools, it seems like it's not much better than just manually creating gigantic geometry in the main map file. 

Hmm. Good point. I'm not sure about VIS, frankly, someone more knowledgeable would have to chime in there.

As far as usability, if your editor supports building geometry that far outside the normal map bounds, then no, there isn't a difference. Really the only advantage in that case is the ability to easily change the scale of the background all at once, with a single number, instead of having to select everything, scale it all, then decide you want something else and do that all again. 

re: vis implications, you can set the misc_external_map to insert the imported brushes into a func_detail. That would probably be the way to go, and then either have the sealing box part of the main map, or in a separate external map that's imported as func_group.

mh - good point! 

Has someone tried running vis with eric's suggestion? It'd be really good if it worked, but if it doesn't... I guess ItEndsWithTens has discovered a way to encourage more unvised maps in the community :P 

As if eric and Tronyn's jam 6 map wasn't reason enough to love unvised maps? :D

Did a couple of further tests, and there are two approaches I've found that "work":

1.) Leave your main map exposed to the open air, so to speak, and set your misc_external_map to create a func_group. Everything will end up sealed, but you of course have the problem of VISing a gigantic open space and the usual problems associated with enclosing your map in a huge box.

2.) Seal your map up with SKIP, and set the external map to become a func_illusionary. This should, I think, mean the background geometry won't contribute to vis calculations, but I now have finally thought to worry about whether there are circumstances under which that entity might be outside your PVS and blink out of existence.

Both of those attempts work in my small scale, throwaway tests, but in real maps I'm starting to suspect this is a dead end I'm running down. I can't get func_detail to work, it gets clipped away by the tiny SKIP enclosed area I've built. Sorry everybody! I mean I did say I hadn't thought this through extensively, didn't I? :|

Then again, it's a tantalizing glimpse at what the real deal would look like integrated into the engine itself, so all the more encouragement to add 3D skybox rendering. I'm going to tell myself that over and over again until I don't feel like a jackass anymore. 

Skip behaves like a solid texture, so if it's used to seal the small inner box, it will clip away func_detail that's outside that in the void.

I think a variation on #1 should work: having the skybox misc_external_map create a func_detail, leaving the main map exposed to the air, and having a skip-textured box that encloses the full size of the skybox.

In terms of vis, it should be roughly the same as a regular skybox map that's sealed inside a sky textured box.

#2 will require the engine to have workaround for the "flickering entities bug" (the problem where a bmodel that touches more than max_ent_leafs flickers.) Quakespasm and I think MarkV have this (it'll just always render the entity if the entitiy's bounding box touches more than something like 32 leafs.) Aside from that it'll generate lots of efrags (a data structure in the engine for when a static ent touches a leaf). 

Would it be possible to create a kind of "priority" brush entity that's always rendered regardless of vis without modifying the engine? Something that behaves like everything in an unvised map, so to speak. Or does the engine do too good a job at enforcing things if vis is found? :p 

That's a good idea, I forgot that void/sky maps essentially do giant open spaces all the time. By using your suggestion, and the one earlier about having the sealing box in a separate file, I was able to get something that works well enough. Easy to scale the background geometry, vis runs in no time, sunlight works thanks to using a sky texture for the outer box, and indoor spaces (built with skip to see what's happening outside them) show that the big background stuff does properly disappear when you're indoors. Maybe this could work for some projects.

Instead of waffling back and forth on whether or not I should have bothered telling anybody about this brainfart before I'd put it through its paces, I really should get to work on some sort of test map. It'd be nice to both see if this could work out for a real project and release a map before it's been a full year since my last one. :) 

This is very interesting and promising, and I'd love to see a true map-sized proof of concept.