# Optimization of big images render
**URL:** https://forum.castle-engine.io/t/optimization-of-big-images-render/1876
**Category:** Uncategorized
**Created:** [April 24, 2025, 10:13am UTC](https://forum.castle-engine.io/t/optimization-of-big-images-render/1876 "2025-04-24T10:13:25Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Noscow](https://forum.castle-engine.io/u/Noscow)
#### Post date: [April 24, 2025, 10:13am UTC](https://forum.castle-engine.io/t/optimization-of-big-images-render/1876/1 "2025-04-24T10:13:25Z")
Good day!
Finally, after few experiments with different visualization styles, I stay at 2D design for game environment.
I use big backgrounds, and that backgrounds scrolls at right and left with minimal parallax for imitation of stationary camera rotation.
But, as I understand, frustum culling works with whole objects, so, if only 20% of background in the field of view, engine will render all `ImageTransform` anyway? So, I must slice background at smallest transforms, for example 1024x1024? For now I haven’t problems with 6000x800 textures, but scene grows, and I want to account future problems for old computers.
Also, I use 3D Viewport for the skybox. I need it for one game mechanic… So, how game skyboxes renders? Usually player see only small part of them. Engine draw only those figure triangles, what are behind the camera? Can I make skybox as monolith thing, or better divide them to smaller parts?
To be more brief:
Is frustum culling work with whole shapes, or it can be used for single triangles or texture fragments?
Thanks 🙃
---
### Author:  [@kagamma](https://forum.castle-engine.io/u/kagamma)
#### Post date: [April 24, 2025, 11:48am UTC](https://forum.castle-engine.io/t/optimization-of-big-images-render/1876/2 "2025-04-24T11:48:02Z")
It does not matter how big your image is because the polygons that used to render the image will be sliced and discarded during [clipping operation](https://en.wikipedia.org/wiki/Graphics_pipeline#Clipping) at hardware level, so that only the parts that are visible on screen will be rasterized.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [April 24, 2025, 12:21pm UTC](https://forum.castle-engine.io/t/optimization-of-big-images-render/1876/3 "2025-04-24T12:21:47Z")
As for geometry:
- The “frustum culling” done by the Castle Game Engine indeed only works on whole shapes (we don’t send the shape to GPU, if the whole shape is definitely outside of the frustum).
- That said, GPU also does culling when rendering. It just rejects whole triangles, or cuts the triangle (calculates triangle or quad in the view) when only part of triangle is visible. So the excessive triangle pixels (outside the view) are not processed, but GPU spends time per-triangle to determine this.
- So, in total: Splitting into more shapes is somewhat beneficial (engine can do frustum culling on shapes, which can be a bit better than culling on triangles done by OpenGL, but _only if your shapes contain a lot of triangles_). On the other hand, less shapes are also beneficial (less “draw calls”, which means we pass data to GPU easier). So these 2 facts are a bit contradictory. See [Optimization and profiling | Manual | Castle Game Engine](https://castle-engine.io/manual_optimization.php#section_shapes) for more details.
- Note that when rendering using `TCastleImageTransform` and repeating your textures using [TCastleImageTransform.RepeatImage](https://castle-engine.io/apidoc/html/CastleScene.TCastleImageTransform.html#RepeatImage) you are actually always rendering only 1 quad (2 triangles). Even if repeat is (100,100), it is still only one quad. So you’re actually always good, and you don’t need to think about above balance (more shapes vs less shapes). You always only have 1 shape with 2 triangles even if repeat is (100,100) so it’s always going to be fast 🙂
As for textures:
- The textures are only calculated when the pixel is actually rendered. So only after something “survived” all the culling, from engine, from OpenGL, and early Z-test… only then is the texture actually calculated. And the cost is “per screen pixel”, not “per texture pixel”. So it doesn’t matter (well, to some extent…) how much is the texture stretched. So a texture with 4096x4096 and texture 4x4 has the same cost (time used for rendering), because ultimately both textures are sampled the same number of times.