Maxnodesize rspeed tweakage

I posted this on the TS forums for someone... since I went to the effort of taking some comparison screenies I thought I would post it here again as well just for the hell of it.

<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
Using the "-maxnodesize" parameter in hlbsp can significantly lower r_speeds on some maps. I am not sure precisely how it works, but it seems to effect how your map is broken up and thus how it is VISed.

The default setting, ie what it is if you specify nothing, is 1024. I find that for maps with huge, open area 4096 sometimes works best. For maps with smaller areas, where you want less 'bleedover' between areas, -512 seems to work best. It is best to experiment with different values, though, to see which works best. This setting will effect different parts of the map differently, so see which is best overall, and/or lowers speeds where help is most needed.

[thanks to Banana for teaching me this one]

[/quote]
I wrote that a while back... generally I find 512 to be the best setting, seems to make the VISing more accurate or something. But your milage may vary, sometimes the default 1024 is the best anyway. Someone told me changing the maxnodesize didn't work so well with hint brushes, but it didn't cause me any issues.

I took some screenies to show the effects of this parameter, they are in this directory:

http://www.cryotank.net/remote/maxnodesize/

These were taken from 2 different bsps, each from the exact same .map, but compiled with a different maxnodesize settings. You will notice a 100-200 wpoly difference between the pics in each set. Note that in one case the '512' pic actually has -higher- rspeeds. This is in a low-traffic area, though, and since 512 seemed to lower speeds overall in the map I chose to use that custom setting for the final compile.

Like I said... it's something worth trying on your map, since sometimes it lets you get a good rspeed reduction with almost no effort or changes to the mapfile itself.

(I would have included the screenies in the post, but they are 1024x768 and the rspeeds aren't legible if I reduce them since I forgot to add the new font wad last time I installed AHL.)

cool, even after so long, new discoveries still occur..

good job jinxy

i might add, if you know you are going to post screens here, change your resolution in advance of taking the screen shots.. it will eliminate the need to resize them, thus guaranteeing clarity for posting images..

since i did dozens of critiques, it was something i found necessary.

/ 2 cents

well, I used to have a larger font installed, which eliminated that problem. just forgot about it.

The -maxnodesize parameter refers to how many triangles go into each leaf node of the BSP tree. When the engine goes to find out which geometry to render, it goes to the leaf nodes first, since that's where all the renderable geometry is stored. From there, the engine goes through the vis portals to narrow down the geometry to render. Then it uses the View Frustum to cut down the number even more, so only geometry that's directly in your view is rendered. Then it does occlusion culling to remove geometry that isn't backface culled(openGL, D3D take care of this automagically) but still inside the frustum that can't be seen. Once it has all of that, it sends it down to the final rendering area, where it's put on a backbuffer, and when that frame is done, it does a very quick buffer swap with the display buffer and POOF!!! You have a rendered image. Sounds like a lot of work, but thankfully 90% of the operations are dirt cheap on both the CPU and graphics card.

Playing with the -maxnodesize is something you just have to go by trial and error. If you decide to understand how a BSP tree is created, you might get a bit more insight on where to start. Basically, the dividing drops off triangle candiates really quick, and then you'll get to a point where the triangle count slowly climbs back up.

Edge Damodred said:
The -maxnodesize parameter refers to how many triangles go into each leaf node of the BSP tree. When the engine goes to find out which geometry to render, it goes to the leaf nodes first, since that's where all the renderable geometry is stored. From there, the engine goes through the vis portals to narrow down the geometry to render. Then it uses the View Frustum to cut down the number even more, so only geometry that's directly in your view is rendered. Then it does occlusion culling to remove geometry that isn't backface culled(openGL, D3D take care of this automagically) but still inside the frustum that can't be seen. Once it has all of that, it sends it down to the final rendering area, where it's put on a backbuffer, and when that frame is done, it does a very quick buffer swap with the display buffer and POOF!!! You have a rendered image. Sounds like a lot of work, but thankfully 90% of the operations are dirt cheap on both the CPU and graphics card.

Playing with the -maxnodesize is something you just have to go by trial and error. If you decide to understand how a BSP tree is created, you might get a bit more insight on where to start. Basically, the dividing drops off triangle candiates really quick, and then you'll get to a point where the triangle count slowly climbs back up.

probably the best explaination of the whatchama that i'll ever read. and i'm still none the wiser

Edge shows off his excessive knowledge of game engines - DRINK!

You have to hand it to him though - he didn't mention Full Sail even once in that post :heee:

FULLSAIL FULLSAIL FULLSAIL FULLSAIL FULLSAIL FULLSAIL

Actually I've spent the last 2 months researching bsp and octrees for my own personal interest and for my final project.