It’s been in trailers, so it’s no spoiler to say that Portal 2 has some pretty cool new mechanics; a lot of them are related to various gels that can be spread across surfaces in order to convey a number of interesting properties.
While I thought all the gel effects looked great, I had a weird hitching performance issue whenever there was a lot of the stuff flying around. To be clear, the rest of the game was running smooth as butter, the hitching only occurred when the gel presence was thick.
I heard a developer commentary on the gels and the challenges faced when trying to optimize the code to work on the Xbox 360, and how it was easier on the PS3, because the blobulator threads could be passed off onto the SPU. This had me thinking that maybe my ageing Core 2 duo just didn’t have the cores required to process the calculations effectively. I also read from others experiencing this issue that dropping effects to medium fixed the hitching, and while this was true for me, that also reduces other areas of detail I was having no trouble with. I needed to just optimize the Blobulator, so off to the developer console I went.
The two most important commands I discovered were
“r_paintblob_max_number_of_threads” = “4” ( def. “4” ) client – Indicates the maximum number of threads that will be spawn [sic] for the blob.
“r_paintblob_highres_cube” = “0.800000” ( def. “0.8” ) client – Set cubewidth (coarseness of the mesh)
It’s worth noting that there were a ton of Blobulator related errors filling up the console as I stood in front of a glorious gel stream.
Threads and Meshes
I thought dropping the threads to 2 would be sensible, given that’s the number of cores I have, but no dice. The way threads are handled must be more complex than that, or it simply expects to be able to use 4 threads if it’s going to do any threading. Anyway, dropping the max number of threads to 1 totally worked! Yay! No more hitching! Except now the framerate was bad when looking at gel. Boo!
Because I had taken out threading, the calculations were simply too much for the CPU to bare, so by increasing the highres_cube value, I was able to achieve 60FPS no matter what. In fact, I only had to increase this value to 0.9 in order to get a stable framerate at all times, and the impact on blob quality was negligible (as a side note, the medium effects setting increases this value to 1.4, which is much more noticeable).
So there you have it. I’ll list my PC spec and the commands used here for reference.
- E6750 Core2 Duo 2.66GHz
- 8GB 1066MHz OCZ RAM
- Radeon HD5870 1GB
- Seagate 7200.12 1TB HDD
That’s all the important stuff, right? Now the commands.
It seems as though the config file used is packaged into the Portal 2 executable, and I haven’t seen a way to get the game to boot with an alternate configuration, so it looks as though you would have to enter these commands every time you start the game. I find it’s a pretty good tradeoff for the ultra smooth and optimized experience. Also, just have a play with the commands in the console while you’re there and experiment with the other crazy hidden-away features.