A technical question, but is graphics.generateTexture culled by the viewport or camera?
I’m trying to use it to save to TextureManager to save memory, however when the graphic is converted, it seems to be partially culled by the camera’s bounds.
When I redraw the graphic as a texture loaded to a sprite, the graphic is cut-off by the original relative edges of the camera - if that makes any sense?
So to show by example: I’m drawing a grid of polygons arranged across the gameplay area. The grid is represented (for now) as stroked rectangles. Each graphic, once drawn using strokePoints etc. invokes generateTexture and then destroyed - a sprite then positioned. So below is the right edge of the game, where some rectangles are partially obscured…
However, once I move the camera to see the rest of the grid, the partially obscured rectangles are cut off at where the relative edges of the camera would have been. So as the first paragraph says: is this a flaw in generateTexture, that the graphic needs to be visible within the viewport / camera when being generated - and can this be overriden?
generateTexture takes additional arguments to determine the width and height of the texture. By default, it uses the size of the game canvas. This is necessary because graphics objects are just a sequence of commands with no intrinsic size.
Keep in mind that large textures may not be supported by all devices, especially when using the WebGL renderer. 4096 pixels is a decent limit to stick to. Do also note that a graphics object will almost certainly use less memory than a texture at the cost of being more expensive to draw.
1 Like
Ah, yes. The width and height. Ok, that makes sense and would explain the culling. The problem for me now is keeping the original position of each poly so that the patchwork persists - but that’s my problem 
Re. texture sizes, I appreciate there’s hard limits all right; the textures shouldn’t be too large in real world examples. Interesting point about keeping them as graphics.
My original thinking was that I draw “white” lines, store as textures then simply use setTint to manage the custom colours needed. The theory being that this would be cheaper than re-drawing the graphics object when I needed to update the colour
It depends on how often you need to change the color, what you’re trying to optimize for, and how complex the graphics are. Tints are practically free. Changing colors in a Graphics object requires you to redraw it, which could either be cheap (the drawing operations only push to an internal array of commands) or somewhat expensive (in case you need to do a lot of calculations and do it often).
Realistically, it’s likely the deciding factor is going to be the size and complexity of the shapes. Graphics objects re-render their entire contents every frame, which can very quickly become expensive. Textures, on the other hand, are much cheaper, but often require more memory.
