 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
some of the most acclaimed maps in the last few years have been 100+ hour vis monsters, and i'd argue that the vis-unfriendlyness of the layout was worth it for the final effect.
I'd hate to have been denied the masterpieces of tronyn, necros, and the like just because of some arbitrary (and utterly inconsequential to the end user) constraint like how long a compile tool is allowed to take to do its job. "utterly inconsequential to the end user"
By that I mean: does anyone here even have trouble running a map in fitz at anything less that 72fps? No matter how big/complex it is? everyone is free to map whatever they like. i's just my opinion: if you use certain engine you ought to follow its limitations. i choose this way because it's more fun to map having such limitations and no restrictions on user end. ^_~
... despite with CDA, I decided to say: "fuck the limitations"... well, Quake can be happy I am patient, and the map deserved it at this time
http://lambert.jeanphilippe.free.fr/Screenshots/CDA1.JPG http://lambert.jeanphilippe.free.fr/Screenshots/CDA4.JPG http://lambert.jeanphilippe.free.fr/Screenshots/CDA5.JPG Globally I think limitations suck, but with such "old" game, it is obvious the mapper need to deal with it... i was a too young mapper at this time to think about that... hence now I know to occlude in better ways my maps... though... the next project I have is also "wide open"... but far away to be completed actually :P split the map up, does it really have to be so complex and big? Most of the original ID maps are short and sweet. Also the texture alignment in that top down screenshot is horrible. You don't need 100+ compiles to fix that, it can be done in the editor!
@JPL, your screenshots are way too dark and flat in contrast. Taking good screenshots is time consuming and most people spend little thought to the process. A screenshot is the selling point, it should grab the viewer and make them want more! Is there any consensus on what wpoly count is acceptable these days?
It strikes me that this entire issue can be settled if we know what our poly budget is, i.e. what r_speeds numbers are "too much"? It is rather hard for me to gauge if something is too complex when playing it, considering I can run (the accidentally unvised) Arcanum 4, or the open-plan madness of Unforgiven 1 and 3, on this 5-year-old laptop without it ever dropping below 72 fps in fitz. Was gigantic, and took 12 hours to vis. TBF I was using multi-threaded vis on a 5Ghz quad-core.
DirectQ is super-super fast anyway :) to have tools made to optimize content for 90s computers grind to a halt when a modern computer could most likely display the entire map more efficiently if it wasn't touched by those tools...
Heh, I've often had that thought.
Have any modern Quake engines ever tried just ignoring the VIS tables and just throw every poly in the BSP at the card each frame - compiled into buffers and whatnot for efficiency? some numbers:
interior map in ne_ruins takes 3 hours to vis on a dual core 1.8ghz. it also hits the absolute maximum # of faces allowed in standard bsp format. size (and even detail) != vis time also, don't forget, cda was vised on a single core system, so vis was nearly ~1.75x slower. AND it was released in 2005 so cpus were slower in general. might be interesting to see how long cda would take to vis on a modern (>3ghz) 4 core system. but anyway, remember to take into account tech differences. :) oh, re 8290:
i believe darkplaces doesn't make use of (or at least, does not requires) vis data. it culls stuff on the fly and is actually pretty darn good. i've loaded unsealed large maps in DP and the culling does a great job even with non-optimized areas (rooms open to the void allowing pvs into areas that it wouldn't normally). one issue with the darkplaces method is i think it adds quite a bit to the map load time as it generates the necessary data. I think I suggested to LH that he cache this on disk somehow, not sure if he ever did that.
in standard Quake, it is 32768, but the true maximum you can have is 65536 (this is the one i was referring to). after that, you must change the bsp format itself.
Final screenshots of my library scene
http://www.simonoc.com/images/design/concept/library_f01hd.jpg http://www.simonoc.com/images/design/concept/library_f02hd.jpg http://www.simonoc.com/images/design/concept/library_f03hd.jpg http://www.simonoc.com/images/design/concept/library_f04hd.jpg If you need more pixels and a larger download size, try these http://www.simonoc.com/images/design/concept/library_f01wd.jpg http://www.simonoc.com/images/design/concept/library_f02wd.jpg http://www.simonoc.com/images/design/concept/library_f03wd.jpg http://www.simonoc.com/images/design/concept/library_f04wd.jpg If you are interested there is the usual waffle about what happened http://www.simonoc.com/pages/design/concept/library.htm Willem is right insofar as, indeed, Quake tech isn't designed for large open areas with lots of detail. Not only can the compile time grow exponentially, there's also the chance the map will not run as smoothly on some machines - from what I understand, the engine is not optimized to render so much at once so it can it will choke in situations of excessive polycount and run poorly on machines that can run more modern games just fine. Case in point: this happened to me when playing the unvised versions of Arcanum on a P4. So the claim that nowadays VIS is irrelevant is wrong. DirectQ (and RMQ) apparently use improved rendering techniques that allow for more excess than standard Quake does.
Of course, it doesn't mean people should refrain from making large areas if they think the map benefits from them. Many of the excellent maps in the past were pretty large and open, and it worked. People who tend or like to go large aren't mapping for the wrong game, of course - they just have to be aware that it comes at the cost of (sometimes greatly) increased VIS time. Kinn: I don't think there's a new concensus. Couple years back people would say 800-1000, at least in non- or low-action areas. Today I'd say 1500-2000 maybe, even though many maps surpass this by far. Real skill shows where maps look great and detailed (and not overly constrained) but still keep r_speeds within a relatively low margin. Case in point: this happened to me when playing the unvised versions of Arcanum on a P4. So the claim that nowadays VIS is irrelevant is wrong.
But I would wager that it's for the wrong reasons. If an engine is parsing the VIS data lumps and using those to determine what to draw and blah blah, rather than just throwing every poly in the BSP into texture sorted buckets at the card - it's probably going to run slower than it optimally could. A map should be sealed, no question, so the extra cruft outside gets removed but I still question the need for the VIS structures on modern machines. Is there any consensus on what wpoly count is acceptable these days?
If I can get hold of a Raspberry Pi, I'll try using that as my low end test system. If it runs well on that, ship it! @Scampie, it is looking good, I love the attention to detail. I just wish the rivet shadow on the pipes was the right way and the metal seam was on the poly edge (pipe in foreground) not in the middle.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |