0
\$\begingroup\$

I've run into a problem where some of the models that I'm loading can have very large textures (2000x2000 for example). While my desktop computer can load them just fine, my laptop gets a segfault at the glTexImage call. I've thought of a couple of things I can do in this situation:

  1. Before giving the image to OpenGL, I could downscale it so it's below the max texture size, but I'm not sure how to then stretch the image to its original width and height

  2. I could also outright refuse to load the texture, and replace it with a generic repeating texture, like Valve's black and purple grid, but this isn't at all reliable or desired

Are these two options viable? How is it done with game engines like Unity or Source? Are there any other options that are better than my ideas?

\$\endgroup\$
  • \$\begingroup\$ segault seems like the wrong reaction to an out of memory, are you sure you validate every memory-allocation? \$\endgroup\$ – tkausl Oct 13 '16 at 10:59
  • \$\begingroup\$ @tkausl How do you mean validate memory allocation? \$\endgroup\$ – Orfby Oct 13 '16 at 11:42
  • \$\begingroup\$ If pointers are valid, i.e. malloc doesn't return nullptr and so on \$\endgroup\$ – tkausl Oct 13 '16 at 12:09
  • \$\begingroup\$ @tkausl The image data is valid, and it generates/loads/binds other (smaller) textures before loading the larger texture successfully \$\endgroup\$ – Orfby Oct 13 '16 at 12:42
1
\$\begingroup\$

I had encountered the same issue when handling textures of size 2048x2048 in iOS. It would simply crash because of memory constraints.

As you stated, i had a threshold of 1024px for either width or height of the image. If it crossed the threshold, i simply downsized it to another image preserving the aspect ratio. There would be platform based image resize APIs which would take care of this. Or else you can definitely find some C code which does this.

One another option is to convert the textures to PVRT format offline & use them. They are very lightweight. There will be loss in quality & we'll have to make sure the target hardware supports PVR textures.

\$\endgroup\$
0
\$\begingroup\$

The best thing that you can do not use that large objects. Using them can cost some problems, and not just with texture sizes. This is a list of problems that it can bring:

    • Collision detection. If you use too large objects the BSP Tress gonna need to chop bounding collisions or it can turn inneficient.
    • Huge amount of time wasted drawing textures and vertex that wont be at screen. You can solve it with a Frustum culling special for this type of objects, like we usually use for terrains
    • If you use frustum for this type of elements, the time that it needs to actually check all vertex.
    • The ammount of memory picks for loading or deleting this textures can bring you another problems.

    Large textures are good just for animating, but even with that if the resolution required is too large, is better chop them in smaller textures and use a index map.

    You can also scale the objects, but be careful with the bounding for collisions for this object.

    \$\endgroup\$

    Your Answer

    By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

    Not the answer you're looking for? Browse other questions tagged or ask your own question.