I didn't noticed it before, but I am pretty much sure it worked ok in Steam some time ago.

r_speeds epolies in Steam show way higher values than in old DoD. On my map in WON DoD there is about 2500-3500, in Steam, same area/position - 9000-15000. Probably Steam DoD renders all models from whole map now :-\.

Steam renders mapmodels by their bounding box now and not just their origin.

Originally posted by Gorbachev
Steam renders mapmodels by their bounding box now and not just their origin.

Ok, so are you saying that Steam renders everything on a brush no matter if it is showing or not? And that WON only rendered what was showing?

Or am I just an idiot?

We're talking about env_models not entities. Brush based entities and all other entities still render/perform as they did before to the best of my knowledge. It's just that now if the entire bounding box (the big pink box in 2D mode around the model in Hammer 3.5 with the proper FGD) is where the model can be seen, so models are more frequently rendered as opposed to how the only part seen before was the origin (the little 'x') so previously you'd end up with times where if you crouched below a trench for example and there were trees out on the ground and you could technically see the tree still but WON HL VIS used the origin only and since the origin was on the ground it would stop rendering the tree model and you'd have it cutting in/out in front of your eyes as the game tried to figure out what you could see and couldn't see based only on the origin. As it is now if you could see the big box around the model and thus anytime you'd be able to see a piece of a model it'll be rendered. This causes strange things too though such as pieces of models rendering inside houses now because the box 'leaks' into it and you'll see some leaves or a chunk of hill in an area that technically shouldn't be. (1.1 merderet had this problem in the main area, the map was exactly the same, but because there was some hill near the axis side that had bounding boxes inside the centre it'd render a huge half of the hillside in the middle of the air. Which caused complaints from people who thought the map had all of a sudden bugged, which technically it didn't.

It doesn't render all, just that the size of viewable-ness is a lot larger so many more models will be rendered than previously.

i still get the massive hill by the merderet river bridge :/

And you would, because the .bsp is the same as before. Technically sturm is the update and successor so take that one as the update. Unless you felt like ripent'ing merderet for your own server and fixing it I highly doubt it's going to change. There's just no point.

Originally posted by Gorbachev
It doesn't render all, just that the size of viewable-ness is a lot larger so many more models will be rendered than previously. I know that Steam renders models by bounding box but this doesn't explain such huge increase.
But to be more specific, I am asking if epoly value gives any real (map wise) sense. It seems the it displayes some values from the roof and I can't judge if map is ok or not using it.

PS. Default maps has much worse values - dod_flash for example has over 30000 epolies in some places, 10000-15000 almost all the time (empty map, just me with Garand).

Maybe adjusting the $bbox value in the qc file to adjust the model's bounding box might help things. Unforuntatley, I tried adjusting the $bbox value on some models, but i see no difference in VHE. I doubt it can work. I think originally this 2000 epoly is gonna end up with 6000 epoly :( Gasp! This better not happen, please...Anyway, i'm recopying Steam back into my computer to test it out. So much for splitting my huge .mdl into multiple parts for optimised origin rendering, (where you only see 2-3 parts each time, not all 8 parts...and my origins strategically placed). Unfortunately, i think i'll end up seeing 6 parts now with this bounding box issue in Steam, not forgetting the leaks of models' bounding box through walls.

Sigh, all my fault. I shouldn't have mentioned about "bounding box" visibility. No wonder dod_merderet had that horrible error.

I mean i prefered origin-based rendering and even if there were issues of trees disspaering, you could always adjust the origin yrself (or get some modeller to do it) by recompiling the model to suit your needs. Origin-based rendering would have definitely saved cpu time as well since it only involves a single point, just like sprites.

Originally posted by Craftos
I know that Steam renders models by bounding box but this doesn't explain such huge increase.
But to be more specific, I am asking if epoly value gives any real (map wise) sense. It seems the it displayes some values from the roof and I can't judge if map is ok or not using it.

PS. Default maps has much worse values - dod_flash for example has over 30000 epolies in some places, 10000-15000 almost all the time (empty map, just me with Garand).

I'd advise installing and using the won version of dod for checking maps for epoly etc, it still works fine for testing a map for epoly/wpoly all I did was copy all sounds,models, sprites etc across to my won install and it worked fine for me.

Issit Steam-vs-WON related or DoD 1.1 vs DoD 1.0 related?

Please lemme know.

-- I have defineately noticed 1.0/WoN & 1.x Steam entity differences in compiled test maps, regarding lighting and env_models.

Seems that the newer steam versions have better control over env_models that are slightly mixed in between a solid brush that may cause it to disappear. (hopefully this is a soon to be past issue with hl2)

I test my maps for backwards 1.0 compatibility and noted that many models did NOT appear in-game while they DID in steam with no actual changes made to the map itself.

I noticed a significant epoly difference between the two, however, Steam versions get a much higher framerate (almost 20fps on my PC) compensating quite a bit for the increased epolies

I didn't really notice it when I was testing Density, I only used Steam, had it in LAN by myself and r_drawviewmodel 0 to make sure it was only the models in the map counting. It seemed pretty low/acceptable most of the map.

My comuter feels the hit a bit from the higher poly counts, with 3.1b or lower I got 100fps always. v1.0 I get 60-80 usually, and nowadays it tends to be 50-60. While that's still impressive for a GF2Ti it really doesn't have to be that way. I just wish there was an option or compile flag for Steam based maps to render by origin or by box and not just box.

I don't think such high epolies come from rendering all models. In flash there is no way so many models that make total of 32000 epolies.

I've not seen a count as high as some people claim in flash or sturm. It seems a bit high from my observations.