 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Here are the original map sources from Quake:
http://rome.ro/2006/10/quake-map-sources-released.html You can load them into your editor! http://www.bspquakeeditor.com/
IT's certainly one of the more attractive modern editors, and it's open source if I recall. You basically have to build the map in your editor, then you run the QBSP (TxQBSP is the best at the moment IMO) This makes the physical world model that is the bulk of the Light This adds a chunk of light data to the Vis This 'visually optimises' the map, for running speed. It adds a chunk of 'vis-data' to the Once you have run all of these compilers on your map/bsp file, your map will be 'fully compiled' and ready to run. If you wan't to add CTF to the original maps, you can load the Can be flagged in the map file as 'not in deathmatch', I'd imagine that CTF is a type of deathmatch effectively (anyone?).
This way, if you play singleplayer then doors etc will be there, but when you play DM/multiplayer they will be gone. id software used this feature to add multiplayer support to all of the singleplayer maps in the original Quake. It means you don't have to pack two full-sized different versions of the same map into the game package. average leafs visible: 593 max leafs visible: 2546 near (-288 224 704) c_chains: 2003978043 visdatasize: 1058 kb compressed from 4668 kb Elapsed time: 63h 35m State time: 13:42 G:\Bsp\Bsp96b\Quake\Maps\pause Press any key to continue... What are c_chains 'cause that looks an awfully large number? What is State time? Just saw this at I3D: it's possible to have Gtk- and NetRadiant display the actual models for entities instead of the colored boxes. You need to edit the entities.ent file and add the model path to each entry, e.g. model="progs/player.mdl". They are loaded from the pak file, but are displayed unskinned (unless, I suppose, you extract the skin somewhere). The big problem is that only the model is shown, not the bounding box, which makes correct entity placement unnecessarily awkward.
I had the same with my map.
Awfull lot of vising time, but I gave up at 67houres. Recompiling some real small brushes to func_wall made it up to 8 houres. For vising it takes too long. My example average leafs visible: 389 max leafs visible: 1544 near (-352 -152 -158) c_chains: 1540051406 visdatasize: 668 kb compressed from 3718 kb Elapsed time : 8h 58m Session time : 8h 59m State time : 1h 43m I don't know for state time. I don't think it are the c_chains, more some queer effect of brushes. Try hiding extensive places with a big cube. Try comparing the bsp limits...
18087 planes 361740 65325 vertexes 783900 29085 nodes 698040 1743 texinfo 69720 56641 faces 1132820 58573 clipnodes 468584 15487 leafs 433636 64691 marksurfaces 129382 236371 surfedges 945484 127066 edges 508264 447 models 28608 96 textures 2493028 lightdata 1639628 visdata 863654 entdata 193675 vertices, clipnodes, faces and marksurfaces are usually the ones to max out first, but sometimes nodes can too. it depends on how you map. in most (all?) modern engines like fitzquake, the limit for vertices, clipnodes, faces and marksurfaces is 65536. limit for nodes is 32768. Oh, I am not concerned about limits. And 63 hours vis time is not a problem: I just start the computer, shut the door (noisey fan) and take a peek each night before I go to bed. I just wondered what c_chains were.
No, the map is fine, plays fine, looks fine; and I only use FitzQ so going over a few limits is fine. RickyT23 posted a link to BSP editor. Anyone use it? Can it do things better than Hammer?
I tried it out for a few minutes (lots of buttons). Is it worth learning? I've used it for many years and never found anything better (but I did stop looking once I had used BspEditor). It is worth learning but use the tutorials and read all the notes because although it has a general Microsoft look and feel, it is not intuitive.
I use version 96B because later versions omitted support for Tony Brownlow's complier routines, and I use that program call to run my own compiler. However, the later versions do have some good additional facilities, so if I was starting again, I would have used the latest version automatically and never have know about the support for Brownlow. Nevertheless, the built in batch file processes work just as well except that you have to write additional routines to make use of all the features of later compilers. I have never understood why more people did not latch on to it? Screenie showing models in the 3D view complete with bounding box (shambler and torch visible)
http://i.imgur.com/GTHgc.jpg I'll try it out. Is it possible to have dialog boxes similar to Gimps "dockable dialogs" (boxes outside of the main window). That would be great for editing with 2 monitors. Any editors do that? I think it would be great to have the visual representation on one monitor the 4 views and the nuts and bolts entities, textures... on the other.
What are efrags and should I be concerned if my map goes over the limit? Fitzquake seems ok with it and gives me a warning, but the warning appears after the map has loaded instead of before like the surf limits etc.
"Too many efrags!"
This console warning is normally caused by having entities (typically torches) too close to or even partly inside solid walls. Another possibility is too many (or too far apart) brushes that are included in one brush entity. EFrags means Entity Fragments. Enhanced Win/GLQuake has higher limits. Thanks for that. I should have checked the compiler tips, since it was helpful last time and I'm assuming that's where you found that info. Sorry for being lazy :)
It's indeed 'fragmented' entities like when you put all details in a room in a single func. The efrags count increases especially fast when doing this with func_illusionaries. Use devstats to keep track of current number.
Also note that clients handle efrags differently - older ones are usually more picky about it than e.g. Fitzquake and may constantly spam the console if the limit is exceeded. I always place torches 4 units inside the walls because I don't like the look of 'floating' torches, which is what you get by placing the torch's bounding-box flush to a wall.
My current map has hundreds of torches placed like this and does not report the efrag error. Mind you, I do get:- 33744 marksurfaces 8808 signon buffer 64 lightmaps 1257 byte packet 343 visedict at map loading, and in game at one point I get:- 36 blights 601 edicts I don't think the torches-in-wall explanation is correct anyway. Best torch placement is where the origin of the torch is 2-4 units away from the wall, yeah. Certain areas may require to set the light level of the actual torch entity to 1, and use a point light several units in front of it. There's absolutely no reason to have floating torches or flames in a map - even through there are editors that only show them as boxes, it's all just the laziness of some mappers not to place them properly.
Mike, don't be lazy yourself and go optimize the map for vanilla limits. With those marksurfaces and edicts counts, it looks very possible to do that. I'm pretty hazy on the exact working of efrags but I can see they are about entities straddling multiple leaves in the bsp tree. I wonder if tweaking the torch model to have a 4 unit offset would avoid the problem. On the one hand that would fix it if efrags were generated by entity bounding boxes crossing leaf boundaries. On the other hand, the efrag code seems to be in the rendering portion of the engine so maybe it's the model bounds rather than the entity bounds which matter. In that case moving the model instead of the entity does exactly nothing...
I can confirm it is the model bbox not the ent bbox which counts. Please disregard that suggestion.
"Don't be lazy", well, as I am sure you know, it is not a case of being lazy; it is a case of mapping for my pleasure, not other peoples. If you ever see this map, you will understand why it is not meant for vanilla Quake, and will not be worth bringing inside the original limits. The original map was over 20,000 brushes with 700 monsters, and covered the full 4096 x 4096 area. I had already cut it down and released FMB_BDG a few years ago and what I have left is the balance.
Besides which, weren't the compilers and engines enhanced just so we could 'break' the limits? Otherwise, there was no point! Anyway, don't worry, I know what you mean ;) ~690 at the moment, and I have a lot of large funcs. I can probably reduce them a bit as I've nearly finished the map now, but I wonder if I'll be able to reduce them enough. I'll do some tests tonight to remove the largest func_illusionaries.
Aside from that, it's just clipnodes and marksurfs that are over. No way in hell I can lower marksurfs enough to bring it under the limit without spending a massive amount of time removing detail, but clipnodes should be easy enough, since there are lots of arches and small details in the map. God I'll be glad when this pos map is finally finished and I can forget about it at last :/
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |