Technical issues that you can help out with

Forum for game modifications and custom clients.

Technical issues that you can help out with

Postby loftar » Fri Aug 03, 2012 5:00 am

Sublime as though my existence may seem, only the Lord can claim perfection; and lacking it, then, myself, there exist things that I do not know. As such, I thought I'd put together this little list of things that technically astute readers of the forums can help out with if they like.

  • The client packs certain textures (tiles, particularly) into packed textures ("texture atlases", if you will). How does one properly use linear filtering or multisampling on such textures without risking having texels picked outside the intended subtexture?

(I'm pretty sure there are more than one thing that I've had in mind, but since I can't think of the others right now, I'll expand the list over time.)
User avatar
loftar
 
Posts: 1021
Joined: Sun Jul 08, 2012 7:32 am
Location: In your character database, shuffling bits

Re: Technical issues that you can help out with

Postby APXEOLOG » Fri Aug 03, 2012 6:39 am

loftar wrote:The client packs certain textures (tiles, particularly) into packed textures ("texture atlases", if you will). How does one properly use linear filtering or multisampling on such textures without risking having texels picked outside the intended subtexture?


I see different solution for this problem.

1. While packing textures into altas you can add 1px transparent border between them, so there will be no problems with filtering.
2. You can add(1, 1) to ul and sub(2, 2) from size of textures while binding it. So the pixels for filtering will be actually taken from this texture.
3. The best solution seems to use native glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_[S|T], *);
khronos.org wrote:GL_CLAMP causes s coordinates to be clamped to the range [0, 1] and is useful for preventing wrapping artifacts when mapping a single image onto an object. GL_CLAMP_TO_EDGE causes s coordinates to be clamped to the range [ 1/2N , 1 - 1/2N ] , where N is the size of the texture in the direction of clamping.

http://www.khronos.org/opengles/documentation/opengles1_0/html/glTexParameter.html
You can call me 'arh'. No needs to distort my nickname :)
User avatar
APXEOLOG
 
Posts: 222
Joined: Wed Aug 01, 2012 4:23 am
Location: Russia, Murmansk

Re: Technical issues that you can help out with

Postby loftar » Fri Aug 03, 2012 6:49 am

APXEOLOG wrote:1. While packing textures into altas you can add 1px transparent border between them, so there will be no problems with filtering.

That's what I'm doing right now, but depending on perspective, it doesn't merely sample the immediately adjacent texels, but sometimes even further from that. It also has the rather grievous problem of preventing mipmapping, since subtextures are no longer aligned to power-of-two-coordinates.

APXEOLOG wrote:2. You can add(1, 1) to ul and sub(2, 2) from size of textures while binding it. So the pixels for filtering will be actually taken from this texture.

While being more mipmap-friendly, I can only assume it would have the same sampling problems as above. (And due to decreasing texture coordinate resolution in higher mipmap levels, the sampling problem would grow worse on said higher levels.)

APXEOLOG wrote:3. The best solution seems to use native glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_[S|T], *);
khronos.org wrote:GL_CLAMP causes s coordinates to be clamped to the range [0, 1] and is useful for preventing wrapping artifacts when mapping a single image onto an object. GL_CLAMP_TO_EDGE causes s coordinates to be clamped to the range [ 1/2N , 1 - 1/2N ] , where N is the size of the texture in the direction of clamping.

Well, the problem with that is indeed that it clamps to [0, 1], which is the range of the entire texture atlas, not the sub-parts of it that are used for individual tiles.
User avatar
loftar
 
Posts: 1021
Joined: Sun Jul 08, 2012 7:32 am
Location: In your character database, shuffling bits

Re: Technical issues that you can help out with

Postby APXEOLOG » Fri Aug 03, 2012 7:34 am

loftar wrote:That's what I'm doing right now, but depending on perspective, it doesn't merely sample the immediately adjacent texels, but sometimes even further from that. It also has the rather grievous problem of preventing mipmapping, since subtextures are no longer aligned to power-of-two-coordinates.


Atlases are good for textures that repeated for many times. For example when i packed all tiles in HnH into one atlas i got about +60 FPS, and UI packing gives me nearly nothing. I think you don't need mipmaps for tiles.

Also i'm sure the solution exists because all android-based games uses atlases and they haven't got problems with it
You can call me 'arh'. No needs to distort my nickname :)
User avatar
APXEOLOG
 
Posts: 222
Joined: Wed Aug 01, 2012 4:23 am
Location: Russia, Murmansk

Re: Technical issues that you can help out with

Postby EnderWiggin » Fri Aug 03, 2012 9:18 am

Will it be feasible to generate texture for each mapcut and then apply filter/mipmaps to it? I know, it would eat more memory, but how much more?
User avatar
EnderWiggin
 
Posts: 339
Joined: Wed Aug 01, 2012 9:12 am
Location: Ukraine

Re: Technical issues that you can help out with

Postby Sevenless » Fri Aug 03, 2012 1:55 pm

Was watching a google IO presentation and they mentioned using a program called TexturePacker that does this automatically and handles border issues for you.
It's been neat to see the evolution of a game. Salem has come so far, and still has far to go. Although frustrating, I think it's been an experience worth the effort.
User avatar
Sevenless
 
Posts: 1727
Joined: Wed Aug 01, 2012 1:57 am

Re: Technical issues that you can help out with

Postby sabinati » Fri Aug 03, 2012 3:30 pm

APXEOLOG wrote:I think you don't need mipmaps for tiles.


from an aesthetic standpoint, he does. imo.
Admin for Salem Wiki • Make suggestions or complaints in the Wiki Suggestion thread
User avatar
sabinati
 
Posts: 1135
Joined: Wed Aug 01, 2012 1:48 am

Re: Technical issues that you can help out with

Postby loftar » Fri Aug 03, 2012 4:30 pm

EnderWiggin wrote:Will it be feasible to generate texture for each mapcut and then apply filter/mipmaps to it? I know, it would eat more memory, but how much more?

I have considered that, but come to the conclusion that the memory requirement is too much, at least if the current texture resolution is to be preserved. Each tile is currently 128x128, so a mapcut of 25x25 tiles would be 3200x3200 pixels, or ~40 MB. There being up to 144 mapcuts cached at one time, then, I think you will come to the same conclusion. ;)

sabinati wrote:
APXEOLOG wrote:I think you don't need mipmaps for tiles.


from an aesthetic standpoint, he does. imo.

I agree.
User avatar
loftar
 
Posts: 1021
Joined: Sun Jul 08, 2012 7:32 am
Location: In your character database, shuffling bits

Re: Technical issues that you can help out with

Postby EnderWiggin » Fri Aug 03, 2012 5:31 pm

Then maybe have pre-generated mipmaps of whole atlas and then just map textures from appropriate atlas depending on distance to camera.
User avatar
EnderWiggin
 
Posts: 339
Joined: Wed Aug 01, 2012 9:12 am
Location: Ukraine

Re: Technical issues that you can help out with

Postby loftar » Fri Aug 03, 2012 7:38 pm

The problems with that are that 1) it's unnecessarily complex, both code-wise and performance-wise, and 2) it's not remotely as good, since the mipmap level must be chosen for an entire map-cut at a time, and not per fragment, and also precludes such things as anisotropic filtering.

One thing that would solve the problem for real is using array textures instead of packed textures, but those are unfortunately only available in programmed shader mode and even then only on newer cards.
User avatar
loftar
 
Posts: 1021
Joined: Sun Jul 08, 2012 7:32 am
Location: In your character database, shuffling bits

Next

Return to Artifice & Arcana

Who is online

Users browsing this forum: No registered users and 21 guests

cron