Animation properties/export
Home › Forums › TimelineFX Editor › Animation properties/export
- This topic has 10 replies, 2 voices, and was last updated 14 years ago by imported_peterigz.
-
AuthorPosts
-
November 3, 2010 at 5:59 am #3202
DarkcoderParticipantMaybe I should just make one massive thread for all my nit pickings 🙂 .
Anyway, I’ve been doing some more work with TimelineFX and noticed a few more things that could do with changing in the Animation Properties/export window:
– The preview zoom slider changes the preview resolution rather than just the size, so zooming in is kind of pointless, as it doesn’t give you an accurate preview of the final animation.
– Changing the cell size doesn’t alter the animation’s zoom, so every time you change it, you must alter the zoom manually, maybe there could be a tickbox to change this?
– A button or something to calculate the amount of frames in the animation until all the particles die would be useful.
– I’m not sure if I would need this feature, but: An option to have the auto-fit keep the emitter centred may be useful, as certain particles such as point sprites don’t easily allow you to offset them, and it may make it easier to handle explosions and stuff.
– Having the ability to anti-alias the final output would be very nice, this can just be as simple as raising the cell size by 2x on each axis and downsampling for 4xAA, of course this would have to be optional, and maybe allow the user to specify the amount, as certain pixel effects look better without, but rain and such would benefit. I know this can kind of be done manually by exporting a larger animation and scaling it down manually, but in doing so you end up with seams at the edges as image editors have no notion of edges to cells.
– The animation preview should have an option to tile the animation for seamless animations, this would easily allow you to see how well water looks when tiled many times etc.
– There should be a button that randomizes the seed and automatically updates the animation, it’s quite tedious manually entering numbers and hitting update until you find the perfect animation.
– Perhaps a notice that changes have been made to the animation that require you to press update, right now the zoom at the bottom left works fine without update for non seamless animations, but for seamless ones it merely scales the particles up and not the animation before you hit update, this is a bit confusing.
– The zoom slider at the bottom left needs arrows to step the zoom by 1, right now it moves by about 15 when I move my mouse, and when typing in new values manually I must hit enter/return before it actually changes, this can be a bit confusing too.
– On the export animation dialogue you can specify a border, this is currently not that useful because usually the purpose of a border is to eliminate texture bleeding by separating the cells, but right now the border is just transparent, so the edges of animations just bleed into transparency which is still noticeable. For seamless textures, the solution is to colour the border with the colour from the other end of the texture, i.e. seamlessly tiling the current frame in the border. This will retain seamless graphics and will even work with mip-mapping if the border is thick enough. Of course this bleeding issue can be programmatically removed by scaling the UVs inside each cell by half a pixel, though it would be slightly faster to fix it in the texture.
– Also on the export animation dialogue, you can specify Sprite Sheet or Strip, it would be even more useful if we could specify a specific x/y size(or at least x, as y can be inferred), because right now it sometimes exports sizes that waste space or are otherwise undesirable. For example: 36 frame 128*128 maps to 8*5 which wastes 4 cells, I assume this is because you round the X up to the nearest power of two?
That’s about it for now. 🙂
November 3, 2010 at 8:41 am #3799
imported_peterigzParticipantThanks, I’m currently in “update mode” at the moment so I’ll try and stick as many of these changes in as possible, they seem to make sense. It’s always really helpful for me to hear these as I get so used to working with it myself it becomes harder to think outside the box! 🙂
What do you mean with the preview slider btw? I put that in mainly for very large animations where the frame size doesn’t fit in the window, so you can just zoom out to see it all.
I quick work around for the other zoom slider – once you clicked on it you can use the mouse wheel to move 1% at a time, but obviously the buttons would help.
November 3, 2010 at 11:32 am #3800
DarkcoderParticipant@peterigz wrote:
Thanks, I’m currently in “update mode” at the moment so I’ll try and stick as many of these changes in as possible, they seem to make sense. It’s always really helpful for me to hear these as I get so used to working with it myself it becomes harder to think outside the box! 🙂
Which is something I should learn to do with my games! (Especially where difficulty is concerned)
@peterigz wrote:
What do you mean with the preview slider btw? I put that in mainly for very large animations where the frame size doesn’t fit in the window, so you can just zoom out to see it all.
THIS image should illustrate what I’m on about.
@peterigz wrote:
I quick work around for the other zoom slider – once you clicked on it you can use the mouse wheel to move 1% at a time, but obviously the buttons would help.
I didn’t notice that, cool.
November 3, 2010 at 7:45 pm #3801
imported_peterigzParticipantoic what you mean now. There’s probably not a lot I can do about that. To have it the work that way it’d have to render each frame every time you make a change which would impact performance quite a bit. The preview just renders in opengl and only commits to a bitmap once you export. Hopefully it’s not too much of a big issue though.
November 4, 2010 at 2:32 am #3802
DarkcoderParticipantCan’t you first render the camera to a render target surface whose resolution is what I specify as the cell size and that’s applied to a rect that’s stretched over the screen and you just remove filtering on it? I have no idea what the editor is written in, but if it supports render targets and drawing sprites to them then there should be practically no overhead to doing this.
November 4, 2010 at 8:47 pm #3803
imported_peterigzParticipantNot without a lot of extra work unfortunately. This is coded in Blitzmax which doesn’t have render to texture ability, so I’d have to implement my own function. If I get lot’s of requests for it though I might get around to it 🙂
November 6, 2010 at 6:13 pm #3804
imported_peterigzParticipantWith regards to to the border, should you not just copy the pixels out to the edge (depending on the amount of border) ? But then if you do that it would lose its seamlessness? The same would happen if you copied from the opposite edge if you had a larger then 1 border. I think anyway… I might be getting confused (which I probably am!) but I’m starting to think that borders are only really useful for tilemaps, whereas this is just creating seamless textures which could be sorted by clamping uvs? or something…
November 9, 2010 at 9:00 am #3805
DarkcoderParticipant@peterigz wrote:
With regards to to the border, should you not just copy the pixels out to the edge (depending on the amount of border) ? But then if you do that it would lose its seamlessness? The same would happen if you copied from the opposite edge if you had a larger then 1 border. I think anyway… I might be getting confused (which I probably am!) but I’m starting to think that borders are only really useful for tilemaps, whereas this is just creating seamless textures which could be sorted by clamping uvs? or something…
Copying images out of the tile sheet is incredibly inefficient as it’ll require changing the texture between draw calls if each sprite uses a different frame, right now I can just change the UV for each rect(or vertex, for point sprites) and simply draw hundreds of animated particles in one go, which is very efficient. However, this also means that the whole animation is shared across the texture, so clamping doesn’t do anything useful. This is why having a border that has the tiling built in saves some computation, right now I’m offsetting the UVs into each cell by half a pixel so it’s not an issue for me. It just struck me as strange, as I don’t see how a transparent border would be useful. I’ve seen coloured(i.e. pink) borders used in complex animation sheets for characters and stuff, but these particle sheets always contain different sized cells, TimelineFX exports each cell as the same size so I’m not sure how useful such a border would be.
November 13, 2010 at 2:53 pm #3807
imported_peterigzParticipantYeh, with the thing I was saying about copying the texture out to the border I was referring to how timelinefx should be adding the border. And yes ignore what i was saying about clamping I was definitely getting confused there! 🙂
Anyway, almost all those features you mentioned in the first post are in now and ready for the next update, I’m trying to test it a bit before I release.
November 13, 2010 at 3:57 pm #3809
DarkcoderParticipant@peterigz wrote:
Yeh, with the thing I was saying about copying the texture out to the border I was referring to how timelinefx should be adding the border. And yes ignore what i was saying about clamping I was definitely getting confused there! 🙂
Ah, in that case, I was pretty much requesting the ability to select between these:
Maybe add in UV mirror too, for good measure. (though thinking about it I can’t actually think of any time where this would be useful in this scenario)
@peterigz wrote:
Anyway, almost all those features you mentioned in the first post are in now and ready for the next update, I’m trying to test it a bit before I release.
Awesome!
November 14, 2010 at 7:49 pm #3810
imported_peterigzParticipantThat makes it a lot clearer, thanks 🙂
-
AuthorPosts
You must be logged in to reply to this topic.