 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Because, MadFox, if you're using that piece-of-shit "Deathmatch Maker" non-editor, like you implied earlier, then no, you are NOT using the grid.
Deathmatch Maker doesn't use the grid, it uses it's own arbitrary decimal grid (i.e. increments of 10), with no way of changing it, because the creator obviously assumed that it's users would be too stupid to understand the concept of a binary grid system. Deathmatch Maker is useless for mapping. Don't use it. Thanks for your response.
I am making the best of the less. I bought this Deathmatch maker, because I thought it would comfort me in mapping. Now I worked some time with it, and it surely has a bunch of tricky errors in it. But I must admit it's more than the Qmap I was working with in that time. So now I am gathering the goodies in it, like the bright textures, and the prefabs, which are realy worthwhile. The carving tool, I was making, relates to Quark. I hope this editor uses the grid well. I got some interesting results, with polygons extracted from leaks. Is it true that the carving tool only causes grief? I thought it works quicker carving a cube, than adding six walls. Or are you reffering to the fact, they could cause microbrushes? ...nothing wrong with carving. Know your scale, know your shape, know your editor, and carve and be happy.
This is carving and NOT subtracting. I use Worldcraft (very occasionally) for Quake 1 level building.
They do say in their tutorial - " Carving, or subtraction as it's sometimes called, is a fundamental feature of any Quake editor. However, it is also the most likely to cause map errors if used wrong, and sometimes even when used right. The most experienced level editors tend to avoid this feature whenever possible. " Links : http://www.planetquake.com/worldcraft/tutorial/index.shtm Actually, I've been trying to find WorldCraft 1.6a Registered on the Internet and it's impossible to find. I'm uploading it to my website when I get home. It should be freely available now concidering you can't actually buy it even if you wanted to. Stupid :P Well, as far as I know, the only situation where carving (or "subtracting" if you like) produces desirable (or predictable) results, is when you want to punch a simple rectangular hole into a simple rectangular brush.
And quite honestly, in that situation the end result would only take a couple of seconds longer to build the usual way. You're far better off using the clipping tool. they only place where i found it useful was for taking corners off of square brushes. but then i started using gtkr and i could use 3 point clipping which totally roxors.
OK, this is where the editors seem to use different terminology. In BspEditor you have two distinct functions - Carving and Subtraction.
Carving is the act of determining two points on a face of a brush and 'slicing off' the denoted section, as per necros above. Subtraction is the act of removing the shape of one selected brush/s from an overlaping brush/s. Carving affects the one brush only and is therefore not in the slightest bit dangerous (besides, you have an Undo in the Edit menu?). Subtraction can be a dodgy tool as it (usually)affects several brushes. As an example, in Fmb100 I inserted Tronyn's map VII right into my terrain. The terrain was larger than the imported map and therfore blocked the passageways in the buildings. So, select everything in VIII (it was imported straight into a Group and was therefore selectable en'masse) click Subtract and the shape of VIII was 'subtracted' from the terrain. The passageways were still blocked, but only by the parts of the original brushes that had not been subtracted - this was empty space before and not affected by the 'subtraction'. Now, move through the passageways selecting and deleting the bits of terrain that were blocking the path. Very quick, and besides, you didn't think that I fitted all of that terrain to the buildings did you? So, carve and be happy; subtract with care. Not really a Scrrenshots and Betas topic, sorry. Thanks for your pricisly subscription of the subject. Makes the mapping help toppic great!
In my screenshot i had a stamp sized in the shape of a walltexture. This were two polyhedrons, used as a stamp group, which i carved into a new cube of the same texture. As long as the 2 poly's of the stamp fit exactly, they create 4 new with diagonals. If they don't fit, they create triangle poly's and microbrushes which mostly create errors. Reading more of this subject encouraged me, because when the stamp is textured well, it makes pretty sideblocks. So, select everything in VIII (it was imported straight into a Group and was therefore selectable en'masse) click Subtract and the shape of VIII was 'subtracted' from the terrain.
/me turns pale and begins to shake somebody hold me Jesus Christ on a bicycle, Mike! o_O - Do you think that might have had something to do with the #clipnodes problems you were getting?
No, absolutely nothing to do with the clip_node problem, which I believe is related to the complexity of the terrain brushwork and the limitations of the compilers, not subtraction. This is bourne out by my experimenting with terrain over the last nine months.
The clip-node issue is clearly apparent in a terrain map long before any other brushwork is added. Once extra brushes are added the clip-node problems either remain or REDUCE. I did not find any clip_node problems remaining in Fmb100 during testing, although some were reported by necros after release. (Mind you, he was probably using the ramp on the island nearest the third building and is misunderstanding the power of the launch - it's easy to overshoot) The only real issue with Subtraction is the possible creation of extremely small or acutely angled brushes, which the compilers do not like. But these can be routed out by the Merge Brushes function or by manual deletion. Have a look at Fmb100 in an editor and check out the brushwork: delete the buildings, compile and count the clipping errors. Reinstate the buildings, compile and count the clipping errors. Subtraction is a tool, not heresy :-) But then, I never did wear drainpipes either! Even as a newbie mapper I have to stare in awe at somebody who would grab somebody's whole map and use it as a carving tool - lol.
Sorry, I just don't believe that basically butting two whole maps into each other and subtracting one from the other will not lead to thousands of extraneous splintered brushes, and horrific compile problems.
How many brushes did you say Fmb100 had in the end? See my previous post on the subject of the use of clipping_brushes to reduce clip nodes. There is extensive use of these where I did not expect/want the player to climb.
You can climb up to the LG and you can climb from the LG to the narrow (slightly hidden) path to the second building: or you can slide down the terrain without losing health and use the secret short-cut. You can also climb from the second building all the way round to the roof of the third building and drop down onto the platform. You cannot climb around from the third building to the back of the first building. You cannot climb from the LG all the way to the roof of the first building. Lastly, you can jump onto the island and then onto the platform of the third building. If you look at the map, you will see that this is very deliberate. The only clipping problem that I found prior to release was between the health and the rockets on the 'beach' area. This was removed by the addition of a clone brush - you will see that there are two triangular brushes jutting-out slightly, whereas there was originally only one. I have yet to find a clipping error on the map but I cannot say that there are none. I can assure you that I could provide a non-subtracted version of the map that is rife with clipping errors and the final Fmb100 has so few(?) that I still cannot find one. Any-road-up, subtraction can be used with care, is not heresy, and can by beneficial without side-effects. I will admit that my use of it in Fmb100 was extreme but this is what happens when you play around with completed maps as there was no other way I could have achieved the joining. Note that I join maps, I do not build them from scratch and haven't done since Fmb1. I have used subtraction since Fmb2 and I had my pointed tail long before that! If you enjoyed the map, all well and good. If you did not and the clipping errors spoilt it for you, I am sorry. Will I stop Carving and Subtracting - I guess you know the answer. And what a long post again... and still in the wrong area :-) and I don't think it matters much how you built it, although I must admit it's an unusually bold way of merging two maps.
I've actually done similar operations to test the compilers. I've taken several huge finished maps and just merged their brushwork sections (not entities) in the text map file to produce gigantic brush-heavy scenarios. The biggest had around 28k brushes and still compiled, although with excessive memory consumption, processing time and bsp values (clipnodes etc). The resulting maps looked a bit odd in-game though I'm still surprised at how well most compilers can handle "messy" maps, i.e. maps off grid or decompiled with a huge amount of microbrushes, gaps and warped planes. I guess it's the same reason that the build process is a bit fuzzy; it's not entirely deterministic and therefore even clean and tidy maps sometimes have build problems that can't really be explained. ...that's another good point: I never build/join off-grid. When adjusting maps for joining you may find that a non-rectangular brush (chamfered, bevelled and/or tapered) ends up off-grid. So, and this is where I also use Subtraction, you line up your joining brush on-grid and overlapping the off-grid brush, and subtract. You now have two on-grid brushes with no visible join in the map. And is this not one of the things that compilers like?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |