Hi,

I have some doubts regarding the use of func-wall to decrease wpolygons-related to rspeeds.


1. Supposing that I have build up a series of rubble packs, each pack contains 10-20 brushes. I have the choice to either set a rubble pack 1 unit higher than ground and leave them as individual brushes (in this case they will be calculated as brushes),
or select the rubble pack and build an entity (func-wall).
My question is, the 10-20 brushes will be considered then as a single entity? or they will be considered as 10-20 individual entities?
What if I group first the 10-20 brushes and then select entity func-wall? Will it be the same?

2. If they are func-wall entity, then they can touch the ground, but can the func-wall entity partially be covered by a world brush? Just like the flags. Will it matter at all?
Thanks
miopalmo

1. Yes, they will be only one entity. Just remember that if you can see one of the brushes all of them will be drawn. Grouping doesnt matter at all outside hammer, its only a hammer function to help to keep track of things inside hammer.

2. Yes again, its no problem to have a func_wall entity intersect with a world brush. Its when 2 worldbrushes intersect you will get a problem with the engine spliting them into smaller brushes which gives more wpolies .
As I said in 1, if you can se some part of the brushes, all of them will be drawn so haveing somepart hidden by the world brush shouldnt be a problem...

Kehldon, Thanks for your reply, here are a couple of things which i still don't know:


1. 10 brushes set as 1 single func-wall entity, if player sees one, the rest 9 will be drawn by the engine. This will then have repercusion only in:
e polys: an addtional 1 since the 10 brushes constitute a single entity.
fps (lower),
i think i am correct.(?)
The only problem is then reaching the maximum number of entities permitted-recommended in dod (how many?).

2. A player model contributes to a SINGLE player model, or does it contribute to player model+weapon+more? Supposing that a map is set to be played by 32 players, we must always count with 32 entities, 64, more?

Yeah, you are correct. They func_wall brushes will contribute to the epolies and will lower the fps. In most cases its not really bad but since you were asking I thought I should tell you.... some people get crazy ideas like combing all the func_walls in the map to one single entity and totally forgeting about the drawing of epolies... but combing your 20 brushes shouldnt be a problem.

I usually look at my map and if I think the players will se them all at the same time anyway I combine them into 1 func_wall.

When it comes to entity counts i think the players entities already is reserved by the compiler so you dont have to worry about that.

As a mapper you can probebly use a few hundred entities without problems, I have never had a problem with to many entities anyway---

You can read some more about it here if you are really intrested in it. http://www.slackiller.com/tommy14/errors.htm#entlim

Dunno exactly the maximum count of entities. Take a look at the compile log, you'll find a "Entdata" percentage. 100% is around 900 point-entities + brush-entities. More than you need for a standard map...

is there an aditional command line to display the entdata? its not in my compile logs

right but for one thing kehldon.

e_poly is models.
w_poly is world, brushes or entitys.

compile a map and try. The reaosn its good to use func_wall is because it cuts down on VIS+RAD compiling and also cuts down the BSP compile, it also drops w_poly when placed right. all because an entity takes less data if you use the "null" texture on it properly.

For DoD, it's usually best to keep the combined (point+brush) entity count around 500 or fewer.

Also, remember that brushes within the same entity will break each other up if they intersect. If two separate entities intersect it's fine.

Hi again, let's see if I can get it. The lattest comments start to make this more complicated.

1. Whenever it is possible, convert world brushes into entities (func-wall), avoiding need of plcing world brushes 1unit higher than ground and decreasing number of wpolies.

2. 1 is correct until you reach a number of certain epolies in a map and in a room-hall. For a map it may be considered (copypaste from http://www.slackiller.com/tommy14/errors.htm#entlim

DoD is now talking about 400-500 as the playing map limit of total entitys!

From the "Entdata" percentage in the compile log around 900 point-entities + brush-entities.

No matter what you do decreasing wpolies, epolies afect in any case the final fps.


QUESTION

Angry Beaver
"an entity takes less data if you use the "null" texture on it properly"


-iNw-Andy
"brushes within the same entity will break each other up if they intersect. If two separate entities intersect it's fine."


Consider the picture

It shows two columns, the left case taking the 3 brushes i guess is not the ideal case since they are touching, Is this correct?

The null texture correctly applied means that ALWAYS put special care for entities to apply null texture to everything that is not seen by a player. Shouldn't this issue be always important for any brush? What does correctly null texture application for a func wall entity mean?
Thanks in advance

miopalmo

I would have gone with the right selection but I think its optional in that case.

When it comes to null texturing you are right, always use null on all unseen sides, entity or not.

func wall helps R_speeds mainly by reducing brush "shattering". it hurts r_speeds because all faces are rendered even if not "seen" at the moment....unless they are NULLED.

but func wall also helps VIS compile right, and faster.

NULL texture helps entity brushes AND regular brushes r_speeds. it is not for func wall alone.

so the consideration for func walling is:
1. will it reduce shatter?
2. can i afford to use it to make the area less complex for VIS? (ie stairs, or a chair/table/bed, or pots, ect.)
3. do i need it for the invisible texture of the model sound effect?
4. should i leave this brush regular because it is big enough to block line-of-sight?

try to keep func walls into one entity within the same "room". this reduces your entity count problem, and everything in the same room is generally rendered anyway, so you might as well make it one func wall.....