AxTile.uvOffset + AxTile.uvBounds for Tile scroll animation

Discuss suggestions to improve the Axel library.

AxTile.uvOffset + AxTile.uvBounds for Tile scroll animation

Postby chamberlainpi » Fri Apr 27, 2012 6:51 pm

This may be a large request... but here it is!

It would be interesting to have a way to specify a uvOffset (typed as AxPoint) for tiles, to make seamless texture-wrapping animations. This could be applied to water, lava, race-track "dash" zones, etc.

A Texture file may potentially contain various artwork, such as: normal static tiles, animated tiles and even static / animated Sprites. Because other sprites would co-exists in the same Texture, wrapping would not work properly with the current vertex/fragment shader. Neighbouring sprites on the spritesheet would leak through.

This is why I'm thinking that a uvBounds (typed as AxRect) would be important to specify when initializing. I haven't quite thought of it all through, but perhaps these uvBounds would have to be fed through a VertexBuffer, or maybe as Vertex Constants with a VertexBuffer that holds indices which, onced passed in the vertex-shader, will refer to the associated Vertex-Constant holding the uvBounds of that specific Tile type.

It would make sense to animate all the tiles of one type in sync, and I believe with the above description, that could be achieved.

I could perhaps build a small prototype as a demonstration.
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby Arkeus » Fri Apr 27, 2012 7:08 pm

So I'm not sure I entirely follow. I've thought about animated tiles in tilemaps a lot, and I have ideas how limited animation could be achieved without losing performance, but you would be limited to a certain number of frames. Because all the tiles are drawing in a single pass, you can't simple pass through animation data in constants to the shaders, it would have to be part of the vertex buffer. You can't compute this on the fly because you don't want to have to reupload the vertex buffer every frame. You're not going through and calling update() on every tile or anything either (which is what makes tilemaps so fast), though that doesn't matter much because unlike sprites you aren't drawing them separately. However, if you feel you can build a prototype, I'd love to see if to see if I can get some insight into it more.

My idea was to have every vertex in the vertex buffer include an extra 6 or so entries that could refer to tile offsets, and I should be able to calculate animations based on that, but you would be limited to 6 frames (or however many I put in there, perhaps 4). Adding more adds tons of data to be uploaded to the GPU and adds loading time when the map is created or edited (though you can't edit yet), so keeping that down would be good. I think it would be possible to also add a framerate number, and calculate the current frame via the shader. However, this would greatly complicate the shaders which could hurt performance. I could have a flag you set when creating the map that tells it if its animated so it wouldn't affect performance of non-animated maps.

There's tons of think about, and I haven't gotten far enough to really put some thought into it or prototype it, so there may be tons of things I haven't thought about, but that's my current view on it. But again, if you have a different idea, I'd love to see it. Just remember that small things can cause huge performance issues, since even a 200x200 tilemap has up to 40,000 tiles. :)
Image
User avatar
Arkeus
Site Admin
 
Posts: 363
Joined: Mon Mar 26, 2012 12:43 am

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby chamberlainpi » Fri Apr 27, 2012 7:25 pm

Yeah a 6 frame limitation might not be too bad, it would be sufficient frames to trick the eye thinking it's scrolling.

What I'm thinking I'll use in my prototype are some form of dynamically addressed constants by their index.

For example, say we have this data for one tile:

vertex-buffer (va0 & va1)
//x, y, u, v
0, 0, 0, 0,
16, 0, 1, 0,
16, 16, 1, 1,
0, 16, 0, 1

vertex-buffer (va2)
//constant-index, ?, ?, ?,
1, 0, 0, 0,
1, 0, 0, 0,
1, 0, 0, 0,
1, 0, 0, 0

vertex-constants #1: uvOffset.x, uvOffset.y, uvBounds.width, uvBounds.height

The vertex-shader could access vc1 like this:
mov vt1, vc[va2.x];

Admittedly, I've just tossed those numbers and I'm not even sure what would go in the vertex-constants yet. But basically, once you have the vertex-buffer setup once (like you said, re-uploading per frame would yield poor performance), then you can control that tile-type via the vertex-constant. It would be like each tile types own their own vertex-constant, in a way.

I'll think more about it, not that easy to explain nor to prototype!
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby chamberlainpi » Tue May 01, 2012 6:27 am

DUUUUUUUUDE..... I did it!

At least I think it will work for many tiles! I've only tested with a Quad so far.

So basically, I'm thinking this will either be a neat Shader to use on tilemaps, or even just any Quads that requires some form of scrollable UV animation.

Total opcodes?

8 in the vertex-shader, 7 in the fragment-shader.

Depending on how many tile scrolling-animations you want going at any given time, you will basically need:

Constant 0: reserved for the camera matrix (takes up vertex-constant 0 to 3)
Constant N: The UV-Offset of a specific tile-type (can be thought as a group)
Constant N+1: The UV Start X & Y, and Width & Height of the tile texture (so the sampling is always confined in those boundaries)

The VertexBuffer will basically be the same enumeration that exists in AxTilemap, where "va0" supplies the X & Y of each vertices, and "va1" supplies the UVs (which just needs to be set as a range of 0-to-1, I'll explain...).
Another vertexbuffer however will be required, "va2", to supply the association between tiles and Vertex-Constants (Basically, these Constant IDs will indicate where should the tiles find their actual UV details & offset information).

Since the camera takes a bit of room, I've started this vertexbuffer with 4 as the Constant ID storing the offset, and 5 as the Constant ID storing the Start X&Y + Width&Height

Here is a running example (might need to right-click & download to test it at the correct dimensions, just the bare SWF for now):
http://pierrechamberlain.ca/blog/wp-content/uploads/2012/05/TextureScrollingPatterns.swf

Click: Will change between the 4 possible tiles (all from the same texture, but samples from different UVs).

(NOTE: After running it on another computer, I noticed it works okay for the most part, but occasionally will reveal the "seems" of neighboring textures. This could be dealt with by tightening up the sampling area ever so slightly!)
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby Arkeus » Tue May 01, 2012 11:20 am

Hmm, I think I just don't understand what "uv scrolling" actually is! I'll take a look at this when I get home tonight since it doesn't seem to run at work.

As for your tweet and your note at the end, I don't think I'm currently using epsilon for tightening the uv area for texturing, but I haven't seen an issue since the quads I draw aren't antialiased, so I haven't seen any bleeding. But I think it might make sense for me to add it anyway, if it doesn't cause any problems. I remember reading something where someone said you should have space between all your sprites in a texture, but I don't like that method...
Image
User avatar
Arkeus
Site Admin
 
Posts: 363
Joined: Mon Mar 26, 2012 12:43 am

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby Arkeus » Tue May 01, 2012 7:10 pm

Oh, so it's like a single tile, but it scrolls and repeats? That is totally different than what I was thinking about (though in the process of trying to understand I may have come up with a solid solution to my animated tiles problem!)

It's actually neat, and could definitely be useful. I'm not entirely sure how generic it is though, so I'm not sure it would fit in the base library, but I definitely see this being really useful for some projects!
Image
User avatar
Arkeus
Site Admin
 
Posts: 363
Joined: Mon Mar 26, 2012 12:43 am

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby chamberlainpi » Wed May 02, 2012 4:46 am

Yeah exactly, it scrolls and repeats, and does its sampling from one single texture :) I tend to just leave the UVs from 0 to 1 in the vertex-buffer (va1) since the actual UV coordinates will be obtained from the vertex-constant -> then passed to a variant for the fragment-shader.

But anyways... yeah it may not be generic enough to use in AxTilemap, but I was thinking maybe a new class in the same package could be a good fit for this one. I'm not sure if it's better that I just provide the class on my own site along with a link to Axel, or... that it gets included in the Axel library. Personally, I'd like to call it "AxTileScrollMap", but I'm entirely open to other names / suggestions!

And actually, about the opcodes count... I had to bump up the vertex-shader with an extra operation, and it's a very mind-boggling issue...

Have you ever had an issue where "swizzling" didn't make the correct results, so you had to split up the opcodes instructions in separate lines (only operating on one register's field at a time)? I've had that frustrating experience with a couple of simple lines in my vertex-shader. It defeats the purpose of calling some of those opcodes "componentwise", I think anyways! I could try to explain this better if it doesn't make sense.

During my evenings, I'll be cleaning-up my UV Scroll Tilemap class so that its more independent and I will test that it can (in fact) run more than one tile at a time! Yesterday, it looked like I had my VertexBuffer / IndexBuffer data all messed up (although I did see some weird... twisted triangles on the screen) - but I know I'm getting close!

I'll keep you posted ;)
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby chamberlainpi » Wed May 02, 2012 6:55 pm

Here's my latest example:

(Right-Click and Download to see)
http://pierrechamberlain.ca/blog/wp-content/uploads/2012/05/TextureUVScrolling.swf

Blog article coming up soon (probably tomorrow, it's getting late... eyes... are... closing by themselves...)
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby chamberlainpi » Thu May 03, 2012 9:52 am

Here's the complete blog post that I wrote today:
Image
http://bit.ly/Jujtgj

I will try to make classes to be closely tied with Axel in the near future. Will let you know when I put those up!
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby Arkeus » Thu May 03, 2012 6:03 pm

That's a really nice article! And you're right, the example is very trippy. Definitely useful for anyone who needs some kind of scrolling effect in their sprites or maps.
Image
User avatar
Arkeus
Site Admin
 
Posts: 363
Joined: Mon Mar 26, 2012 12:43 am

Next

Return to Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest

cron