Archived

This topic is now archived and is closed to further replies.

Troughput of Top 3D Engines

This topic is 5826 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, Could anyone tell me what is the troughput of "indoors" 3D engines, in triangles per second, nowadays? How many textured triangles are those [powerful] engines capable of spiting out? Also, I am aware there are two diferent things, a scene can have 500 triangles, but only 100 are currently in the field of view (fov), so, we are just rendering 100. (the remaining 400 could be behind the camera...) How many triangles (total) in a single scene can top 3D engines handle, and how many in the FOV can top 3D rendering engines render in real-time? Just so we newbie folks, slowly building our OpenGL engines know where our 3D engines scale in the scheme of things. Thanks to the guys that give me a straight answer, and not a "go search somewhere" answer. Have a GREAT year 2002, happy, bugless coding,

[Hugo Ferreira][Positronic Dreams][]
"Research is what I''m doing when I don''t know what I''m doing."
- Wernher Von Braun (1912-1977)

Share this post


Link to post
Share on other sites
I can''t give you an exact number, but I will tell you this: They have a lot less throughput than the cards are generally rated at. The problem is that once you start adding multiple different textures and such, batching data becomes much more difficult, and sending triangles individually instead of in groups is by far slower.

For numbers, generally it''s not too bad. I can do about 10000 triangles per frame at 80 or so frames per second on my GF2 GTS, which is 800,000 triangles per second. Of course I''m not doing the best job of batching the data either, so you could do better. If you keep your polygon count around 4000 or so polygons per frame you should be OK, although you can always push the limits to about 16,000 or so per frame before you start cutting off a large number of systems.

----------------------------------
AIM: IanWinsAgain ICQ: 60635592 TIM: FaceHat
FaceHat Software -- Wear the hat.

Share this post


Link to post
Share on other sites
The Senshi:

You should be getting many more than that on a GF2! - Have you tried running nVidias BenMark5 program (there are a number of OS, driver and mobo fixes which if not done cripple GF2s) ? - It''s a pure case of vertex cache optimised untextured strips, but you should get in the region of 14-15 million polys per second on that (I''ve tried it on a range of machines in the office - from 500MHz K6''s to 2GHz prototype Northwood P4s.

In "Pac-Man:Adventures in Time" we averaged about 20000 polys per frame, with vertex lighting for characters etc. All of the animation was done with the CPU so many of the buffers were dynamic, and the artists did a few things which prevented optimal batching (e.g. there were a few draw calls with less than 100 polys). That was with a full game going on, WMA playback, 3D sound (EAX, ZoomFX etc) etc

A slightly different version of the same engine released before PM:AIT with more optimal data, but still doing 100% CPU animation did 50000-90000 polys per frame at 60Hz. nVidia used the demo in some of their press releases (alien looking female with 3 coloured lights spinning round her - there used to be shots on Riva3D.com).

With totally optimal batching, and extremely careful use of dynamic buffers under DX8 I''d expect even more polys per frame. Our engine DX8 re-write is looking like its already beating our old DX7 effort without any optimisation - although we''ve not done any proper profiling yet.


One important thing to note though is "its what you do with them that counts" - you can usually produce much better results with clever texturing/blending/effects than you can with a few more polys. ISTR reading that a whole *level* in Quake2 contained on average 10000 polygons, but with the lightmapping and effects it looked a lot more detailed than it really was.

We''re working on a PS2 and GameCube game at the moment, and its an interesting dilemma for me - the artists want to know what the upper polygon budget is - what I''ve told them is about a third of what I expect the final optimised engine will be doing. Two main reasons:
1)its easier to ask them to add more detail later and still preserve the same framerate than it is to get them to optimise bits of detail when the game is slowing down.

2) I''m intending to use a very rich set of shaders/texture effects in multiple passes. Low polygon meshes with bump mapping, envmapping, per pixel specular, decals, Fresnel effects etc can make it look like theres 10x the polygon count.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
wow, nice Simon!
Are these programmers self-taught?
where do u guys work/live? London? in Europe, right?
If I was a medium 3D programmer, was there any chance
i could join your team? I''m just cheking arround
cause I want to go work abrod, even if in the beggining
i don''t get paid much...
I expect to have a 3DGL Chess game finished by March 1st...
I''ll build upon that engine until i get it suficiently
musteld up, while getting myself knowladgeable about 3D
stuff nowadays. I used to program 3D rotating cubes in pascal,
arround 1995... it took me a while to migrate to win32
programming, and now i''m paying the cost...

[Hugo Ferreira][Positronic Dreams][]
"Research is what I''m doing when I don''t know what I''m doing."
- Wernher Von Braun (1912-1977)

Share this post


Link to post
Share on other sites
quote:
Original post by S1CA
The Senshi:

You should be getting many more than that on a GF2! - Have you tried running nVidias BenMark5 program (there are a number of OS, driver and mobo fixes which if not done cripple GF2s) ? - It''s a pure case of vertex cache optimised untextured strips, but you should get in the region of 14-15 million polys per second on that (I''ve tried it on a range of machines in the office - from 500MHz K6''s to 2GHz prototype Northwood P4s.

In "Pac-Man:Adventures in Time" we averaged about 20000 polys per frame, with vertex lighting for characters etc. All of the animation was done with the CPU so many of the buffers were dynamic, and the artists did a few things which prevented optimal batching (e.g. there were a few draw calls with less than 100 polys). That was with a full game going on, WMA playback, 3D sound (EAX, ZoomFX etc) etc

A slightly different version of the same engine released before PM:AIT with more optimal data, but still doing 100% CPU animation did 50000-90000 polys per frame at 60Hz. nVidia used the demo in some of their press releases (alien looking female with 3 coloured lights spinning round her - there used to be shots on Riva3D.com).

With totally optimal batching, and extremely careful use of dynamic buffers under DX8 I''d expect even more polys per frame. Our engine DX8 re-write is looking like its already beating our old DX7 effort without any optimisation - although we''ve not done any proper profiling yet.


One important thing to note though is "its what you do with them that counts" - you can usually produce much better results with clever texturing/blending/effects than you can with a few more polys. ISTR reading that a whole *level* in Quake2 contained on average 10000 polygons, but with the lightmapping and effects it looked a lot more detailed than it really was.

We''re working on a PS2 and GameCube game at the moment, and its an interesting dilemma for me - the artists want to know what the upper polygon budget is - what I''ve told them is about a third of what I expect the final optimised engine will be doing. Two main reasons:
1)its easier to ask them to add more detail later and still preserve the same framerate than it is to get them to optimise bits of detail when the game is slowing down.

2) I''m intending to use a very rich set of shaders/texture effects in multiple passes. Low polygon meshes with bump mapping, envmapping, per pixel specular, decals, Fresnel effects etc can make it look like theres 10x the polygon count.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com


Hmm, well I can push it to a million or so polygons per second, but that''s not a huge difference. Part of it is because I''m batching the particle effects poorly, and the other half is because I''m locking some VBs for animation when I probably should be doing animation in a shader. Anyway, as far as I can tell I think the overdraw is actually the primary performance problem, because I''m not clearing out occluded objects (it''s a very difficult problem to solve in landscapes). The animation is also a lot slower than I expected it to be (interpolating vertices has a lot higher cost than one would expect).

The figures I gave weren''t nearly ideal but rather just estimates for what you can expect most engines from my experience. Unfortunatly when you''re rushing to add features optimization can sometimes be pushed to the wayside and such.

----------------------------------
AIM: IanWinsAgain ICQ: 60635592 TIM: FaceHat
FaceHat Software -- Wear the hat.

Share this post


Link to post
Share on other sites
I''m a little curious about the comment about interpolation. How many vertices do you have to interpolate per frame on average? Do you have any idea what percentage of your time is spent on the interpolation? Also what percentage of your time is it worth to you? The main reason I ask is that I have some idea how much work is involved, but no idea of what that means in the context of a game.

Share this post


Link to post
Share on other sites
pentium3d:

Our office is in Cheadle, Cheshire which is near to Manchester (where many of us live) in the UK.

It was me who wrote the 3D part of the Pac-Man:AIT engine (aka the Paradox engine), in terms of 3D and game programming I''m largely self-taught with college, further college and school level qualifications in computer studies/science. Many years of practice in commercial and hobbyist situations is the most important education.

The company is aiming to stay small for as long as possible, preferably with only one team - this allows us to adapt to change very quickly and take risks larger companies couldn''t.
We also disagree with the idea of growing quickly to impress shareholders then making people redundant a few months down the line. (That''s what we ran away from! - we were part of an in-house team at a developer/publisher with over 130 staff).

A programmer from our previous company (Mike Spencer) has just joined us which balances out the team, so for this reason and the reason above we unfortunately won''t be needing to hire any new staff for the forseeable future (at very least until the end of the current project next year).


The Senshi:
quote:

Part of it is because I''m batching the particle effects poorly, and the other half is because I''m locking some VBs for animation when I probably should be doing animation in a shader.



Ah right, that does account for some of it. The effects were one of the killers caused by the artists - there''d be stray 8 polygon objects all over the place each using unique animating textures.
The VB locking thing is what I mean by correct use of dynamic buffers - tuning the overall size of the buffer, the size you lock, the flags you use to lock and the amount of polys/verts you pass to draw makes *A BIG* difference in my experience (in PM:AIT we originally had a big dynamic 10000 vertex buffer for all geometry which was locked, filled and drawn without any flags etc - changing it to a 2000 vertex buffer and drawing in nicer batches got us about a 50% speed increase).


LilBudyWizer:

I don''t have a debug version of the game on my home machine so can''t give exact figures, but I''d say 4000-10000 polys were animated with about 1.8 vertices per polygon so that''s 7200-18000 vertices being interpolated per frame.

The keyframes were stored at about 20fps and interpolated for higher framerates to give smoother motion.

The time taken for the actual interpolation is was never really an issue - if we''d had the spare development time it''d have been an ideal candidate for some 3DNow!/SSE/SSE2 optimisation though.

A much larger problem with the animation was the fact that the buffers were dynamic meaning for T&L cards we were locking and accessing Write Combined (i.e. uncached) AGP memory. On software T&L with the D3D PSGP this meant that D3D had to swizzle vertices into SIMD friendly format every draw call.
With hindsight there were probably a few things we could have done to improve the animation system - particularly in the area of level of detail and hardware supported interpolation.


--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
Simon, i''m afraid i didn''t explain myself very well.
I just wanted to know what to expect from the market
when I get myself in the "rather good 3D programmer" area,
and start looking for jobs abroad. I was not trying
to get a job at Creative Asylum. And I tottaly agree with you
in keeping teams as small as possible, for all the
reasons you mentioned and some more...
Can you tell me what your book library (about 3D)looks like?

What books did you read to get where you are now, and
what will you be reading in the near future?

Thanx for the tips,

[Hugo Ferreira][Positronic Dreams][]
"Research is what I''m doing when I don''t know what I''m doing."
- Wernher Von Braun (1912-1977)

Share this post


Link to post
Share on other sites
Ah right I see,
A very important thing to get right is your demo - it needs to show off as much as possible and have the slickest possible presentation. A complete game as a demo isn''t necessary, and could actually be a negative thing in some situations: imagine you have loads of cool stuff on level 2 of a game - you have no way of knowing whether the person looking at the demo will ever look past level 1. Smaller teams such as ourselves tend to only hire people with previously published games - mainly since we don''t have the time or resources to have to train somebody.

Larger teams and big multi-team studios hire graduates who can show decent demo(s), a sense of humour, good communication skills (meetings, meetings, meetings - even we have quite a few), self sufficiency (i.e. to be given a task, and be able to do your own research etc without having to ask the rest of the team every 10 seconds) and **a passion about games & gaming technology!**


As for the books I read to get where I am and which I''ll be getting:

I actually started 3D without any books or a clue of where to go (www wasn''t an option in 1989) when I was in the demo scene on the Amiga. Some very basic overview articles in magazines gave me an insight into the ideas of perspective etc. Some text file tutorials floating round the Amiga demo scene gave me an idea of the implementation side of things (perspective calc, 3d line draw etc).
Once I started making 2D only demos, I made some contacts who shared 68k sourcecode to their demos, some with very basic 3D - going through that source code revealed the use of sin() & cos() for rotation plus some other stuff like tabled lighting and backface culling. It wasn''t until much later that I learnt the proper maths of what I was doing and how matrices worked etc, but because I''d understood what the optimised asm versions were doing it made it easier to learn the basics (so I sort of learnt it all in reverse )

There are many books I''ve read that I don''t know the titles of - ever since I was young (before forums like this) I used to go down to the local library every week and just read technical books - even those I didn''t understand - it wasn''t research, it wasn''t understanding, it was purely soaking up "information".

3D books (or those containing 3D stuff) currently on my bookshelf include:

- Computer Graphics Principles & Practice (Foley & Van Dam et al)
- Advanced Animation & Rendering Techniques (Watt & Watt)
- Real-time Rendering (Moller & Haines)
- 3D Game Engine Design (Eberly)
- Game Programming Gems 1 & 2 (ed. Deloura)

[there are others, but some I wouldn''t recommend, and some are purely about maths etc]

I also have a large cache of SIGGRAPH papers which have caught my interest over the years on my harddisk, along with conference proceedings (paper & CD) from CGDC, Meltdown, registered developer conferences for hardware manufacturers etc.

I''ve actually got a "backlog" on books - I have some books I haven''t read properly yet, so there isn''t a specific shopping list at the moment, but a few I''d probably consider would be:

- The 2 Jim Blinn books (a graphics programming "God")
- Texturing and Modeling (Ebert)

- The Graphics Gems series (if I had the time/money - not essential reading, but some interesting snippets in those)

There are others which might be interesting, but I haven''t investigated properly yet.


As useful as those books are, the most stuff I''ve ever learnt has been from actually DOING rather than reading about doing! - formulas on a page are nice if you''re a mathemetician (I''m not!), but aren''t really interesting IMO unless you can "see" the results.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
Those are all good books, but personally I would suggest you start with something like OpenGL Game Programming by Hawkins and Astle. Once you master a howto book like that then start with Computer Graphics: Principles and Practices. I believe the 3rd edition comes out in the next month or two so it should be out by the time you have a completed program and played with it a bit. It is easy to spin in circles and run off on tangents. Working through a howto book should give you a bit of direction for your quest.

Share this post


Link to post
Share on other sites
Well, yes, thanks for the suggestion, but i did
AndreL'' "WGPGurus", and Prima''s OpenGL and i own lots
of otherbooks, like, the gems, I&II
Prima''s Direct3D & Multiplayer & Pocket PC books( i own
an iPAQ 3660), i own "Computer Practices, principles and practice" and "Advanced animation and rendring tecniques."

I used to make 3D rotating cubes in turbo pascal, using
assembly (duh!), its just it took me a while to know c++,
and get into the Windows32 programming architecture stuff...

I''m really, really advanced as a DOS programmer, i did a
multitasking unit (a header, in c++), that enabled other
pascal programs to run with multithreading capabilities, it
was preempted (used the clock)...

Also, i''m an A.I. scientist, in the bio-mimic aproach (trying
sintectic AIs to work, by analysing the copied central nervous system of the animal''s day-to-day behaviour...)

So, i think i have a lot of knowledge under my arm, i just
nee the time to flex my windows muscles, once i do that, i think
i''ll start writing cool win32 apps. I have an opengl 3d mesh
loader, with texture-maping running right now, its the top thing
i did so far. I''m gonna improve the engine, and generalise it
a bit so that i can make a basic Opengl 3D chess game until
March this year...

Lets see if i can make it till there...

I love game programming, cause its the most challenging area,
and would love to join a company one day...



[Hugo Ferreira][Positronic Dreams][]
"Research is what I''m doing when I don''t know what I''m doing."
- Wernher Von Braun (1912-1977)

Share this post


Link to post
Share on other sites