Trying to render a quad with 16 smaller textures ( as in a 4 x 4 grid ). Thought of the approach in 1 smaller quad to a texture and creating a quad tree…
Maybe its viable to do replace the quad with a triangle strip, but Im still lost in setting the 16 smaller textures on the one spatial
If there are any demos, pls say.
If there are no demos, point me in the right direction and i will create a demo for the JME tests.
Let me see if I understand correctly… Would 16 quads, each with its own texture not solve the problem? Do you really want only one quad? If so, why don't you create the texture on the fly by creating an image and painting the 16 textures in it (on the appropriate place), and then apply this new texture to the quad?
duenez said:
Let me see if I understand correctly... Would 16 quads, each with its own texture not solve the problem? Do you really want only one quad? If so, why don't you create the texture on the fly by creating an image and painting the 16 textures in it (on the appropriate place), and then apply this new texture to the quad?
Im making an embedded 2d tiled game like command and conquer / warcraft etc.
The tile set contains small images that are reused.
There can be 512 * 512 blocks. Each containing 16 quads.
if I would like to cut down on the added overhead of the vertices for the small quads within a block, they simply would not serve any purpose in being a geometry as the custom quad tree takes care of culling
any computer built since 2004 will be able to handle 512*512 simple quads, even if they have to be rendered all at once, which won't even be the case here.
512 * 512 textures each with a resolution of 128 * 128. Ok some may be repeated but its still a hell of alot memory and loading time just the board.
Can someone please verify it it is possible to apply many opaque textures with differing coordianate offsets to a single SceneElement.
hate to repost, but is it possible to render many textures to a single SceneElement without using more than one texture unit
maybe using a shared node for the quad would avoid the issue of many superflous quads ??
well i would reccomend you to create one big texture with all the tiles you need. and then when you want to accses a certain tile you supply it's UV coordinates in the texture.
This way you can have one TriMesh with one texture. ( but i doubt this will speed things up much, or at all )
Sasa said:
( but i doubt this will speed things up much, or at all )
I think it will. It's a technique called "texture atlas", nvidia has some good papers about it on their site.
It can speed up rendering, because there's no need to switch states any more between rendering your individual quads.
(At least that was true some time ago for jME/lwjgl, I experimented with something the like and got great speedups. With today's batches, and renderstate sorting, and possible other improvements, the performance increase may not be that significant.)
However, when using (auto generated) mipmaps texture atlases have a nasty downside - color bleeding between the distinct texture tiles adjacent in your texture atlas. Nvidia's papers offer some thoughts on solutions for that.
Yes, like hevee already says, this is only a problem for autogenerated mipmaps. You can always supply your own mipmaps with no bleeding.
nice, thanks, ill have to get the manual out for this and read up…