View Full Version : Object count NOT polycount limits display speed
pixelherder 07-15-2003, 02:27 PM an untextured max scene with an average poly count of 60,000 polys runs like a dog. Its made of multiple objects (approx 1000 - its a game level)
HOWEVER if you merge the pieces into one mesh, the frame rate jumps back to normal (not practical, just for demonstration purposes)
I had thought that textures/polycount were the main slowdown, but this isnt the case.
This would explain the problems in previous projects (it wasnt the xrefs slowing things down, it was the number of xrefs/objects in the scene)
Anyone have any idea why this should be the case - max can throw around massive amounts of polys in certain cases, so is there a cause/solution/workaround to this?
It makes building even semi-detailed scenes a real pain, and as i mentioned, xrefing doesnt solve the issue at all (it near crippled a previous project)
And does anyone have experience of other packages for game levels? Maya keeps cropping up in conversation, but just because someone says the grass is greener doesnt make it true...
aidan
|
|
EricChadwick
07-15-2003, 02:50 PM
What hardware are you using? I've found the quality of my graphics card can make a big difference, like a pro-level card. Different cards run OpenGL or D3D faster.
I think the same thing occurs with Max as does with your game... each object needs its own transforms. The more objects, the more transforms to calculate to render a frame.
However your game probably has optimizations like culling, mips, LOD, etc. that Max doesn't do for the most part, since it is an authoring tool. Multiple views at once, modifier stacks to calculate, etc.
Maybe you could try using a Camera with clipping planes? Collapse the stacks? A couple ideas...
maxmare
07-15-2003, 02:52 PM
Sorry, no solution from me, but I must say I have noticed that as well and that's why I always try to merge objects into one mesh whenever possible. Maybe it's got to do with the way Max has to store its data tree in memory and the way to access the data when displaying, in which case...well, you know!
I assume you aren't using HEIDI as the display driver?. Just a thought.
pixelherder
07-15-2003, 03:10 PM
...i cant remember everything off the top of my head, but i'll try and cover the main points
Display - i'm using a geforce 4, but with the slow scene (all the individual objects) the max frame rate seems to be the same across the board - open gl, d3d, heidi. I'm guessing that its the cpu/memory load thats grinding things too a halt.
Collapsing - the game engine uses instanced objects in a tile like fashion to reduce the memory overhead (e.g. a room would be made of instanced sections of wall geometry etc) Therefore collapsing the mesh isnt practical because then you lose the benefits of instancing. So the console can display these things fine, its AUTHORING them thats so slow.
A previous title's levels took 10-15 minutes just to load - you can imagine the effect this had on workflow (no room for tweaking, experimentation, just had to stick with what you got)
The general consensus seems to be that this is just the way max is, and theres not a lot you can do.
drat!
EricChadwick
07-15-2003, 03:14 PM
Did you post on the Discreet board? Lots of knowledge over there...
EricChadwick
07-15-2003, 03:17 PM
Oh, just remembered. I have a little script around here somewhere called InstanceOMatic that will let you re-associate the instance link between mulitple objects.
So you could use the Collapse util, then re-instance.
Or are the stacks collapsed already?
pixelherder
07-15-2003, 03:22 PM
i've got the same question over on the discreet boards, but i dont know if the answer will be any different
the instanced geometry we use is "final asset" standard - that means its modifier stack has been collapsed and its just a simple editable mesh*
*on a completely unrelated note, i made a benchmark scene with dozens of teapots, total of 400,000 faces. Ran pretty smooth as primitives. ran ok when converted to editable mesh - framerate went through the floor when converted to editable poly. Odd but interesting!
EricChadwick
07-15-2003, 03:24 PM
Huh.... maybe max is slow in converting to tris for hardware. Bummer.
Here's that script anyhow.
http://www.scriptspot.com/Main_Scripts.asp?BrowseType=Search&Sort=Popularity&ST=-1&SearchField=Instance-O-Matic
pixelherder
07-15-2003, 03:32 PM
thanks for the feedback fellas
cheers!
Invader Zim
07-15-2003, 04:24 PM
How big are your texture sheets and how many of them do you use? This could slow down your machine.
I work on scenes that have more than 60 000 triangles and they work fine and they don't take more than 1 minute to open. Have you tried opening them on another computer? You shouldn't have problems especially if you intance everything. Maybe your MAX or version of windows need to be reinstall.
Have you tried calling a witch doctor ? ;)
Have you tried putting an editable mesh modifier on top of all your stacks?
Also, have you tried using Maxtreme, it gives a very sizeable speed boost to the viewport speed
its because max isn't very good at handling large data sets...1000 of 10 poly objects will be way slower than ten 1000 poly objects or even one 10000 poly object.
This is because for every object there is the axis data, the position data, all the properties data (like renderable etc), as well as any modifier data you may have....when you have one object you just have one set of data....it shows that the gfx card handles polys far better than your machine is handling data
more ram may help if your running out and a faster processor will, but i really doubt this is anything to do with your gfx card
CGTalk Moderation
01-15-2006, 03:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
vBulletin v3.0.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.