Maximum Poly Counts

[Phoenix1583]

Hey folks. Just curious about what level of detail should I be using when working on engines, fuel tanks, and other objects? Given that we do not yet have a functional (Windows) x64 client, I have a feeling that poly counts are rather limited. Is 3-5k polys too much for say... an engine?

Example seen below (poly/tri count at top left)

Edited June 18, 2015 by Phoenix1583

[landeTLS]

Polycount doesnt do much in the way of memory or performance for that matter. Texture size is much more important. As a second concideration many unmerged/unattached objects in your part will slow down performance.

When it comes to polycount i usually dont care so much about the count but instead i just try to keep the polygons even'ish in size. Ie as cylinders taper in their segements decrease or a smaller cylinder gets less segements than a big one.

I would compare a rocketengine in ksp to a weapon in an fps game for reference on how many will appear in a scene. Given that you can use too many polies but the tipping point is probably somewhere around 20-60k (depending on scale) for few use parts. And that is being quite conservative(given that ksp is played on low end computers, but in those cases you are still much more limited by texture size).

Yours is now about 6k. Just emagine how wastefull you would need to be to reach those kinds of numbers. For many use parts like fueltanks etc. You should probably be aiming for less than 5k polies.

also. When i say polies/poly im talking about triangles and not quads, so for a nontriangulated model youll be looking at the triangle count and not the polycount.

An example in ksp is the mainsail. It is around 10k polies if i remember correctly.

hope this helps

Update: improved explanation a bit and formatting

Edited June 18, 2015 by landeTLS

[NecroBones]

Polycount doesnt do much in the way of memory or performance for that matter. Texture size is much more important. As a second concideration many unmerged/unattached objects in your part will slow down performance.

For clarity, specifically having multiple mesh objects will count against performance, much more than multiple mesh islands in a single object. Each mesh object is a separate draw call, and that's where you take the biggest performance hit.

[landeTLS]

Yes that was what i was getting at. It gets a bit cumbersome to explain properly because different softwares use different terminology.

Basically You can have as many detached parts as you want, but they should be part of the same object (atleast when exported to unity)otherwise youll incur extra uneccesary drawcalls.

To further clarify you do not need to boolean or attach the meshes physically together, just attach them so they appear as 1 object in the inspector view.

There are cases where youll want them to be seperate objects. Like if you are animating them through basic parent/child based rigging(one example is the standard engine gimbal setup for the nozzle). If you use different texture maps for them and/or you need a different shader for the objects.

[Beale]

For reference, the stock 1.25m engine (LVT-40?) has just over 1.5K triangles.

Triangles is the important number, as I'm pretty sure all quads and N-gons get converted to that in Unity.

Mainsail, and I imagine most of the other 2.5m engines have in region of 2.5K triangles.

Like others have said, I'm sure the engine can handle much higher numbers, but these are maybe good reference points.

Edited June 18, 2015 by Beale

[Phoenix1583]

Alright, so to sum up what's been said thus far:

A: Poly counts ingame are limited to increase performance on lower end machines.

B: Poly counts are not a major factor in performance on higher end machines but textures are.

C: Avoid multiple meshes where able if not needed. Combine into same group object.

D: Stay under 10k tris per object to ensure that complex rocket designs are not bogging down the engine.

E: Wait until 64bit becomes available.

[landeTLS]

Regarding A: yes to a small degree but texture size is still much more important. Think of it as what will tax the gpu/cpu most: The gpu is designed to render many points quickly through threading, this makes it excellent for rendering many polygons. But textures are one big 2d image that need to be painstakingly projected onto those polygons. I dont know so much about the internal processes here but from experimenting iwe seen that even lower end machines (that can barely run ksp smoothish by default) can easily handle moderately higher poly objects with small textures, its when you put in 1024++ textures on the parts that you get one figure framerates.

E: 64bit wont do much/anything for performance. The major advantage as i see it is the ability run more mods in your game. I tell you, i was trying to get ksp running just with the full nearfuture pack and some kopernicus planets + agressive texture compression. and there is just no way of balancing it to not go above the memory limit after a few launches. There may be a mem leak somewhere but even without that im too close for comfort to the memory crash limit after load.(for me the game crashes at around 3.4gb-3-8gb)

Btw: did they optimize the mainsail? I thought i saw it at higher polycounts earlier.

Edited June 19, 2015 by landeTLS

[Alewx]

My last stand at Unity was that it only supports meshes with up to 65k verticies.

So I think you might want to reduce the engine slightly.

[landeTLS]

Unity splits up single objects that are over 65k polygons to multiple drawcalls/objects automatically. I was able to get a model with over 1m polygons into ksp. But since it was split into almost 20 drawcalls the performance was a bit low.

In eather way his engine is only about 6k polygons not 60k so he is way below the treshold where unity needs to start splitting objects.

Might be that unity counts verts here and not polygons. I dont remember. But in that case you are even better off as youll usually have less verts than polygons (triangles)

Edited June 19, 2015 by landeTLS

[NecroBones]

Texture size is also important in the sense that KSP keeps all of the textures in memory all the time (unless you install ATM). For people who like to run a lot of mods, a heavy memory hit can be expensive. This is less a performance issue than one of playing nice with other mods, so that people can run more of them at once.

[Alewx]

Unity splits up single objects that are over 65k polygons to multiple drawcalls/objects automatically. I was able to get a model with over 1m polygons into ksp. But since it was split into almost 20 drawcalls the performance was a bit low.

In eather way his engine is only about 6k polygons not 60k so he is way below the treshold where unity needs to start splitting objects.

Might be that unity counts verts here and not polygons. I dont remember. But in that case you are even better off as youll usually have less verts than polygons (triangles)

Good to know, in unity 3.6 (yeah that is quite a long time ago) and the one after that 65k vertices where the limit than the import stopped.

Texture size is also important in the sense that KSP keeps all of the textures in memory all the time (unless you install ATM). For people who like to run a lot of mods, a heavy memory hit can be expensive. This is less a performance issue than one of playing nice with other mods, so that people can run more of them at once.

At the same time (long ago) we learned that unity is better in handling less large textures than multiple small ones.

But like before my knowledge could be massively outdated.

[NecroBones]

At the same time (long ago) we learned that unity is better in handling less large textures than multiple small ones.

But like before my knowledge could be massively outdated.

Yeah, I have no idea on that one, especially with Unity 5 around the corner for us.

But just from a "memory saving" context, these days I tend to favor one big texture shared amongst several parts. The more parts that can use the same texture, the better.

[landeTLS]

Using a big texture across many parts/models (i believe its called "texture atlasing" or something thereabouts) is a good idea for memory savings, and with limited memory available with the 32bit based ksp this becomes good practice in almost all cases.

But to delve more into detail each drawcall must now reference a big texture file rather than a smaller one, it could perhaps lower the performance compared to multiple moderatly sized maps. (For example you have 4 parts. Eather using 1 x 2048map or 4 x 512maps)

But this is where my knowledge of the processes really falls short.

Ksp keeps all assets loaded at all times. Ram/ddr memory is very fast and gpu memory is even faster so the fact that multiple operations may be referencing the same memory blocks at the same time should not be a performance issue. But the bigger map size may be an issue as for example each mesh rendering operation on our 4 parts must now reference the 2048map (4 x 2048) vs (4 x 512). But again there may be some batching/caching or other smart programming going on in the background to make this less of an issue(inside directx/opengl and/or in unity). So unless someone here has some more in depth knowledge, testing it ingame may be the best way to know for sure.

[Beale]

Using a big texture across many parts/models (i believe its called "texture atlasing" or something thereabouts) is a good idea for memory savings, and with limited memory available with the 32bit based ksp this becomes good practice in almost all cases.

But to delve more into detail each drawcall must now reference a big texture file rather than a smaller one, it could perhaps lower the performance compared to multiple moderatly sized maps. (For example you have 4 parts. Eather using 1 x 2048map or 4 x 512maps)

This is my go-to method of texture design (See texture repo in signature), really can it cause performance problems? (I thought UV shapes were referenced as percentages of the distance of the height and width of the texture, so different resolutions would not impact performance).

Either way, interesting info, thanks

Btw: did they optimize the mainsail? I thought i saw it at higher polycounts earlier.

Possibly, those numbers were taking using the Blender .MU converter - I don't know if there are any errors in conversion, so you might want to regard them with a pinch of salt.

Edited June 19, 2015 by Beale

[NecroBones]

really can it cause performance problems? (I thought UV shapes were referenced as percentages of the distance of the height and width of the texture, so different resolutions would not impact performance).

That's my understanding as well. I'm surprised to hear of performance differences with larger textures. The one thing I can think of, is if the video card has very little video memory, so the textures have to be loaded/purged from the video memory more frequently. That I could understand.

[landeTLS]

Yea. Take my theorizing with a grain of salt. It may be that the performance does indeed not take any hit what so ever by using big atlases across many parts over single per part maps. A quick google search did not uncover any good resources on this in a performance context. I kindof wanna test out using a 4096 atlas across a bunch of parts vs 512 single ones to see if there are any difference in fps.

In any case its good practice to prioritize decreasing drawcalls on your meshes. Ie avoiding multiple materials/texture maps on single parts as well as attaching objects into one as much as possible. Texture size and this does much more for your performance than does polycount

edit:

i did a quick atlas vs single maps experiment with my potato laptop(intel i5-460m @ 2.53ghz, ati radeon 5650 1gb, 4gb ddr3 ram) graphics card is a bit on the weak side, so this one barely runs ksp with full texture resolution(at 10-20fps..)

these are the results:

Javascript is disabled. View full album

as you can see the results where quite even, if you can see the tiny fps view in the upper right corner. the avarage was about the same for both the 4 parts with the single 1024 maps vs the 4 parts sharing a 4096 atlas map. i didnt do any more detailed checking because most differences will probably mostly be on account of noise on this laptop. the single maps did seem to perhaps have a higher peak fps but the avarage was 8-11 for both atlas and single.

i set this up by picking a part that didnt use a normalmap and used a big texture(i picked one of the kerbodyne tanks that uses a 1024x1024map) i then duplicated the folder 4 times and renamed the parts in the cfgs. i then duplicated all 4 folders and scaled one of the texture maps to 4096x4096, put it in a seperate folder and scaled down the texture maps of those 4 parts to 1x1 i then referenced the texture atlas in the cfg of those 4 parts, and renamed them.

you can download the gamedata folder here if you wanna try it out. it would be easier to distinguish any differing results if the test is run on a more suitable (low>midrange with a slightly petter gpu) computer, and if running a better fps logger. Its probably easier to see any differences if more of each parts are used

edit:

sorry to the op about cluttering his thread with discussions of tiny optimizations. hopefully his questions got answered.

Edited June 19, 2015 by landeTLS

[Beale]

-Science-

Great stuff!

Many thanks for taking the time to do this.

Interesting stuff, it appears the overall impact is thankfully quite minimal - but, there is a difference which is good to know.

[landeTLS]

Great stuff!

Many thanks for taking the time to do this.

Interesting stuff, it appears the overall impact is thankfully quite minimal - but, there is a difference which is good to know.

actually youll be happy to know, i did another test after a modeling session. this time on my main gaming/rendering pc and the results are much more conclusive. there is actually about a 16% gain in performance in using an oversized atlas over single maps(in this case, might be even higher in most cases)

2015-06-20 03:07:00 - KSP
Frames: 1505 - Time: 60000ms - Avg: 25.083 - Min: 9 - Max: 29
//this is with single 1024x1024 texture maps

2015-06-20 03:10:11 - KSP
Frames: 1747 - Time: 60000ms - Avg: 29.117 - Min: 7 - Max: 35
//this is with the single 4096x4096 atlas map

epic stack of tanks is epic.

sorry no FPS overlay, forgot that fraps doesnt work that way

Edited June 20, 2015 by landeTLS

[NecroBones]

actually youll be happy to know, i did another test after a modeling session. this time on my main gaming/rendering pc and the results are much more conclusive. there is actually about a 16% gain in performance in using an oversized atlas over single maps(in this case, might be even higher in most cases)

2015-06-20 03:07:00 - KSP
Frames: 1505 - Time: 60000ms - Avg: 25.083 - Min: 9 - Max: 29
//this is with single 1024x1024 texture maps

2015-06-20 03:10:11 - KSP
Frames: 1747 - Time: 60000ms - Avg: 29.117 - Min: 7 - Max: 35
//this is with the single 4096x4096 atlas map

http://i.imgur.com/HZGI1ap.pnghttp://i.imgur.com/xvG9qdW.png

epic stack of tanks is epic.

sorry no FPS overlay, forgot that fraps doesnt work that way

Awesome. So yes, one big texture beats many small textures. That's good to know.

BTW, FRAPS has a checkbox in the screenshot settings for including framerate.

[Beale]

actually youll be happy to know, i did another test after a modeling session. this time on my main gaming/rendering pc and the results are much more conclusive. there is actually about a 16% gain in performance in using an oversized atlas over single maps(in this case, might be even higher in most cases)

Why can't I rep you again? Ack!

That's great news, thanks for gathering even more data on it!

[landeTLS]

Why can't I rep you again? Ack!

That's great news, thanks for gathering even more data on it!

no problem, i just thought of another fun performance test to run. hipoly vs lowpoly w/ big maps

take one cylindrical hipoly model with 20-40k triangles(lots of greebles on it), bake out a big normalmap from it and perhaps ao to a plain cylinder. create mu files with same collider for both. but put a 1x1 texturemap to the hipoly model(this is to keep the game from temporarily freezing as it is looking for a nonexisting texture map), and the 1024x1024 normals/diffuse to the plain cylinder. put a bunch of each on two different vessels and check avarage fps over 60 sec.

i might run it later.

just saw the trick with the fps in fraps now, thanks to necrobones for pointing it out

Edited June 20, 2015 by landeTLS

[Fengist]

Ok, so here's a noob question. I assume collision meshes add into the equation. Do multiples of those matter much? I know they're low poly count.

[NecroBones]

Ok, so here's a noob question. I assume collision meshes add into the equation. Do multiples of those matter much? I know they're low poly count.

Yep, generally you want to keep them as simple as possible, with as few of them as possible, to get a good rough estimate of the shape of your object. The more of them you have, and the more polygons they have, the more it taxes the physics system, which is where most of KSPs performance problems are.

The stock fuel tanks use a single 12-sided cylinder as the collider, as an example of what you might want to aim for. Sometimes you have no choice but to use more, for more complicated parts. Cargo bays and the like will usually have several rectangular ones for the walls and doors. Landing legs have separate colliders for the piston parts, and the attachment base.

Here's an example of colliders I did for a more unusually shaped part (the command pod for the Joolian Discovery). I used a truncated "sphere" for the bulk of the pod, and two more "truncated cone" colliders for the neck area, all 12-sided:

Javascript is disabled. View full album

[landeTLS]

What necrobones said. In addition you are limited to 256 tris (if i remember correct, might be verts) for each collision mesh. But this is still probably more than you need. Its probably better to combine several colliders to match more complex shapes (since these dont contribute to extra drawcalls). I prefer the primitive box collider in unity for adding protruding collider pieces. But there may be some performance issues by using exessive amounts of colliders. Its also not currently possible to make concave (shapes with holes in them) colliders work in ksp. In order to make them you need to arrange several colliders to make up your shape

Edited June 23, 2015 by landeTLS

[Fengist]

What necrobones said. In addition you are limited to 256 tris (if i remember correct, might be verts) for each collision mesh. But this is still probably more than you need. Its probably better to combine several colliders to match more complex shapes (since these dont contribute to extra drawcalls). I prefer the primitive box collider in unity for adding protruding collider pieces. But there may be some performance issues by using exessive amounts of colliders. Its also not currently possible to make concave (shapes with holes in them) colliders work in ksp. In order to make them you need to arrange several colliders to make up your shape

Yea, I discovered the 256 limit in one instance in the log. What I've mostly been doing is chopping the model into pieces in the editor (save selection as .obj) and just importing the .obj pieces into Unity and using those for colliders. Most of my parts aren't standard shapes. Looking at necro's model, I guess I would have come up with the same shapes but maybe not the same way. I would have selected all the faces in the forward round part, the truncated sphere, and exported that as an obj, and then the same for the two rear truncated cones. I wouldn't attempt to make those from Unity primitives. I assume this is the correct method.

One thing this thread has taught me, I'm WAY under the poly count. I doubt any of mine have more than 500. So that's good news, I can make my models smoother. As for UV's, I used Wings 3D and have no idea how to combine the unwraps. I assume that's something I'd have to plan out as in, keep model x's unwraps on the left side and model y's unwraps on the right side and then use my graphics editor to mash the two together in the same .png file?