Updating 1 large texture or multiple small ones (Performance question)

Started by Mr_Chaos, October 27, 2014, 01:23:48 PM

Previous topic - Next topic

Mr_Chaos

I have some objects that I want to have a description on top of, my current solution is.

Make 32 transparent planes which are not visible from the start
For each plane make a texture (1024x128) for the text


  • On each drawcall, check each objects distance to the camera
  • If the distance is less than X

    • Get a plane and translate it to the correct location
    • Create a new texture with the correct String
    • Update the texture in the texture manager

My question is if this is the best way of doing it ?

My other suggestion would be to have 1 big texture instead of 32 small ones.
 






AGP

I think that if it's only 32 textures, it's probably easier to just go with that. But I'm almost positive that a single large one would be better both for performance and for memory (by a small margin in memory, because I don't think that textures have a large overhead).

EgonOlsen

 :-[Many small ones sound better to me in this case, because you are only updating some of the text at a time, if i got that right. Is it possible that all 32 objects are visible at once? If not, then maybe you can pool the plane objects and won't need all 32 of them.
If you don't update the textures at runtime, one large one might be better. But as AGP already said: It's unlikely that it really matters.

Mr_Chaos

Quote from: EgonOlsen on October 27, 2014, 06:26:46 PM
:-[Many small ones sound better to me in this case, because you are only updating some of the text at a time, if i got that right. Is it possible that all 32 objects are visible at once? If not, then maybe you can pool the plane objects and won't need all 32 of them.
If you don't update the textures at runtime, one large one might be better. But as AGP already said: It's unlikely that it really matters.

You're right I only update some of them, whenever the object is visible, all 32 being updated is a worst case scenario and doesn't happe very often.

Right now my problem is the hit I get when updating the texture, it brings the tablet to a crawl :/

EgonOlsen

Updating a texture is expensive in terms of performance. Are you actually creating new texture instances? In that case, consider to use an ITextureEffect implementation to update an existing texture instead of creating a new one.
Or use blitting from a texture that contains all letters to create your text output. Have a look at raft's GLFont class, that does a pretty good job with that.

Mr_Chaos

Quote from: EgonOlsen on October 28, 2014, 04:22:56 PM
Updating a texture is expensive in terms of performance. Are you actually creating new texture instances? In that case, consider to use an ITextureEffect implementation to update an existing texture instead of creating a new one.
Or use blitting from a texture that contains all letters to create your text output. Have a look at raft's GLFont class, that does a pretty good job with that.

Yes, I am creating a new Texture everytime, I'll look into ITextureEffect, and get back with some performance numbers.

Mr_Chaos

I think I found my problem and a new solution.

The problem was creating the texture(Without ITextureEffect) or modyfying the existing texture(With ITextureEffect).
Clearing the texture took 2ms and rendering the text took 4ms.

My new solution is to create one big texture with all letters and then making the Object3D plane consist of 12 squares and then change the UV coordinates of the vertixes to show the correct letters.

It takes less than 1 ms to update a plane, so the performance is there, but my problem is that if I run compile on the Object3D I think JPCT optimizes away some of the vertices and then I have a hard time using the PolygonManager to update them since they are missing (Hope this makes sense).


EgonOlsen

If you want to modify texture coordinates, you have to build the object with build(false); and call touch() after updating them. If you want to modify vertex coordinates, it's similar, but you have to use a variant of compile (...) that supports dynamic objects.

Mr_Chaos

I use the correct compile method, but I think my problem is vertixes having multiple texture coordinates.

Let's say i want to write the letters A and Z, A has texture coordinate(u(0.00->0.1), v(0.0->0.1) and Z has (u(0.9->1.0), v(09->1.0).

Then 2 of the vertixes will have both coordinates for A and Z

My current solution (not pretty) is to double the number of squares and only use one out of two.

I'll post some code later I someone else is having the same problem and maybee some of the experts can tell me how stupid the code is :)

EgonOlsen

Yes, vertices will be shared by default. You can disable it on an Object3D by calling disableVertexSharing();, but you have to create the mesh yourself then by using addTriangle or it will have no effect.

Mr_Chaos

Quote from: EgonOlsen on October 31, 2014, 06:04:52 PM
Yes, vertices will be shared by default. You can disable it on an Object3D by calling disableVertexSharing();, but you have to create the mesh yourself then by using addTriangle or it will have no effect.
If I had only known this (AKA read the javadoc before coding  ;)