TriCount v. Textures

[RoverDude]

So in working with a part that will likely be part of a ship with partcounts in the 200 or so range, and assuming smaller or compressed textures (idealy single color 64x64 ones), what kind of tricount should I aim for as a reasonable upper limit? I'm trying to figure out how much detail I can safely add before hitting issues, but at the same time, don't want to be so conservative that I avoid adding further detail to a model.

Thanks!

[Greys]

I'm gonna skip ahead and come back. If you have a texture that is a single color, there's no reason for it to be more that one pixel, and 64 square isn't big enough to do much with emissives, normals, etcs. So save yourself the rest and round down to 1x1.

Textures can be expensive in that they take up a lot of memory, but drawing them onto geometry doesn't change a whole lot by the texel density because the number of pixels they take up on screen is pretty much unrelated.

Mesh can be expensive because the graphics card has to simulate a space with them in it and figure out how a bunch of stuff adds up to result in the scene, so having simpler geometry can make that faster.

That all said, textures take up memory, mesh take up GPU Utilization, and what makes KSP's physics get bogged down is not either of those.

Ships with super high part counts are hard for KSP because KSP simulates the physics of every part separately, ships are bendy not rigid, and every part has it's own collision mesh, which admittedly is culled a bit by making ships clip through themselves.

Making your collision mesh simpler and using primitive colliders instead of mesh colliders wherever possible will improve performance but the issue is quantity of parts more than it is the complexity of those parts

Edited March 30, 2014 by Greys

[Justin Kerbice]

Regarding poly count of objects, I get some data modders may found interesting.

I'm curious about how GPU intensive KSP/Unity can be, so I create a crazy thing.

stats:

57780 polygons

112860 triangles

56538 vertices

collada object size: 14043 Kb

mu object size: 4229 Kb

(the object is so big, it is split in unity into 2 separate objects !)

In game: surprise......... NO slowdown at all !!!!

Far less than having a 500 parts ships, GPU not so much used (piece of cake for them)

On my test install, I haven't yet add showfps library, I'll redo some test with it.

Javascript is disabled. View full album

I'll update later with part download link.

Conclusion: we should stop making ugly low poly objects, and start to make things smooth !

[Dispatcher]

That's cool! However, do you consider your computer to be of average, below average or above average hardware; such as RAM, CPU, graphics card, etc.?

[Justin Kerbice]

That's cool! However, do you consider your computer to be of average, below average or above average hardware; such as RAM, CPU, graphics card, etc.?

It's pretty high-end for now: a gamer laptop Asus G750JH-T4024H with a i7-4700HQ 2.4 GHz, Nv GTX-780M 4GB, 32 GB ram, ... but a ship with almost 500 parts, I got only 5-8 FPS, and GPU are always under used.

For info: Far Cry 3 (badly coded) is almost smooth at max, max ok for Crysis 2, Saint Row the 3rd, Shift 2, Red Faction Guerilla, ...

I'll try some other unity games, it might be interresting.

[NovaSilisko]

Polygons are generally cheap as hell to render. A decent computer can handle millions and millions of them (plain ones, minimal shader weirdness) on screen at a time before slowing down.

Try some ships of 50 to 500 or so parts with your high poly objects, vs the same stress tests using some low poly objects with the same texture (just overwrite the model, perhaps, so you can use the exact same test craft). I'd be interested in seeing how much difference it makes. While you're at it, maybe try the same tests with a 2048x2048 texture applied to those same high and low poly models.

[Justin Kerbice]

This is the file (max scene + collada object included), "released" under my whatever license (see my stuffes for details).

Tried with showfps plug-in: as I guess, 60 FPS except when hyperedit do its job and when physics get stabilized.

The collider used is a mere big box around.

Polygons are generally cheap as hell to render. A decent computer can handle millions and millions of them (plain ones, minimal shader weirdness) on screen at a time before slowing down.

Try some ships of 50 to 500 or so parts with your high poly objects, vs the same stress tests using some low poly objects with the same texture (just overwrite the model, perhaps, so you can use the exact same test craft). I'd be interested in seeing how much difference it makes. While you're at it, maybe try the same tests with a 2048x2048 texture applied to those same high and low poly models.

Interesting challenge but I'm pretty sure we'll reach CPU limit first and it will bias the final result as unless we have access to Unity internal profiling/statistics data, how can we be 100% sure that is the polycounts/textures which create the slowdown or the physics ?

Of course I can track GPU usage with nvidia inspector + CPU/disk/ram usage with integrated win7 task manager, but it will be indirect view.

As I wrote earlier, I get low fps (9 top) with a bit less than 500 parts using stock parts and 1 Talisar's spherical tank, 17 mechjeb control units, a few KAS end pipe point and 16 basic SCANsat sensors.

On my system, it's always CPU which kill KSP performance, I don't play fullscreen but I think resolution is irrelevant anyway. GPU just work a little.

[CaptainKipard]

If you have a cheap laptop you can do your testing on it.

[DMagic]

Interesting challenge but I'm pretty sure we'll reach CPU limit first and it will bias the final result as unless we have access to Unity internal profiling/statistics data, how can we be 100% sure that is the polycounts/textures which create the slowdown or the physics ?

Of course I can track GPU usage with nvidia inspector + CPU/disk/ram usage with integrated win7 task manager, but it will be indirect view.

Turn off physics for the part in the cfg file. I can't remember the exact line, but you can check the cubic octagonal strut file and copy it from there.

[Justin Kerbice]

Turn off physics for the part in the cfg file. I can't remember the exact line, but you can check the cubic octagonal strut file and copy it from there.

is this PhysicsSignificance = 1 ?

There is a talk here and a link pointing to something I don't have access to. Here is another data.

Doing this for all parts used in a 500 or more parts ship... may need some parsing helper . I'll perhaps try this one day.

[Justin Kerbice]

Juts as an experiment, I have tried to put as much as possible of these physicless octo strut, the result is a 542 parts thing with only a few cube and a command pod, I get less performance that way. I don't think it's 7 parts with physics enable which eat the performance.

Album updated with new pics of the thing.

[landeTLS]

This seems to confirm what i was thinking about triscounts. They can be crazy high as the only thing in the scene is usually the rocket(s) and some lod reduced planets terrain. Compare this to other modern games where you often have entire high geometry cities with lots of breakable objects in the scene (think battlefield 4 etc.) Unity may not be the most optimized engine for modern graphics but its still quite good. I think one can even on low end rigs have models with 10-15k tris for engines and other parts that are used in low numbers and around 3-7k on other parts. What to mainly focus on instead are the physics colliders(i never generate colliders in unity from meshes as this creates really complex colliders. Instead i build them as seperate super simple geometry objects ) need to be pretty optimized and another thing iwe noticed is that unity dont handle many seperate objects well(ie. Many drawcalls) but from what i can gather this issue can be virtually eliminated by joining objects (the meshes are still seperate in the object but dont create more than one drawcall) this can also be done with colliders (exept those that need to be seperate objects so that ksp can designate them as ladders/hatches etc.) Something iwe been working on recently is using mesh deformation/vertex groups to do animations(each mesh inside the object is assigned to a bone via vertex groups so all legacy animated objects can be single meshes. This way no deformation of the meshes are performed and they move as if they where seperate objects) still some stuff like landing gears where some springing etc is performed inside ksp probably need some of its objects seperate and parented in the traditional way. But overall this method reduces drawcalls on animated parts dramatically.

i Hope this post was informative for some ppl. It summarizes the things iwe been able to gather over the past months. And i apologize for my poor english. Im norwegian

Edited March 31, 2014 by landeTLS

[Absolution]

Without giving a definitive answer I say "the fewer the better". Sure, polygons are relatively cheap to produce on low end machines but you have to consider the bigger picture. You can easily get away with a single part with 40k triangles but what happens when you put a dozen of those parts together? It can really add up quickly.

For my mods I put an upper limit of 4k on most parts and only go above that for extremely fancy parts (like an engine). You'd be surprised just how nice a part can look with so "few" polygons. In my experience the texture has a much more profound impact on how good the part looks (unfortunately I suck at texturing ). If you add in Normal maps you got yourself a recipe for some really nice stuff with relatively few polygons.

[PolecatEZ]

But with those nice Normals and Textures you start hitting another limitation, the almighty RAM cap, which you really need to keep under 2.7 on a fresh load if you don't want your game to randomly crash when it decides to suddenly eat a lot.

My framerate with my GTX770 did take a hit when I was playing with making objects and put in a block of spheres with a poly count of 77,000. I lost a whole 10fps (from the capped 61) when I threw the object on the floor in the VAB. I came here hunting for what the acceptable limit would be, and I see its still under debate. Roundy objects just don't quite look right without a high poly count, unless I'm missing a trick (likely, just got Blender yesterday).

[NoMrBond]

Roundy objects just don't quite look right without a high poly count, unless I'm missing a trick (likely, just got Blender yesterday).

You possibly need to apply the Smooth shading modifier which has been moved to Edit mode under Blender 2.70 (which is good because now you can select by face/edge/vertex rather than by whole mesh only from when it was under Object mode). While in Edite Mode it's under the Shading/UVs tab on the left hand edge now.