I have a question,let's draw a triangle twice,the first time we put the triangle nearer but smaller,the second time we put the triangle farther but larger,we scale it elaborately so the result rendered image is exactly the same,can we say for sure the costs of the two draw are exactly the same?I ask because I am thinking about making the game map,if I scale the map up,the map becomes larger,but the drawing overhead my be roughly the same,it means I can enlarge the map cost-free.Am I missing something?BTW,I am thinking use this technique only for unreachable landscapes far away,

PolarWolf said:
can we say for sure the costs of the two draw are exactly the same?

Yes.

PolarWolf said:
Am I missing something?

No.

The idea you have is the same as ‘levels of detail’ (LOD). Using low detail for distant geometry and high detail for close up stuff.
If the playable area is small enough, you can get away with having just one level of detail for everything, because distant mountains remain far away no matter where the player is.
For close up stuff this won't hold, but if you don't need very high detail, e.g. because architecture is flat, or you have some low poly artstyle, having just one detail level is fine (and even the norm for static geometry in most games).

Multiple levels of detail per object are commonly used for things like characters, or a limited amount of static models in the scene.
For terrain made from hightmaps, it is quite easy to have some LOD which is not constant per model (discrete LOD), but varies across the same model (continuous LOD).
Making continuous LOD work on any geometry is hard and almost never done. UE5 Nanite is pretty much the first general solution shown to this problem.
Another related technique is Impostors, which is rendering distant 3D stuff to a billboard sprite, and then rendering just the sprite instead the 3D stuff. Often used for distant trees, but can work for buildings as well.

“The idea you have is the same as ‘levels of detail’ (LOD)” Never think of it it's so true,I read your reply several times,and learned much more than expected,Thank you.

@Thaumaturge You are so true,indeed I am thinking about this myself,making the game scene efficient and easy to cull is one of the most tricky problems so far.

Well, if you scale the scene and the camera is the origin of scaling, culling results remain the same too. (assuming far and near clip plane have little effect)
Of course if you would have a miniature version of the whole map, and display that on a table in front of the camera, it would cause a difference.

What does have a big impact on culling however is the field of view angle. If it's wide, you see more stuff and less is culled.

Merging many models into one as discussed yesterday also reduces the advantage of culling. If we make the whole map just one model to draw it with a single draw call, culling would become pointless.
So we want to form spatially compact clusters to keep culling efficient.

I am thinking of divide the map into chucks which can be culled separately,and so far I think it's very complicated.for the far away unreachable landscape and sky box,I want to use very large triangles,not only to reduce vertices count,what is more important,I think if the tirangle count is reduced,opengl will cull them more efficiently,but not sure about this,still finding information to confirm this.

PolarWolf said:
still finding information to confirm this.

The best you can do is profiling to see the difference from various compromises. Unfortunately GPUs and drivers also make a big difference, so ideally you would have NV, AMD, and now Intel GPU to test.

But in general we can assume vertex count has not much affect on performance. Usually it is pixel shaders causing the most cost. It's only important triangles are not too small (less than 10 pixels), because then any GPU becomes inefficient.
Using very large triangles probably gives not so much benefit in most cases. But ofc. it depends on your targeted detail.

PolarWolf said:
opengl will cull them more efficiently

OpenGL is not responsible for culling. You are. You should have a frustum test to cull a model. Usually that's just testing the bounding box of the model against the frustum planes. If you don't have this yet, it's worth it for sure.
GPUs nowadays do some triangle culling, but they still need to transform all the vertices first.

Beside frustum culling, there is trivial backface culling, which OpenGL does fine.

And there is occlusion culling, meaning to cull an object if it is hidden behind other objects in front of it. But that's hard and still an open problem. Current solutions mostly do it using a Z pyramid of the re-projected previous frame.
That's GPU compute driven rendering then. If you go there, you could also do things like backface culling of small triangle clusters based on their normal cone, moving the whole culling pipeline to GPU.
However, that's pretty advanced and time consuming stuff. Likely you want to avoid such things and instead tone visual fidelity down so the traditional methods suffice.

I really recommend using GPU profiling tool(s), and learning what it tells you. Otherwise you always make just assumptions, and may optimize the wrong things.

JoeJ said:
GPUs nowadays do some triangle culling

This is what I mean,maybe in vertex shader or after but before fragment shader,when the 3 vertices of a triangle are all out of view,the pipe line will cull out this triangle,and if a triangle is partially visible,the pipe line will cull out the invisible part,in both cases the cull happens once per triangle,that's why I assum less triangle count make the pipe line cull more efficient.

Yes, I am planning to add frustum test,I think it's surely profitable.

As of occlusion culling,I think the overhead will be too much and too complicated so it's not in plan.

I am sure GPU profiling tool is a must.thanks a lot.