 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Hey there! So I got my map working and fixed all the leaks, but for some reason, when I run the map in GLQuake, it renders a far off distance like it's clipping! Is ther anyway to increase the drawdistance like in winquake with r_maxsurfs and r_maxedges or is it impossible? Could it be a mapping problem itself? Compiler gives no errors!
Because it's the best engine that comes with the Steam version.
Well, the second best, but the default one. It's worth remembering that's the out-of-the-box experience, when you're looking for the largest possible quake audience. I'm new to mapping, i've been using EricW's tools. In regards to the VIS proccess, has there ever been any consideration into farming out jobs over a network? I am sure i'm not the only mapper who has a second PC that is idling alot. I can picture small communities of mappers providing their PC's for VIS jobs. And not just 1 map/PC (that could already be done with some kind of file monitoring script). I'm talking about splitting one bsp over multiple PCs to get the completion time down. It seems with multithreading the individual threads are operating independently anyway once they get their work chunk.. granted i don't know anything really.. just my assumption. This seems to be the biggest bottleneck in dev time. Maybe the couple guys i am in a group with are inefficient mappers but the VIS'ing has taken days and days on an 8 thread i7. It would be cool if network nodes could just be seen as additional threads.
Should be helping with the vis times. Unless you are building a gargantuan map that rivals Ter Shib in size I can't see VIS taking this long with 8 cores. I vised a bsp2 size map in less than 1 min. on 3 threads with ample use of detail brushes.
Again this could depend on the size and complexity of the map, but if you are new to mapping, you should be using detail brushes on objects like pillars, stairs, loose bricks, small details etc. or else VIS might take days where is should be seconds. With func_detail, vis should not be the longest part of the compile any more.
Make sure you are using ericw's tools: https://ericwa.github.io/ericw-tools/ For instance, anything angled, off-grid, small, thin planks, trim, light panels, crates, pipes, broken walls, debris chunks,
trisoup (terrain e.g.) etc. etc. should be func_detail (solid) or func_detail_illusionary (not solid). This lets vis deal with very simple rectangular areas and drastically speeds up compile times. It also can help you add specific lighting features to some details, such as _phong (nice and smooth shading) on rounded columns or terrain trisoup. Aside from wanting to apply phong shading to columns/pipes/whatever (which can be done with standard func_walls as well), if you're willing to eat the compile time instead that seems like going overboard a little with the details. Won't you run into issues with vis not blocking off *enough* due to details making up walls and such and possibly cause poor map optimization and lower framerates on less powerful machines? Not to mention the extra effort of making a solid rectangle area outside of any part of the map even slightly skewed or clipped-'n-vertex-edited.
Depends on balance between CPU and GPU time per frame. Loads of objects to render = long GPU time. Loads of vis leafs to calculate against = long CPU time.
E.g. in a level with 10ms CPU and 20ms GPU, it would help to render less, so yes more leafs could help. If instead you had 20ms CPU and 10ms GPU, then fewer leafs would help improve performance then func_detail would help. I honestly don't know what the bottleneck would be or how to check it. gpus are quite fast nowadays, they don't really care about a few hundred more quads.
overdraw is still a concern (so you still want your various rooms to be properly sealed with structural brushes to avoid the worst of it), but otherwise if the engine has decent batching then you won't see much of a problem if all the details+pillars+etc are flagged as details. tbh, its the leafs themselves that are the expensive things. That in quake, you can't appreciably change the number of leafs with func_detail, only the vis compile times. Has this changed?
no, you have the leafs whether they're detail or not.
you can't fold leafs using q2-esque cluster stuff, because the bsp format doesn't support it. and you (usually) can't merge leafs due to the engine calculating a parent leaf - each one must have a single parent node so no multiple routes through the bsp tree (side note: this doesn't apply to hulls 1+2). so the only way you can merge them is if two leafs share a parent node, have the same contents value, and together form a convex area (such merging can happen recursively so long as those conditions still hold true). less leafs means fewer marksurfs, fewer nodes, fewer frustum checks, smaller pvs data (and for every other leaf too), and fewer cache misses throughout. arguably surfaces could be merged into a concave mesh on the condition that there is still 1 truely central vert somewhere. the geometry works even if they're on different planes, but lighting and texcoords would likely be broken because of it. whether it would break software rendering, or gl engines that pick the wrong edgevert is a different matter, but hey, most gl engines should cope without realising it. Engines should be able to recover detail clusters by recursively merging leafs that have the same visofs. This has the benefit of working on released maps and won't risk breaking anything. Once you recover the clusters you could generate lists of faces per cluster, new compact visdata, etc.
Hello,
Longtime quake player, trying to create a custom version of DM3 with some Scourge of Armagon assets for team deathmatch. I used pak explorer to extract the DM3.bsp from pak1 in id1 and was able to convert the bsp file to a Any help would be appreciated :) Cool idea to update Dm3 for SOA. The source for DM3 is available at Quaddicted. So use that instead of a decompiled bsp.
You'll have more luck. https://www.quaddicted.com/files/maps/sources/quake_map_source.zip Next, you will want to load up the mission pack fdg in Trenchbroom. I have been searching for it but cannot seem to find the link. But it's out there. When you have the fgd you will go to the entity tab in TB and at the bottom load external and select that fgd file. After that you should have the entities available to you in the browser. You will also want to load the mission pack as a mod in TB in a very similar fashion. It's on the map tab I believe. I might as well pimp a DM level I made that includes a Hipnotic version of the map. It's called Lividus. Maybe you and your pals will enjoy it along with DM3.
https://secretlevelsite.wordpress.com/my-levels/ Thank you for the help and taking the time and all the links provided! I managed to figure most of this out through a bit of trial and error and talking to the devs from qrack and fte. Some of those old assets are indeed hard to find!
I still play TDM with a group of oldschool quakers on DM3. Matches on most weekends. I was looking to create a fun tweak of DM3 that would preserve what works about the level for teamplay, i.e. the idea of level/item control without messing up the balance too much. But due to having played it 9999999 times, I thought adding some SOA assets would be fun. I added the proximity grenade launcher at the opposite side to standard GL, replaced the SNG in the SNG room with the laser cannon, replaced the standard nailgun (useless in DM) with the SNG, and put mjolnir outside by the pent. I feel like these weapons could lead to a few interesting tweaks in gameplay (e.g. setting traps with proximity mines, using laser cannon to blast into areas by bouncing shots, mjolnir to close proximity attack somebody with weapons). If anyone's curious, here's the first iteration. Requires the hipnotic pack to work (i.e. whatever executable you're using -game hipnotic -hipnotic for command line switch): https://nofile.io/f/arGY5npZyZ3/dm3a.bsp
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |