Is this an insane amount of polys?

[K.I.L.E.R]

The need for lots of polygons is really important when you come to jungles. Lots of trees is hard, by lots I'm not talking about 10 or 100, I'm talking about 1000s (in view). IIRC we have around 70,000 trees in one (quite small) level. A good tree needs a minimum of 2000 polygons (I think we hit around 5000) and for such low poly trees you need alpha-tested foliage (if you wanted purely polygon trees, you would need 50,000?), even wih LOD (imposters etc) we still need 100,000 to 250,000 polygons per frame. Trees also burn fillrate like nobody's business, before adding a front to back sorter we were getting overdraw of 50+ per pixel.

Indoors is easy, outdoors is where it gets hard.... Brute force fails completely outdoors, I once calculated that to brute force render the worst view of one of the levels would take some thing like 22,000,000 polygons per frame....

Should I throw out my R300?

AFAIK 22M polys is far more than my R300 can do practically.
You think about just the trees taking up that many polys and the amount of bandwidth.
How will you render lighting, shadows etc... along with those trees over 1fps?

I realise the guy must have been messing around and isn't going to have that many polys in his upcoming game.
It's just that I find it fascinating that all those polys will eventually be full rendered and games will use more polys than that.

Add all the polys on the finished scene up I can bet you are looking at a couple of billion.

 

[DeanoC]

The need for lots of polygons is really important when you come to jungles. Lots of trees is hard, by lots I'm not talking about 10 or 100, I'm talking about 1000s (in view). IIRC we have around 70,000 trees in one (quite small) level. A good tree needs a minimum of 2000 polygons (I think we hit around 5000) and for such low poly trees you need alpha-tested foliage (if you wanted purely polygon trees, you would need 50,000?), even wih LOD (imposters etc) we still need 100,000 to 250,000 polygons per frame. Trees also burn fillrate like nobody's business, before adding a front to back sorter we were getting overdraw of 50+ per pixel.

Indoors is easy, outdoors is where it gets hard.... Brute force fails completely outdoors, I once calculated that to brute force render the worst view of one of the levels would take some thing like 22,000,000 polygons per frame....

Should I throw out my R300?

AFAIK 22M polys is far more than my R300 can do practically.
You think about just the trees taking up that many polys and the amount of bandwidth.
How will you render lighting, shadows etc... along with those trees over 1fps?

I realise the guy must have been messing around and isn't going to have that many polys in his upcoming game.
It's just that I find it fascinating that all those polys will eventually be full rendered and games will use more polys than that.

Add all the polys on the finished scene up I can bet you are looking at a couple of billion.

The key is not rendering via brute force, if you don't do LOD you couldn't display this kind of scene but with clever LOD (imposters for trees in the distance, quad tree terrain etc) its playable. Any engine that doesn't have serious LOD techniques, isn't going to be able to render good outdoor scenes. But with some magic LOD it all works, in a similar mannor the 150 Mb DXT1 texture we use for the ground texture wouldn't work brute force (I tried it once, for some reason my R300 didn't like 200+ Mb of texture in view, can't think why )

One of limitations is not rendering speed but storage, the next level up of a terrain texture generator would mean 1 level per CD....

 

[PC-Engine]

Looks like a job for a TBDR. 8)

 

[Arun]

Since when do TBDRs save geometry work?

The only way in hell to save geometry work is actually having some much more complex stuff. I've been thinking a little about it, and it nearly gave me an headcache seeing all the evyl limitations you've got. Either you reduce flexibility ( and that's not gonna happen now... ) or you got some very complex thingies.

What could help a LOT here, however, is a PPP. A very powerful PPP might be able to save you a LOT of polygons when more polygons are useless, and give you amazingly detailed objects when you're near them.

I'm not aware of the implementation details of the NV40 PPP ( remember that's the first one we're gonna see ) , but it wouldn't surprise me if they did think a little about letting you do that rather easily with it. Although the true question is whether they've managed to do it...


Uttar

 

[Ailuros]

Since when do TBDRs save geometry work?

Theoretically I could see only some sort of problem with vertex shaders or HOS for example in possible future TBDR's. A PS on a TBDR will not process any unseen surfaces at all AFAIK.

Not that early Z is going to help much with the two forementioned examples (**edit: VS, HOS) on an IMR, unless some sort of early object culling mechanism gets implemented in hardware.

 

[cybamerc]

What game is that? You have some very nice looking forests in games like Rogue Squadron 3 (GameCube), Fable (Xbox), Far Cry (PC/Xbox) and STALKER (PC).

 

[Arun]

Since when do TBDRs save geometry work?

Theoretically I could see only some sort of problem with vertex shaders or HOS for example in possible future TBDR's. A PS on a TBDR will not process any unseen surfaces at all AFAIK.

Yes, yes, TBDRs obviously save pixel work. But they don't save vertex shading work.

However, there are some very clever tricks you could do. And I'm sincerly suspecting the NV40 to use them. Some things just don't fit together otherwise... If the NV40 is what I think it is ( and I've got no proof at all ) , then ATI can say bye-bye to the performance crown until they actually get another architecture out of the door. Even a godly clocked R390 wouldn't save them then.

Please note that this is only if the NV40 is what I think it is. It could very well be very different, in fact my theory is quite unlikely, but if I'm right, well you got my point


Uttar

 

[K.I.L.E.R]

Uttar: Too much speculation can cause confusion.

 

[Tagrineth]

Kyro II SE's EnT&L, IIRC, is based on some kind of vertex culling.

 

[andypski]

Kyro II SE's EnT&L, IIRC, is based on some kind of vertex culling.

Interesting - perhaps you can cull vertices but it seems to me that you still need to run the portion of the shader that generates the final vertex position before this can be done - this can easily be the bulk of the shader in some cases. In addition, depending on the applied pixel shader an 'invisible' vertex can potentially produce visible pixels due to depth manipulation, which is a more general problem.

 

[Nebuchadnezzar]

What game is this? Sound like Far Cry.. :?

 

[DeanoC]

What game is that? You have some very nice looking forests in games like Rogue Squadron 3 (GameCube), Fable (Xbox), Far Cry (PC/Xbox) and STALKER (PC).

It hasn't been annouced yet. Its nickname (and initials) is PH.

 

[MfA]

Wether the pixel shader mucks about with depth is easily known, and it wont be all that common.

 

[Reverend]

What game is that? You have some very nice looking forests in games like Rogue Squadron 3 (GameCube), Fable (Xbox), Far Cry (PC/Xbox) and STALKER (PC).

K.I.L.E.R should've mentioned who and where he quoted this.

Link 1

Link 2

Both links are in our new "Developer" forum, right at the bottom of our main forum index page.

 

[Vince]

Didn't SA contribute a post around two years ago where he described a [region based?] deferred-rendering algorithm that used the temporal and spatial coherency in a scene to gain improvements in the entire pipeline and not just the fragment creation? I seem to remember him stating a complex jungle (or city) as a prime example.

In theory, using this coherency would seem to be quite ingenious if it's possible to avoid problems with the shaders and a dynamic enviroment.

 

[Ailuros]

Kyro II SE's EnT&L, IIRC, is based on some kind of vertex culling.

Whereby I haven't seen from the few public tests available any notable difference compared to a simple K2, apart from the apparently higher clock frequency and fillrates.

Vertex culling? I'd call them "optimized transforms" under very selected occassions; still just a software sollution.

 

[Ailuros]

Yes, yes, TBDRs obviously save pixel work. But they don't save vertex shading work.

Where did I say otherwise?

Yet no one says that some form of early object culling for example would be completely impossible on a TDBR and you ignore the possibility that PS from VS are perfectly decoupled, which is another nice plus for shaders overall.