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? 

Ahahahahahahahaha*










*hahahahahaha (etc) 

oh no!! that's ... uh fucking satanic!
mike...omg!....


/me faints 

Rockys Revenge 

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. 

i noticed a bunch of the "invisible wall" things when climbing the terrain in the first area. 

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? 

an 'invisible wall' clipping problem is where you can walk past an edge, but can only jump over. the barrier is only present when you are in contact with the floor. this can also happen on walls. you jump, hit the wall and start sliding down the side, and all of a sudden stop moving, seemingly hovering in the air.

i wasn't talking about running into clip brushes. come on man, i'm not that stupid.

also i liked the map... no need to get hot and bothered... O_O 

problem is where you can't walk past an edge 

... I just can't find the clipping errors and without finding them, I can't correct them.

And I am assuming here (I know I shouldn't) that we are talking clipping errors generated at compile time and not simply getting snagged on brushwork where the player 'expects' the mapper to have put handy clip brushes in the map to stop the snagging?

I mean, if I have left a jutty-out brush in the map, I am happy for you to get stuck: it may aid MY monsters in killing you :-) 

"...I must admit it's an unusually bold way of merging two maps."

You did it without giving up or going insane, more power to you. 

want to play FMB100. It is only a matter of finding the time. 

want to play [and review] FMB100. It is only a matter of finding the time. 

FMB100 was a very enjoyable and good looking map no matter how it was built, and it was relatively bug free unless you went looking for them. Frankly, if you go looking for bugs specifically, you can find them in any map. 

screenshots? 

screenshots should be posted in the fmb100 thread, to keep everything balanced. 

http://celephais.net/board/view_thread.php?id=24816 

no, i mean screenshots of other maps. 

Ooops! I'm a bit slow.