Snarkpit Forum Index » Half-Life editing » Epolies and models
Epolies and models
1
Post Reply
Quote
 Re: Epolies and models
Posted by DocRock on Thu Oct 16th at 12:43pm 2003

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

[addsig]



Quote
 Re: Epolies and models
Posted by ReNo on Thu Oct 16th at 12:48pm 2003

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 [addsig]



Quote
 Re: Epolies and models
Posted by Orpheus on Thu Oct 16th at 1:21pm 2003

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.

[addsig]



Quote
 Re: Epolies and models
Posted by Gollum on Thu Oct 16th at 1:49pm 2003

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

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!





Quote
 Re: Epolies and models
Posted by Adam Hawkins on Thu Oct 16th at 2:08pm 2003

func_waters seem to be drawn no matter what from my experience. Maybe that's just me though [addsig]



Quote
 Re: Epolies and models
Posted by Orpheus on Thu Oct 16th at 2:22pm 2003

? posted by Adam Hawkins
func_waters seem to be drawn no matter what from my experience. Maybe that's just me though

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.

[addsig]



Quote
 Re: Epolies and models
Posted by Adam Hawkins on Thu Oct 16th at 2:32pm 2003

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?

[addsig]



Quote
 Re: Epolies and models
Posted by DocRock on Thu Oct 16th at 2:41pm 2003

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?

[addsig]



Quote
 Re: Epolies and models
Posted by Gorbachev on Thu Oct 16th at 11:07pm 2003

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.

[addsig]



Quote
 Re: Epolies and models
Posted by fishy on Fri Oct 17th at 11:46am 2003

? posted by DocRock

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





Quote
 Re: Epolies and models
Posted by DocRock on Fri Oct 17th at 12:53pm 2003

smiley

Thanks Fishy!

[addsig]



Quote
 Re: Epolies and models
Posted by Orpheus on Fri Oct 17th at 1:13pm 2003

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

[addsig]



Quote
 Re: Epolies and models
Posted by Gollum on Fri Oct 17th at 1:23pm 2003

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



Quote
 Re: Epolies and models
Posted by Orpheus on Fri Oct 17th at 1:48pm 2003

? posted by Gollum
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..

[addsig]



Quote
 Re: Epolies and models
Posted by Gollum on Fri Oct 17th at 1:52pm 2003

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





Quote
 Re: Epolies and models
Posted by Jinx on Fri Oct 17th at 4:45pm 2003

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.





Quote
 Re: Epolies and models
Posted by Orpheus on Fri Oct 17th at 5:48pm 2003

? posted by Jinx

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

[addsig]



Quote
 Re: Epolies and models
Posted by Bruce on Sat Oct 18th at 7:47am 2003

? posted by Gorbachev

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.





Quote
 Re: Epolies and models
Posted by Gorbachev on Sat Oct 18th at 8:26am 2003

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



Quote
 Re: Epolies and models
Posted by Orpheus on Sat Oct 18th at 12:34pm 2003

? posted by Bruce

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..

[addsig]




1
Post Reply