Polygon limit?

[Staer9]

I am currently modelling quite a complex ship, but I want to know: what is a good polygon limit so that the ship will run smoothly but also look awesome?

[Svengali]

Welcome Staer9. It depends on what you are targetting.

A good test is to spawn a bunch of them to see if there's a FPS hit. But the v/f numbers are not the only factor for FPS drops and I don't think that there is a general working rule. It all boils down to testing, testing, testing .-)

Most of the OXP ships are still below 500 vertices and 800 faces (per entity), but your 'complex ships' sounds as if this wouldn't match your expectations...

[Zieman]

Some indication in the Screenshots thread:
https://bb.oolite.space/viewtopic.php?p=95120#p95120
https://bb.oolite.space/viewtopic.php?p=95167#p95167

[Staer9]

My ship is probably going to be slightly over 1000 polygons...
which could cause a slight problem, but I haven't finished modelling it so maybe I can drop the count somewhat.

[Commander McLane]

There is no vertex or face limit in current Oolite, therefore your ship will be rendered in any case.

I don't know how the number of polygons will impact the frame rate. I am no ship builder myself. I tend to think that the impact of shaders will be bigger than the impact of polygon-number, but I can be wrong.

I think you just will have to try on a middle- or low-range computer and see how it works out.

[Killer Wolf]

i asked the same question a couple times, and most replies seemed to infer any amount was ok. i still try and be sensible and i find myself almost obsessively scouring my models to find a face to remove etc ~ i guess this sometimes is detrimental to my design/detailing. i suppose the only thing i'd consider now is how many of the things you'd be likely to meet - if you've got a 2500 face spacestation it might not be too bad, but if you've got a 2000 face fighter, and you get five on them blitting about in a dogfight, it might be an issue.

regarding McL's comment - what's the processing/lag differential between using Griff's shader, or using the MAterials statement etc in the shipdata?

[Svengali]

There is no vertex or face limit in current Oolite, therefore your ship will be rendered in any case.

Yes, the limit is gone for a whole while now. If I remember right KW and Frame have done some higher detailed models.

I'd think there are different factors that have an impact on framerates.

- vertex/face counts will have an impact on spawning the entity. Higher detailed models will need more time, probably because of the octree calculations. And positioning/rotating the entity will be slightly slower.
- textures have to be loaded. I/O transfers can be pretty slow and GPU limits for the max size can cause weird effects.
- shaders can cause pretty big FPS drops. And the difference between 2nd and 3rd generation GPUs makes it sometimes difficult to understand why this happens.

While doing the inflight overlays for the Vector I've seen that using a shadered entity with shadered subents is slower than doing it with single entities.

Sidenote:
I've read that 2nd generation GPUs are handling the if/else stuff different to 3rd generation GPUs.

Code: Select all

if(condition){...}
else {
  if(codition){...}
  else {...}
}

On 2nd generation GPUs all code is executed regardless of the condition. After processing the not matched results are truncated. 3rd generation GPUs are executing only the code for matched conditions. Maybe the article was wrong or I have misunderstood it. I'd think Ahruman can tell us more .-)

My ship is probably going to be slightly over 1000 polygons...

Doesn't sound bad. But 1000 polys can be a much higher face count. How many triangles is it?

He - this cries for a screenie! .-)

[JensAyton]

I don't know how the number of polygons will impact the frame rate. I am no ship builder myself. I tend to think that the impact of shaders will be bigger than the impact of polygon-number, but I can be wrong.

They’re different types of cost. Setup time costs and vertex shader/transform costs are per-polygon, while fragment shaders’ costs are per rendered pixel (in addition to a per-frame setup cost which is roughly proportional to the number of uniforms, including textures). A slow fragment shader will slow you down when the ship’s close to the camera, while a high polygon count will slow you down whenever the ship’s in drawing range.

- vertex/face counts will have an impact on spawning the entity. Higher detailed models will need more time, probably because of the octree calculations.

Correct.

And positioning/rotating the entity will be slightly slower.

True, but potentially misleading; geometric transformations are actually part of the per-vertex drawing cost, and generally happens on the GPU (in the vertex shader) and is elided for objects outside drawing range. Oolite 1.x doesn’t reuse identical vertices, so the vertex count in this case is strictly three times the number of triangles. 3000 vertices is a very small number in this context, so you don’t need to worry about it.

- textures have to be loaded. I/O transfers can be pretty slow and GPU limits for the max size can cause weird effects.

Textures don’t just affect loading, either; textures may need to be swapped in and out of video memory, and there’s a setup cost per object per frame per material per texture.

While doing the inflight overlays for the Vector I've seen that using a shadered entity with shadered subents is slower than doing it with single entities.

There’s a cost for switching shaders (bigger than the cost of switching textures), so using specialized shaders for different parts of a ship can easily be a failed optimization.

I've read that 2nd generation GPUs are handling the if/else stuff different to 3rd generation GPUs.

Yes. The old approach is equivalent to evaluating each branch, then calling mix(a, b, (float)condition);. This allows each vertex/fragment in a batch to have the same control flow – it’s a lot like SSE programming.

Newer GPUs have better but still limited ability to branch.

[ZygoUgo]

On a kind of related note I was wondering how Oolite goes about using two cores? I find alot of pausing when things are being spawned which made me wonder about it. Oolite definately recognises I have two cores, so is it currently using them, or will this be for /2?

[Svengali]

Thanks a lot Ahruman.

He, and your explanations made me thinking about the buoyRepair station (urgs) .-)

[JensAyton]

On a kind of related note I was wondering how Oolite goes about using two cores? I find alot of pausing when things are being spawned which made me wonder about it. Oolite definately recognises I have two cores, so is it currently using them, or will this be for /2?

It loads textures on secondary threads, but it can’t usefully do that for models because the geometry and octree data are required for important quantities like mass and collision radius (which also determines render distance).

[ZygoUgo]

Thanks Ahruman, it's interesting to get an insight under the bonnet

[Staer9]

Unfortunately my computer is one of the slow ones, so if it will run on this it will run on anything... if it runs at all.

[Svengali]

Unfortunately my computer is one of the slow ones, so if it will run on this it will run on anything... if it runs at all.

Maybe it will need some tweaks, but it will run - I'm pretty sure. So don't give up (and post a screenshot!) as we are keen to see it .-)
You'll also see that we are a friendly bunch here and help is in most cases not far away if you are running into trouble.

The discussions above are mostly about fine details that are often confusing in the beginning and Ahrumans explanations are a big help to create OXPs at a higher level. We are all learning and trying our best to reach the goal.

Some topics might be of interest for you:
- The Shipyard at the End of the Ooniverse. Modeller's bit.
- Shaders’ Outpost
- Skinner’s Den

[Staer9]

here is what it should look like when finished, (it is based on someone elses design.