HL2 Map Design Question: Brush or Mesh?

    Another question, OT I guess, but it's still Source related. I read that textures need to be powers of 2. Is that an iron-clad rule? If not, what is the effect of breaking the rule? A somewhat related question, lets say you have a 512x512 unit set of brushes. You can either make it one brush with a 2048x2048 texture or 4 brushes with 4 512x512 textures. In that situation, what would be the wiser choice. That's more of a general question has to how Source handles geometry and textures in relation to performance I guess. Thanks again.

    -Dranore

    I think I can answer one of those questions ;

    textures do not need to be in powers of 2, but making them in powers of 2 will make the texture smoother and just look nicer ingame.

    If you have a texture which isnt in powers of 2, it will look grainy/blurry/crappy ingame, because of how the engine does

    I hope that helps

    Actually in HL1 a fully visible 256x256 texture is 4 polies. Slice 16 "pixels" from each side and you got 1 poly.

    Will HL2 work the same way? How does this apply to 512x512 textures and so forth? 32? 64? etc?

    yes, you cannot even compile a texture without it being a power of two. As far as 4 512's vs one 2048 . . . therey would probably be about the same . . . as far as the 256 texture being 4 polies thing, I don't know, I have never noticed or taken a close look at something like that.

    what?

    just make a 256 x 256 brush and fit a 256 x 256 texture onto it and it will split into 4, one big one in the lower left and three smaller ones on the right, top and upper right.

    240 x 240 bottom left

    16 x 240 top

    16 x 240 right

    16 x 16 top right

    nub

    By doing this you can do miracles with r_speeds just like 3d-mike has done in his maps. I managed to reduce my r_speeds by up to 250 in some parts of ts_antrodome.

    So since everything works similary in HL2, ya can probably do some faptastic r_speed reductions using this technique.

    Quote from -Stratesiz-

    By doing this you can do miracles with r_speeds just like 3d-mike has done in his maps. I managed to reduce my r_speeds by up to 250 in some parts of ts_antrodome.

    So since everything works similary in HL2, ya can probably do some faptastic r_speed reductions using this technique.

    Err I didn’t really say how to do it but, for those who didn't know, basically 3DMike used it on boxes and a few other things.

    He’d make a, say, 256 x 256 box texture. The bottom left 240 x 240 would be the box texture while the rest was black, he’d then make a 240x240x240 brush and apply the texture scaled by one to the bottom right of each face. This made only 240 x 240 pixels show on each face of the box; that would remove the three polies I mentioned before from each face. Three polies from each side, five sides show, that’s 15 saved polies.

    The crowds go wild for the 15 polies per box.

    If you went crazy you can make walls using 240x240 sections of 256x256 textures, just chop the wall up into sections and only show the 240x240 part of the texture. The only problem with this method is a bit of texture bleed which can be helped by not using a black background and just stretching out the edge pixels all the way to the end which should eliminate most of the seam.

    :^)

    with the acceptable range of world polies being what it is in source, putting that much work into saving a few polies for this quirk in the engine would be negligible and a waste of time.

    Quote from Zaphod

    with the acceptable range of world polies being what it is in source, putting that much work into saving a few polies for this quirk in the engine would be negligible and a waste of time.

    So does Source still cut every 240 units, or is that simply a prequisite of BSP-based games?

    I tried to do a quick test, and it seemed like it would not consistently cut at 240, sometimes I could get a 256 face with 2 polies, sometimes it would cut it. I don't have the time right now to test it out any further.

    yea, I'm sure it was for a variety of reasons, probably to try and make vis information more accurate mostly. Hovever the engine uses portals for more than just calculating the PVS, for instance - sorting 32 transparent textures. If you have two 32 bit transparencies in the same leaf, often times the sorting will be incorrect, the engine sorts them by which leaf is closer to you. I have had a lot of instances where I would have to correct sorting issues by hand by putting a hint brush to make a bsp cut between two transparent objects.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login