Models Replacing Brushes....?
dalewb
Join Date: 2003-09-02 Member: 20504Members
Join Date: 2003-09-02 Member: 20504Members
<div class="IPBDescription">take complex brushes and convert them</div> [FONT=Times]You guys have an incredible web site here! Anywho, this is my very first post here. Since there seems to be a very advanced mapping community here, I thought I'd post my query here.
Is it possible to export brushes from WC into the map file format, then take them from that and convert them to models? In all my years mapping, I have never taken an interest into pursuing modeling. It takes long enough just to get good at mapping that throwing modeling into the mix was just too much. But in this situation, I would definately benefit from it. I have numerous spiral staircases in this level I am building, plus about 20 wall sconces throughout the level which are wreaking havoc on my planes count and clipnodes count.
Trying to compile the map with the staircases as reg brushes was impossible. After 6 days in VIS (trying to do a full compile) I gave up. Converting them all to func_walls allows the compile process to finish at the expense of r_speeds. I could handle that (for now) but I am nearing the clipnodes limit and planes limit! If I can't find a way to lessen these, I will have to end work on this level and start a new one <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->.
For your information, I have copied the table at the end of the compile process to the end of this post. I have also attatched one pic of some staircases included in the level. Any suggestions would be most appreciated.
Thanks!
Dale
Hmm, looks like I'm only having probs with clipnodes. Well, still, that's a prob. Here's the table:
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 98/400 6272/25600 (24.5%)
planes 34764/65535 695280/1310700 (53.0%)
vertexes 15385/65535 184620/786420 (23.5%)
nodes 7576/32767 181824/786408 (23.1%)
texinfos 441/32767 17640/1310680 ( 1.3%)
faces 12378/65535 247560/1310700 (18.9%)
clipnodes 29708/32767 237664/262136 (90.7%)
leaves 4744/8192 132832/229376 (57.9%)
marksurfaces 14225/65535 28450/131070 (21.7%)
surfedges 54972/512000 219888/2048000 (10.7%)
edges 28656/256000 114624/1024000 (11.2%)
texdata [variable] 168/4194304 ( 0.0%)
lightdata [variable] 3024033/8388608 (36.0%)
visdata [variable] 693248/2097152 (33.1%)
entdata [variable] 65395/524288 (12.5%)
41 textures referenced
=== Total BSP file data space used: 5849498 bytes ===
4430.12 seconds elapsed [1h 13m 50s]
Is it possible to export brushes from WC into the map file format, then take them from that and convert them to models? In all my years mapping, I have never taken an interest into pursuing modeling. It takes long enough just to get good at mapping that throwing modeling into the mix was just too much. But in this situation, I would definately benefit from it. I have numerous spiral staircases in this level I am building, plus about 20 wall sconces throughout the level which are wreaking havoc on my planes count and clipnodes count.
Trying to compile the map with the staircases as reg brushes was impossible. After 6 days in VIS (trying to do a full compile) I gave up. Converting them all to func_walls allows the compile process to finish at the expense of r_speeds. I could handle that (for now) but I am nearing the clipnodes limit and planes limit! If I can't find a way to lessen these, I will have to end work on this level and start a new one <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->.
For your information, I have copied the table at the end of the compile process to the end of this post. I have also attatched one pic of some staircases included in the level. Any suggestions would be most appreciated.
Thanks!
Dale
Hmm, looks like I'm only having probs with clipnodes. Well, still, that's a prob. Here's the table:
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 98/400 6272/25600 (24.5%)
planes 34764/65535 695280/1310700 (53.0%)
vertexes 15385/65535 184620/786420 (23.5%)
nodes 7576/32767 181824/786408 (23.1%)
texinfos 441/32767 17640/1310680 ( 1.3%)
faces 12378/65535 247560/1310700 (18.9%)
clipnodes 29708/32767 237664/262136 (90.7%)
leaves 4744/8192 132832/229376 (57.9%)
marksurfaces 14225/65535 28450/131070 (21.7%)
surfedges 54972/512000 219888/2048000 (10.7%)
edges 28656/256000 114624/1024000 (11.2%)
texdata [variable] 168/4194304 ( 0.0%)
lightdata [variable] 3024033/8388608 (36.0%)
visdata [variable] 693248/2097152 (33.1%)
entdata [variable] 65395/524288 (12.5%)
41 textures referenced
=== Total BSP file data space used: 5849498 bytes ===
4430.12 seconds elapsed [1h 13m 50s]
Comments
As for using models, you still would need to provide clipping for the staircase (unless there's a way to use solid models in HL).
<!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
So you really don't think there is a way, huh. BTW, I am using zhlt_1.7p11 as my compile tools and Nem's Compiler front-end program to create the batch files (I got so sick of manually adjusting those!). So I have already done the optimizations.
Now, is the max number of clipnodes 32,767? That's what I wasn't sure about.
Dale
<!--emo&:D--><img src='http://www.natural-selection.org/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
So you really don't think there is a way, huh. BTW, I am using zhlt_1.7p11 as my compile tools and Nem's Compiler front-end program to create the batch files (I got so sick of manually adjusting those!). So I have already done the optimizations.
Now, is the max number of clipnodes 32,767? That's what I wasn't sure about.
Dale <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
EDIT: Max clipnodes is 32767 (32K - 1).... confused it with the face limit... clipnodes are stored as a signed short in the file format, so this is a hard limit. Negative values are reserved for leaf content types, so the number can't be used as an unsigned value.
To address the main question, it is possible to convert geometry from a brush model to .mdl format, but you'd have to chuck the texture information and slap on a default skin when doing the conversion... mdl skinning uses an image reference system that is completely different from brush texturing. You'd end up losing texture detail in the form of light and decal information as a tradeoff for faster per-face processing. I haven't seen a converter and although I might have use for one, I have a lot on my plate on the moment (writing a new BSP toolset from scratch) so it's not something I'm going to be working on.
P.S. -- if you see odd lighting artifacts when using RAD with p11, you might want to download p10 -- I've had a report of odd lighting with p11 and I haven't looked into it. I've made p10 the current download in the webbed thread in the meantime.
I have the same problem! <!--emo&:angry:--><img src='http://www.unknownworlds.com/forums/html/emoticons/mad.gif' border='0' style='vertical-align:middle' alt='mad.gif'><!--endemo--> I have completed two very large TFC maps. Both were quite large. In the first, I compiled regularly and continuously revised my design to keep r_speeds under 800 (they spike up to 1050 in a few hard-to-get-to areas) with most of the level at <600. The other one, though, was enormous, with clipnodes at 99.8% fullness (not using the cool new compile tools) and r_speeds way too high. But it was a great-looking complete level (it's still waiting in line at Pixel for a playtest, hahaha) called thegorge.
(sigh). I went out and bought Unreal Tourn 2003 the day it was released and began mapping for it, but it was super hard to get used to. Plus, I don't know if you guys know, but UnrealTourn 2003 and Unreal2 use different builds of the same engine/editor and their maps are incompatible with each other! The UnrealTourn 2003 Editor (released first) was more advanced and easier to use than the Unreal2 editor (released months later). Never mind the fact that the editor is not nearly as stable as Worldcraft.
Well, thank you all for your input, it has been quite helpful.
Dale Broadbent
The UnrealTourn 2003 Editor (released first) was more advanced and easier to use than the Unreal2 editor (released months later). Never mind the fact that the editor is not nearly as stable as Worldcraft.
[..snip..] <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Sorry for dragging this slightly OT, but is UnrealED still in beta or have they FINALLY completed a final version.
<img src='http://www.unknownworlds.com/forums/uploads/post-4-1062545999.jpg' border='0' alt='user posted image'>
with witch editor u creat this???
*Note to dalewb:
If you build this in WC/Hammer, <b>don't</b> check out QuArK's path duplicator plugin at the risk of serious frustration.
I hear from others that they have UPDATED the editors from the first released versions, but as far as a final version I don't know. I do know the original editors (and maps) released with UT2003 and Unreal2 were incompatible with (but similar to) each other.
Thursday:
You got me. I am not a NS mapper. I was attracted to this community due to my continuing search for better compile tools. I had heard whispers around the HL community about such tools existing, but it took me forever to locate them (here). But never fear. I will not be popping up here constantly leading the members off track on my tangents. I just had some questions I thought only you guys could answer and I was not disappointed, I am happy to say. :-). These pictures are of another of my Team Fortress levels based on the texture set from Gunman Chronicles, of which I was once a developer for. For anyone interested, I do have a level which has been reviewed on a few sites. It is likely the only level for Team Fortress that uses 100% Gunman Chronicles textures. <a href='http://www.jmcsmapzone.co.uk/thegorge6.zip' target='_blank'>http://www.jmcsmapzone.co.uk/thegorge6.zip</a>.
Icecream:
Valve Hammer, version edited by clan [WTH?] (has bigger properties menus and stuff).
Wolv:
Thanks for the warning. I have used Quark many times in the past for various tasks that other editors couldn't do (viewing bsps, manipulating entities, finding leaks), but its interface was just too wierd for me.
Blackpanther:
I agree that it is better to do that (reduce # of steps). I start out in Hammer using the arch tool. I then create a single brush 10 units high (the shape/size of the brush isn't as important as how tall it is) with that tool and hit enter. Why 10? Because at 12 units high Gordon (the HL guy) can't climb the stairs without jumping. Perhaps the number is 14 or 16 - I forget - and that would help with framerate, but 10 is a good number. The shape of the brush I create is generally rectangular. The arch tool will take that single brush AND apply the thickness of it (10) to whatever I make with the tool. By choosing the "step" amount to be < or = 10, and choosing the shape I want the staircase to be (180 degrees is my standard - half a doughnut, basically) the tool will create a perfectly-connected group of stairsteps with a beautiful curve. I then go in by hand and manually vetex-edit each vertex of each brush so that every vertex is snapped to a grid of 2 or 4. There are ways to do this that greatly reduce the amount of time involved (using different views that allow me to drag a selection box around groups of vertices rather than hand-click each one, for example). IF and only IF I do not TOUCH the staircase after it has been created using the arch tool (move it, vertex manip various points) and IF I initially choose a thickness value of the initial brush to be a multiple of 2, THEN when I begin the process of making sure every single vertex is snapped to the grid it will be a simple and quick process. Selecting, for example, every bottom left vertex of each staircase brush will allow me to snap each one of those to the grid because they were made by the arch tool and as such are in exactly the same spot relative to each other.
Once they have all been snapped to the grid, the entire staircase then can be moved around without any errors (before or after compiling) and can be shaped (in limited ways) using vertex manipulation.
I said this to point out that while the initial size of the brush doesn't matter too much in the overall composition of the staircase, it does effect the overall look of it. Larger steps make a more blocky, angular look. I was looking for a more smoothed, curved look. And that is what I achieved at the expense of r_speeds and clipnodes. I was able to eliminate almost every "lift" in the level and replace it with a staircase of some sort. Much more artistic. But the HL engine just can't handle all that. These staircases - wether solid or func_walls are killer on the clipnodes, I have seen.
Well I think I have taken this message board far enough afield. Thanks for all your coments and conversations. If you wish to talk to me further, I am getting private messages from this message board and I'll respond to those.
Dale Broadbent <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
HL just wasn't meant to have rounded architecture... or stairs for that matter.
Look at DOD_Avalanche for example. See what Valve has done?
The map's stairs are actually slopes. The stairs are all rectangular brushes in a single func_wall over lapping the slope. This doesnt make any clipnodes per stair and looks just as good. they also lowered R_speeds by putting NULL texture on the unseen faces of the stairs.
BUT, those stairs were "encased" on each side. Only the top and the front of the steps were visible. Yours are wide open everywhere. THAT is your problem.