Node size 64 ... increasing wpolys? Created 12 years ago2012-05-03 17:35:31 UTC by smellycat

So I'm really at the point where I've optimised my map a load and trying to eek the last few wpolys out of each area.

Anyway, I saw the node size 64 suggestion around this forum and while it reduces the wpoly count in most areas of the map on the outside of my base (looking in) & at the back of a big flag-room the wpoly count is actually higher than 512 or 1024 compiles. It's only a difference of ~10% but where these are my highest wpoly counts (of about 1,100-1,200) in my map I don't really want them to go up any higher.

So my query: why on Earth would a compile with -nodesize 64 give a a higher wpoly in some areas? Seems totally counter-intuitive.

Thanks again,
Jord

It creates more cuts, so in a large open area it would create much more poly.

Use 512, or if really needed use 256. (From my experience)

I see. Only noticed it having changed my architecture inside to stop VIS having to draw so much - the outside area is quite vast so this makes a lot of sense, thanks.

I'd somewhat decided somewhere between 128 and 512 was optimal, depending which areas I wanted to have the lowest wpoly but it's clear to see why now you've said it.

I've noticed that too and I can't explain it. I use nodesize 128, and it seems to me to do justice. I don't think it cuts up the map, and I can't explain why it is higher in some cases. This is my understanding of nodes and node sizes.I may be wrong though.

keep in mind that the default chop size is set to 240. i haven't actually tried 240 as a node size, and I wonder if it matches up if it would actually provide better or more accurate results. The chop is also scalable with texture scales. Which is why a large wall can be 12 wpoly and not 2 like anything smaller than 240, but the same wall with a scaled up texture can be 2. You can make enormous rooms if you scale the textures up. (See Alpestrine, or CP Sancefar) Changing the chop size crashes almost everytime so never change it, its an engine thing.

I would leave the nodesize at 64 if I were you. I am no expert but it looks like to me that w_poly isnt the necessarily the main concern with vis leaf size. The smaller the node size the easier it is for the vis lower the amount of space a player can see, regarless of the w_poly. The amount of w_poly is not as important as the amount of entities being cut out. It isn't my understanding that node size affects the actual cutting of brushes, just vis leaf cutting. Default chop size cuts to the variable you set it at, so if its at at 240 then every 240 units there will be a cut all the way across the map vertically and horizontally. If you brushed around that number using like 240 unit wide hallways and such you would more efficient/optimized than not I guess. I set mine to 256 so that it links up with the grid in hammer. I could not get it to go higher than 256 without crashing though.

ps- I'd think that hint brushes would get you lower than the amount of w_poly you'd get with a higher node size plus hint brushes.

pss- I'f node size did affect cutting of the map ( which I never read that it did) then you'd able to set the node size to something really high like 1024 or bigger and then do your own hint brushing and end up with way less node brush cutting....

"Sets the maximum portal node size.

This option tweaks the maximum size of a portal node. Setting it smaller will bsp the world into smaller chunks at the cost of higher r_speed values, but it can pay itself back in many cases with making vis either faster, or more accurate, or both."

damn presets.