In this forum you can easily get banned when you request new engine features. You better stick to Quakespasm or leave. 

so how is it up there on that cross 

But anyway, @Maxi... are you talking about the kind of thing where a view from inside actual box of geometry somewhere in the level gets projected into the skybox?

It's a neat trick, and I wouldn't be entirely surprised if it's already been implemented by FTE or DarkPlaces or something.

I'm not entirely sure what the best use for it in a typical Quake environment would be. I can think of a few things, but what sorts of possibilities did you have in mind? 

Get a fucking grip and post under whatever name you did previously.

Maxi, not sure how useful it would be to be honest. 

@Fredo Sorry, I didn't know that. As I said, I'm new into old-school gamimg communities, so I don't know all the rules yet. That actually was one of the reasons why I decided to post this - to understand what changes in engine are considered acceptable and what is generally frowned upon in mapping community, even if it's technically possible.

I know the phrase "When in Rome, do as the Romans do", so I tried to ask politely, but it is always dilemma for a new guy - how to throw an idea so it will not sound rude, like some unknown guy giving unasked advices to already enstablished group or community. So, I didn't mean to sound disrespectful. 

@Johnny Law, I hope I'm not continuing to break the rules by answering that, please don't ban me ;)

I imagined something like level at the top of some massive palace, or inside huge cave, or LotR-style underground halls. May be even some small ancient village/town as a view from the windows of some tall building, or even some massive spaceship or space station for sci-fi styled map, but this is possibly too-much.

But even something simple like desert or sea to the horizon, or some brush hills/rocks/mountains at the distance may also look interesting.
But it would possibly look too out of place in Quake, I'm not sure... 

No you are not being disrespectful or anything. You asked a perfectly valid suggestion / question. The Fredo-anon is just trolling and whining. 

Oh, ok. Anyway, this is pretty random idea, but I tried to google it - unsuccessfully, so I decided to start this thread myself. 

Also I know nothing about 3d graphics programming, so not sure - how realistically lighting would look, especially at the border between real and projected geometry. Also, is it possible to make textures not to be 10-times stretched, without huge perfomance drop? 

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.