Epolies and models

Do custom models (no matter what size) have the same epoly count? I don't think they do, but, what is a good way to measure their epoly count and determine how many you can get in a map without having the epolies skyrocket?

I figure using r_speeds 1...but is there another way to read the epoly count, say with a model viewer?

Also, how much does the engine see when reading epolies? Does visblocking even effect epolies, or does the engine see the whole map no matter what kind of visblocking there is?

What is the general max-accepted limit for epolies in a multiplayer map? 8000?

Thanks

The amount of polies on a model can vary hugely, and the only way I know of to measure them is to use r_speeds in game. However I guess model viewers may well have poly counts viewable, I'm not overly accustomed to using models in game so its not something I'm too familiar with. If the model came with a readme it may well state how many polys there are, its very easy to get a poly count from a modelling program so the modeller should really put this in the documentation. And god, I really ought to know the recommended epoly limit, but i dont :biggrin:

visblocking will block them assuming a compile is not defective..

to my knowledge, the only thing that fails to be blocked by a good compile and visblocking is really large func_?'s

so yeah, visblocking will work, provided its a proper visblock.

[edit]recommended, thats as subjective as wpolies.. i say 10,000 or less, but.... i have seen other replies.

Generally solid entities are not VISblocked quite as well as world brushes, and if they get really large VISblocking can fail altogether. I'm not sure how this would apply to a model though - technically that's a POINT entity in the editor. The only experience I have is of my boulder model, which is teleported way out of the map when not in use :sad:

Given that models (cyclers) are point entities, it's possible that really huge models might "flicker" in and out of visibility - that is to say, if the engine cannot see the VISspace that contains the centre point of the model, then it probably won't draw the model at all!

func_waters seem to be drawn no matter what from my experience. Maybe that's just me though :smile:

Adam Hawkins said:
func_waters seem to be drawn no matter what from my experience. Maybe that's just me though :smile:

should be dependant on size and quality of vis compile, i have had no issues myself :/

i suppose we could load a few high quality maps, with large waters in them and see?

also something many people forget, you can scale up a water texture pretty damned big and it still only looks like water, most have massive quantities of small shapes because they never upscale.

In dm_rampart, if you enable gl_wireframe, you can see that the engine is drawing the small 'circles' of water in the wells, which are in no way visible by VIS unless you are in the same corridor as them. The engine can still see them even if you stand on the bridge, which is a fair distance from the water.

On a side-note though, if you make the water's render properties so that the texture is completely transparent, the water is not drawn by the engine (though you can still see the water/fogging effects if you enter it). It's just the surface that's drawn, and i've also noticed that the scaling up of the texture does nothing to reduce the w_polys in it - it's always chopped up at the same scale - which is probably due to the wave properties. Though having a wave height of 0 still chops it up small.

Bit of a swine really eh? :smile:

If you take a water texture, and remove the ! (or whatever key it is for a water texture), and then make the brush a func_illusionary with contents of volumentric light, you'll get the feeling of being in water and the ability to swim in it.

It will all be rendered as one entity, too, and you'll be able to scale up the texture.

Only bad thing is that the surface of the water won't have the movement like a normal water texture...

btw...anyone have a rainbow.spr or seen one?

Personally I prefer non-moving water, because unless it's set really high it doesn't look really good, just looks amature. Doc, about the epoly and wpoly limits I remember seeing a chart that had comparisons...so for example (but probably untrue) that if you had a wpoly of 100 or something you could have a much higher epoly (10,000). Generally I've found that 800 wpoly and 5500 epoly is a good limit to go for. It's not always possible to keep under that, but I find that if you get too high in too many places it destroys the gameplay for unreasonable reasons. Sometimes it just takes a little optimization. I saw a map in the TS forums and someone had 1300 wpoly/3000 epoly or so...someone took the map and optomized it to just under 1000 wpoly and 2000 or so epoly just by changing certain scales and making brushes in better ways.

And be sure to remember that any brush or brush based entity is adding to wpoly not epoly. Models (and gibs which are also models) are the only thing that effect epoly.

DocRock said:
btw...anyone have a rainbow.spr or seen one?

here u go. 5 mins work in psp and sprite wizard.

www.invalid-brush.co.uk/files/rainbow.spr

rendered with additive fx

Thanks Fishy!

the sad part about this thread is, its not all editing, or general..

how would one classify a thread on epolie counts?

and with no clear winner, will this thread go into the search base lep?

i think epolie use is an editing question, but i am iffy on the counts issue

Ultimately all classifications must simplify and hence sometimes misrepresent that which they describe :/

Gollum said:
Ultimately all classifications must simplify and hence sometimes misrepresent that which they describe :/

yeah i know, but sometime soon, another member will ask this again, i was curious, will it show up in the search without a clear winner..

oh well..

This problem also happens whenever someone asks too many things in one post, or has one of those "....and another thing" threads.

we discussed this a while back guys, don't you remember? I think 5000 was about what valve had said, to leave room for ingame player models and effects and gibs etc.

the problem we ran into was that after a certain point you might have an okay 'framerate', but you would get rendering lag from the ancient game engine.

Jinx said:
we discussed this a while back guys, don't you remember? I think 5000 was about what valve had said, to leave room for ingame player models and effects and gibs etc.

the problem we ran into was that after a certain point you might have an okay 'framerate', but you would get rendering lag from the ancient game engine.

we did cover this topic jinxy, in V3.. this is V4, i am trying to make sure it gets in the search base is all :razz:

Gorbachev said:
Personally I prefer non-moving water, because unless it's set really high it doesn't look really good, just looks amature. Doc, about the epoly and wpoly limits I remember seeing a chart that had comparisons...so for example (but probably untrue) that if you had a wpoly of 100 or something you could have a much higher epoly (10,000). Generally I've found that 800 wpoly and 5500 epoly is a good limit to go for. It's not always possible to keep under that, but I find that if you get too high in too many places it destroys the gameplay for unreasonable reasons. Sometimes it just takes a little optimization. I saw a map in the TS forums and someone had 1300 wpoly/3000 epoly or so...someone took the map and optomized it to just under 1000 wpoly and 2000 or so epoly just by changing certain scales and making brushes in better ways.

And be sure to remember that any brush or brush based entity is adding to wpoly not epoly. Models (and gibs which are also models) are the only thing that effect epoly.

Epoly limits, violations of combinations can cause lag
by Chris 'Tal-N' Blane from the 69thVlatitude forum

100 wpoly + [x100] 10,000 epolys
200 wpoly + [ x45 ] 9000 epolys
300 wpolys + [ x25 ] 7500 epolys
400 wpolys + [ x15 ] 6000 epolys
500 wpolys + [ x10 ] 5000 epolys
600 wpolys + [ x8 ] 4800 epolys
700 wpolys + [ x6 ] 4200 epolys
800 wpolys + [ x4 ] 3200 epolys
900 wpolys + [ x2 ] 1800 epolys

I believe this is the list you were talking about.

Looks like it. My dod_cliffside map follows that chart, 550 wpoly and 4850 epoly at max that I could find.

Bruce said:
Epoly limits, violations of combinations can cause lag
by Chris 'Tal-N' Blane from the 69thVlatitude forum

100 wpoly + [x100] 10,000 epolys
200 wpoly + [ x45 ] 9000 epolys
300 wpolys + [ x25 ] 7500 epolys
400 wpolys + [ x15 ] 6000 epolys
500 wpolys + [ x10 ] 5000 epolys
600 wpolys + [ x8 ] 4800 epolys
700 wpolys + [ x6 ] 4200 epolys
800 wpolys + [ x4 ] 3200 epolys
900 wpolys + [ x2 ] 1800 epolys

I believe this is the list you were talking about.

if this is the answer to docs question, make it yellow, so he can score it, that way it will enter the search database..