metlslime: people who don't relieze why they're doing something, but do it anyway. 

Appearantly the caulk-hull method has it's roots in Quake 3 engine games. Newer games such as Call of Duty rely on this technique as the current tools are not that efficient at removing faces from structual hull brushes. As a result many people have adapted to using the caulk for everything, then going back, retexturing and using massive ammounts of detail brushes.

In Doom3 the bsp compiler is efficient enough that the caulk-hull method is no longer needed. I believe some people in the Doom3world.org boards are having a hard time moving away from this technique. A few guys there have done some performance testing to back up this believe, and as Scampie linked a fairly knowledgable sounding guy also said caulk-hull is no longer needed. 

But I thought I'd post a link to the little tutorial I just wrote up regarding geometry.

http://www.doom3world.org/phpbb2/viewtopic.php?t=4112 

Thanks scampie nice work :D I can never get my head around curves tho, would you do a wall curve the same method and how do you apply a texture to just the curved side of wall and caulk to the back? 

Nice job. :) 

Just taken a look around, followed some tuts and I didnt know it was that easy :) 

http://www.doom3world.org/phpbb2/viewtopic.php?t=3353&postdays=0&postorder=asc&start=0 

whoa! what they say is true! mitering IS a thing of the past with d3's bsp process!

http://scampie.spawnpoint.org/d3/mitre_compare.jpg

I must say, I am impressed. 

um... by mitering, i assume you're talking about the way the brushes meet at 45 degrees?

how would that affect the lighting like you mention in your tutorial? 

Thanks for pointin that out. I'll probably still miter like normal tho, I for some reason believe it keeps my map cleaner... what that means I'm not sure. I just feel it's tider with stuff mitered, not everything mind you.

I'll try to be more vague next post. 

er? i never said it helped with lighting... never even mention lights.

but in Quake engines, had I made the example on the left, it'd have almost twice the polygons as compared to the section on the right, due to how they meet end to end instead of side to end. 

here's the same test done in q3. show is taken the opposite way to show how it splits the wall bad too, so the mitre section is on the left now.

http://scampie.spawnpoint.org/d3/q3_mitre_compare.jpg 

http://collective.valve-erc.com/index.php?doc=1047005525-19966900

but I would not be suprised if Scampie knocked this one clean out of the park. 

I'll probably keep mitering out of sheer habit, and also because it makes the map look cleaner in-editor and helps me to see what's what at a glance, but it's nice that you don't have to be really anal about it and sweat performance anymore... 

Headthump: I shouldn't even dignify a Half-Life mapper's claims with a response, but if you insist.

His argument is based on tests that don't have anything to do with real life mapping. In his first, he shows a light inserted within a 'pole', and somehow claims this proves that the bsp splitter is god's gift to render speeds. Without showing the tris, I see little reason to believe his argument. Here's the same piece, done in q3, on the bottom showing an unmitred peice, the top mitred.

http://scampie.spawnpoint.org/d3/q3_mitre_compare_2.jpg

If he's in fact not lying about there being no cut there, then there's more to the story than we're seeing. Possibly a decal? I know they exist in HL, but don't know how common they are in level design.

His second piece of 'evidence' just shows an example of the splitter doing it's job correctly and how we'd all expect it to work. A real world example, like in my first Q3 mitre comparision ( http://scampie.spawnpoint.org/d3/q3_mitre_compare.jpg ), shows the compiler just doesn't how how to effeciently deal with all the vertices of the various faces coming together and has to split things up. By mitering, and making more vertices meet at common places, less splits occur and thus less polygons are created.

Mitred brushes making the map cleaner is a personal call, I find in my mapping where I'm very concerned with overall design, it's much easier to see things. As for his final point, plane counts are a Half-Life compiler specific concern, and may well be true for all I know.

That's all I have for now. 

His second piece of 'evidence' just shows an example of the splitter doing it's job correctly and how we'd all expect it to work.

Compilers do know enough to combine all brushes they lay flat as he's showing, and will merge all the faces that have the same surface properties. 

thanks for that, scampie.

i don't know why i had it in mind that mitering affected light... O_o

i'll need to keep that in my for future maps. :) 

Mitre-ing revelation

Nice work, Scampie. I'll have to remember that. 

Mind you, I miter instinctively in Q1 and will no doubt continue to do so in Doom3 (if I ever get around to mapping for it). 

I always thought the whole bsp/csg way of making levels would be phased out with the Doom3 engine, but after seeing those pics of how Doom3 "automatically" miters brushes, it looks as though the Carmack is perfecting it. 

I shouldn't even dignify a Half-Life mapper's claims with a response, but if you insist.

Too true.

I wasnt sure it I should have posted that link, but I'm glad I did. I've used both methods in the past, and mitering does look cleaner; esp. on the x/y plane where I organize my layouts anyway. 

and i've seen so many threads on Doom 3 forums by people claiming the Doom 3 engine is "inferior". Inferior to what, Half-Life? Doom 3 may not be perfect, but the engine IS technically impressive. Carmack isn't some 15 year old who makes counter-strike mods, even if he looks like one. 

I've started futzing with the GUI scripts, following the tutorials on d3world mainly. As soon as I started, I made a beeline (lol!) in my tests to see if you could apply normal-mapped shaders to a GUI, my goal being to create a switch panel or a keypad that reacted to light the same as other textures, and thus actually looked functional and real and not like a happy shiny hi-tech LCD screen.

Sadly, putting a material shader in a GUI object doesn't work - Apparently to Carmack it wasn't conceivable that you could possibly create an environment in which happy shiny LCD screens would be advanced and out of place - and thus begins the slow process of my starting to hate all the shortcomings this engine will no doubt limit me with.

If I hack something up to fake it I'll post the process but I doubt it will be elegant, pretty, or even satisfactory. 

Send him an e-mail, he just might care and add it to a patch. 

well, there's a secret in the game which seems to be what you're looking for... when the crosshair goes over it, it still beeps, but the mouse crosshair isn't displayed. it looks like a normal block texture... you can probably not make it beep too...

i don't know if this is exactly what you're talking about. i'm still trying to figure out how to make most of the funky moving stuff and haven't even looked at the GUI things...