Plzz help to place hint brushes in my map
Skyforger
Join Date: 2007-03-25 Member: 60494Members
<div class="IPBDescription">plzzzz </div>here is the file <a href="http://yy.lv/download.php?f=47723" target="_blank">http://yy.lv/download.php?f=47723</a>
Plzzz i try all the wey's i know. fps is till low anywhere near the ship.
plzzzzzz help to make a higher the fps
Plzzz i try all the wey's i know. fps is till low anywhere near the ship.
plzzzzzz help to make a higher the fps
Comments
I have not had a chance to look at your rmf. However, may I suggest you read the following lovely writeup at the <a href="http://developer.valvesoftware.com/wiki/Optimization_%28level_design%29" target="_blank">Value Developer Community</a> Note that this is using source. The concepts should be very similar in halflife.
The level to which the hint brushes will help your frame rate is very map dependent.
I believe the engine uses gl_wireframe to control how the level in rendered with gl_wireframe3 showing all the polies currently being rendered by the engine. If you go to the area you mention with this wireframe enabled and large portions of your level that should not be being rendered are being rendered then hints will help. Otherwise, you may need to start cutting out faces, inserting vis blocking objects and religiously using the null texture.
Hint <u>cannot</u> replace sensible mapping though. You simply need visblockers ('visibility blockers', as in, WALLS between rooms).
gl_wireframe 3 is a godsend for this. I bound my pageup button to gl_wireframe 3, and pagedown to gl_wireframe 0. With this (and sv_cheats on) you can walk around your map, hit pgup and see exactly what is being drawn, because you'll be able to see the wireframe of it through the wall.
There's a nice HINT tutorial <a href="http://twhl.co.za/tutorial.php?id=71" target="_blank"><u>here</u></a>, but frankly i'd say read that, try to understand the gist of it, and then go <a href="http://home.comcast.net/~ninjagrinch/pyramidhint.htm" target="_blank"><u>here</u></a>. That second link is for Pyramid Hints, which imo are far, far superior to regular hint methods, as they work much better and are easier to place. (once you 'get it').
i know how to put the hint brushes in simple rooms and corridors but i got something complicated <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
<img src="http://img01.picoodle.com/img/img01/8/6/4/f_helpmem_18d48ca.jpg" border="0" alt="IPB Image" />
What you need to do is cut faces out. this means minimizing face splitting as well as using pure awesome to pull polys out of the system. simplify everything. Every face and polygon is precious.
Also what are your r_speeds here?
*This is the approximate number of brushes shown, in standard yokel format
The halflife engine has huge issues with layouts like that. See the legs of your ship (I presume), allow visibility beneath it. This means the ship itself is doing little to block vis there. If you need the ship there, you need to make it work for you, not against you like that. For example: Instead of having the room being a huge box with a ship in it, make it like a dock setup. Raise the ground and lower the roof around the ship. Think of a boat in a dock. For an example of this sort of thing, go to the "generator area" on Shiva. The big "generator" thing is sort of sunk into ground and ceiling. Or another one is at circumm in Machina. Look at how the floor and ceiling have wrapped around the sphere thingie.
See, here's the problem. From the angle you took that screenshot you can directly see 3 sides of the ship, and from a long ways out no less. The engine will have a helluva time figuring out what <i>shouldn't</i> be visible and will likely render more than needed. No amount of hint brushes will fix that, because if you hint brushed for that view, and then move over 10 feet, those hint brushes won't be doing anything anymore. A complex structure like that, I wouldn't even touch with a hint brush because you'd need so many.
The fact that you've made it hollow (it appears) complicates things further. Don't think that people haven't tried to create dropships... heck, for every ship that has made it into a map (hollow or otherwise) I bet 20 have been scuttled.
Make the room smaller for start. Make it so that you can't see more than 2 sides of the ship at any distance. Bring the walls in around it. Imagine, a big U-shaped walkway all around it that the shuttle parks into. You may yet have to reduce detail, or create models to replace the details instead.
Either that, or move to the source engine!
before you even are going to toy with hints try OPTIMIZING your brushwork. we explained it when with the
chairs, but you did it again.
I'm going to post two screenshots (after and before) for example. that'll better do, because there's tons of similar hick-ups like this one.
like we said, "plzzzz" don't let two cylinders touch eachother. it'll end up just a mess as the engine starts cutting them into piecews. leave one unit of space between them and this goes for every other detail brushwork too.
you really should grasp the "clever" mapping style before trying to magically fix all flaws afterwards with hints.
before:
<img src="http://uffo.wanha.org/maps/noes01.jpg" border="0" alt="IPB Image" />
after:
<img src="http://uffo.wanha.org/maps/noes02.jpg" border="0" alt="IPB Image" />
On the left are 2 squares that look absolutely identical. On the right you can see they are made differently. One saves lots of compile time and fps as well as texture memory, the other doesn't. Can you tell which is which and why?
<img src="http://www.uklanparty.net/uup/Soulrider_Hammerbox1.jpg" border="0" alt="IPB Image" />
Box 1 is made using the clipping tool to trim off the edges so the walls align, this means there is no leaks and we have reduced the amount of visibly textured units.
Each block is 128x128 and the walls are 16 units thick. So the inner textured square will be 96x96. Easy so far..
When you texture box 1 you will use a 128x128 texture to cover each of the external walls. This will be exactly the same for box 2, so there is no saving there. The benefits can be seen when it comes to texturing inside the box...
In box 1 you will need to texture each of the four inner walls with a texture of 96units wide, by 128 units deep. The angled joins are not textured at all as they are not visible and do not count towards vis, so they are not in the vis compiler, and thus do not get rendered in the game.
When you come to texture box 2's inners walls it's a different story.....
<img src="http://www.uklanparty.net/uup/Soulrider_Hammerbox2.jpg" border="0" alt="IPB Image" />
Now you can see that there are 2 overlapping walls. This causes a problem, because now when you texture the inside you have 2 walls that will be textured 96x128, as in the first example, but the other 2 walls will be textured 128x128, and although these walls cannot be seen they will be compiled and drawn, as they have a texture on them.
So in this little 128x128 box room with no wall or floor, we have a total unit texturing of
Box 1 = ((128x128)x4)+((96x128)x4) = 114688 textured, compiled and rendered units
VS
Box 2 = ((128x128)x6)+((96x128)x2) = 122880 textured, compiled and rendered units.
So in this little example we have saved the engine 6.66666*% of it's workload. While that does not seem a lot, it does make a hell of a difference as you work your way through the map. This is one of the simplest ways to make sure you don't run into issues like you have. Working wisely as you go saves you so much time trying to correct errors at the end. Prevention is always better than trying to cure, and so much less work....
Making sure your brushwork is correct means you can get a much more streamlined map. There are lots of other issues with vis that you can learn, but start mapping right, and all the rest will be childs play.
With the images you have posted above, and as people have already mentioned, you have way too much visible at one time, the engine is having a fit trying to cope. what you need to do is make it so less is visible at any one time, hint brushes will never work in that sort of room, because there is no portals/corridors to use them in. Make your dropship in it's own confined piece of the dock if you do not want to lower the size of th dock itself. Unfortunately I can't give you any examples of what to do as I only have the source hammer editor installed now, i hvae given up trying to learn HL1 mapping when it is going to dissapear in a year or two, much better for me to learn the new source mapping way ready for NS2...
There was a whole debate about this on another forum about a year ago when i brought up exactly this topic (its been in many tutorials). The only thing that ended the debate was solid proof, which was easy to make given the controlled environment of Hammer. Try it out.
Here are the options, including the two you showed. I now opt for the third.
<img src="http://img374.imageshack.us/img374/4091/corners7eu.jpg" border="0" alt="IPB Image" />
I go for the bottom because i find that its the most 'rounded' method. You get perfect alignment, with quick mapping. Angling corners like that takes time, and gets a little crazy when its the corner of three separate brushes (instead of a corner like the one pictured, picture the corner of a cube).
And it in no way causes leaks. Again, think of the corner of a cube. Thats the corner of every room in your map. Did you really make a 3 dimensional angle on EVERY brush for EVERY corner or your map? Jesus <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
P.S. and big senx who helped understand lot of things.
and yesterday get drunk because i understand that month of work whit my drop ship is totally in toilet and i need to make it simpler. thats sad <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
For me, I find that the bottom one works the best, by far. Someone could try to prove me wrong; if they do, i'll probably switch my method.
I actually created about half of Nexus (so like 4000 brushes) before i came to this realization and switched my mapping technique. Its was kinda funny, because the newer rooms looked way better in-game than the older ones, and also had obviously different mapping techniques used (an example of which is exactly in that picture; i had been using the first method).
But its all for different situations as well. I use the bottom method for all world brushes; the brushes that are on the outside of your map. If you want a corner, but the players will be able to go on both sides? Then yes, the 2nd method is superior than either of the other two (the bottom would look odd, and the left would create more work for texture alignment... though possibly less work than it would take to actually use the right method... interesting <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />)
<!--quoteo(post=1631389:date=Jun 5 2007, 10:59 AM:name=Skyforger)--><div class='quotetop'>QUOTE(Skyforger @ Jun 5 2007, 10:59 AM) [snapback]1631389[/snapback]</div><div class='quotemain'><!--quotec-->
and yesterday get drunk because i understand that month of work whit my drop ship is totally in toilet and i need to make it simpler. thats sad <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
Aye, the alcoholic comes out in every mapper now and then.
Perhaps the best piece of advice i can give you as a mapper; NEVER worry about completely deleting entire sections and starting fresh. Theres a few reasons. First off, you DID make the first, and in doing so, you <i>became a better mapper</i>. Mapping is all about experience. I bet if you were to remake that room, you'd do it a whole lot faster now.
Second, when you remake an area, generally you create something that it a lot better. You have a better grasp of the size of the space you're using; you understand what worked well (and kept it) and what didnt (and replaced it); and you're simply a better mapper by then. Mapping is ALL about experience.
So go ahead, ditch the drop ship. Not really ditch, since you can always keep the file. But start afresh, knowing the lessons you've learned, and create a wicked drop ship that can actually work in-game. Keep us posted <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
I do that vith evey vertical join, for the roofs i just join in the old fashioned way... that's why i didn't include them in the example.... <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
I have used your method previosuly, but kept getting odditites and leaks where there were no gaps, so i stopped using it, but if you've used it without problem, then keep on with it...
One; you zip your .rmf. I had insane problems with Nexus for awhile (unrelated to this technique), and was zipping it and sending it to a mapping friend who was trying to help me. It was zipped, sent, unzipped, worked on, zipped, returned, unzipped, about 100 times. After all this i got some curious leaks, which i eventually found, but it was there an untouched brush had one edge move 1/10th of a unit, causing a leak (since my method needs to be EXACT... which the grid usually is). But the few leaks were found and it was fixed.
The second is with weird angles. Maybe you have a straight hallway, but the hallway turns on a 30 degree angle, and there's a step up to that angled hallway. In cases where its a weird clip angle, i just fully cover the bottom brush instead of trying to make them both on that weird angle (dont know if that was explained well).
Anyways, everyone for themselves <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />