News | Forum | People | FAQ | Links | Search | Register | Log in
3d Skyboxes For Quake?
At first, I want to introduce myself. I'm newbie mapper. Video tutors on dumptruck_ds channel motivated me to switch (at least for a time) from learning mapping for HL in JACK to mapping in Trenchbroom for Quake. Also I'm trying to learn Quake C.

So, to the question. Recently I've got a strange idea. What if some of the sourceports, that added new fatures (like mirrors in Mark V, for example) - added also a possibility to use 3d skyboxes, like in HL2? I don't know, maybe it's stupid and too much not-quake, but at the same time I can imagine possibilities it could add for mapping.
Anyway, I wanted to know what do you think about that idea. Is it too crazy? Is it hard to do technically? Would anybody even cared if such feature existed?
First | Previous | Next | Last
 
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. 
Cool Stuff Tens! 
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! 
Where Were U When Vis Was Kill? 
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. 
@Tens 
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). 
Crackpot Noob Idea 
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 
@eric 
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. :) 
+1 Test Map 
This is very interesting and promising, and I'd love to see a true map-sized proof of concept. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.