Could you elaborate a bit more on event synchronization? As it stands, I was planning to attach a custom "Offset" field to each frame, and use it to offset the pivot in the viewer. I would then also export that field to the config file. I'd prefer to do it as "standard orx" as possible though.
Right now you can add custom events to animation frames, in config.
An event also comes with an optional numerical value that will be sent along the event.
I believe that's how sausage did his pixel-perfect synchronization by sending the amount of translation via those events and handling it in the code, isn't it?
Those events can be used for anything, really, from footstep sound/FX synchro to firing bullets, etc.
Looks nice! I'll implement this per-frame offset into the editor, right after finishing the Drag and Drop support I'm working on right now. (Drag and drop makes everything so much more natural )
Sausage, do you think this approach will fit your current purposes?
BTW, Iarwain, how would you go about, if you wanted to have an offset in X and Y? It seems that the event receives only a single float.
It should be everything you need. Explains how the eventvalues are stored in the animation frames and how the value is picked up in the event handler and used to update movement.
Really got to hit the hay. But I'll get my other examples to you tomorrow.
@sausage Thanks, this link should be enough for implementation. What does AR1 stand for BTW? Should I export this as the event name?
On a separate note, we've a new version of the editor up now. The changes are purely cosmetic, but I believe you'd like them. Now the Animation Manager supports conventional drag and drop with full visual feedback. You can even press CTRL while dragging to copy instead of move. The drag and drop support is purely within the Animation Manager for now, but I'll soon implement drag and drop for many operations between panels (such as for inserting an animation into an animation set).
There are many more tiny cosmetic changes (such as better visual feedback while editing the name of an object) that I don't even remember , but they make it more pleasant to use the editor.
The next item on the to-do list is to implement offsets then!
I'm back with yet another update, now we've frame offset support in the editor. I've tried to rebuild the config files for your tutorial; you can get the .oap (orx animation project) file (along with the image for convenience) [strike]here:[/strike](Sorry I've uploaded a new version)
Simply unzip this archive somewhere, download the latest editor version, and open the tutorial.oap in the editor. You can then see how the animations look with the offsets.
When you're done editing, you can then write to the target ini, I've already set it to be tutorial.ini. I'd be glad if you tried the resulting ini with the actual engine, and see if it works.
BTW, note that I'm also exporting an offset in y with an event name "AR2".
There's a new version of the editor up. With this update, drag and drop became quite robust and well-integrated. I've extended the drag and drop support to the animation set editor as well. So, you can now just add animations to an animation set by simply dragging them from the animation manager.
I've also removed the unnecessary "delete animation" and "delete link" buttons in the animation set editor, since now you can just do that by selecting and pressing delete.
The Animation Manager also behaves much more naturally. For instance, when you create a new frame inside an animation, the animation is automatically expanded and the new frame selected. You can then press Enter (new feature) to start editing its name.
In the next update, I'll make the whole export process much more robust, with some diagnostics. So that, what gets written to an .ini file will definitely reflect what you see in the editor. The problem right now, is that you can have duplicate names, and they'll be silently written, over-writing each other.
And in the update after that, I'll make some changes to the Animation Viewer, and you'll love it
Based on the current activity around the Orx Studio, you might have thought that the stand-alone animation editor has stopped development. Well, that's not true. I'm about to make a hefty update to the animation editor. I'm actually planning to call the animation editor at its beta stage with the update, because it will have all the features I thought I would add in the beginning.
There's one thing I'd like to discuss with you before I make this update though. As you know, a recent addition has been the frame offsets. Now they're in the editor, and with the coming update, they become very easy to edit, with 3 different ways to set them.
The problem is how to define the offsets. Currently, when you define an offset for a frame the following is written to the target config file:
One could of course do more efficient things like caching (though I don't know it that's really necessary).
How do you feel about this way of handling offsets?
Another point is about whether the offset is "in" or "out", I mean, is the offset applied before or after the frame? I personally thought that the offset of a frame should be applied when the frame is first shown, because it felt more natural. The editor currently assumes that's what you mean by the offset. Though another interpretation could be that the offset is applied at the end.
I have a feeling that the engine supports the latter better. If I'm not mistaken, the event synchronized to a frame is fired at the end of the frame. And further, that if an "immediate" animation link is followed, the event is never fired.
I'm really trying to decide which view is better and how one should implement it. When you actually consider the fact that the collisions are best handled before they take place, each frame defining the transition to the next makes sense. For instance, if the object has the running animation, and if you realize the object is going to collide with a wall in the next frame, you could immediately switch to the bumping animation and cancel the offset.
There's yet another point though: If you define offsets to be after-frame, then the first frame of every animation has to be static (or follows the offset from the previous animation). Take the running-bumping example above. You could want to come up with a sophisticated animation system, such that depending on the speed of collision, you want the object to bounce with different speeds, and for each different speed you have a different animation. In this scenario, simply canceling the frame offset in the event of a collision will not give you the fine control you might want (i.e. finer than simply either current frame offset or zero).
Now I conclude that the most general approach is to be able to define the offset both into and out of a frame. What do you think about the "in" "out" issue? and do you have any implementation suggestions?
nice update. I'm much too tired at the moment for thinking about the in/out issue, but I'm awake enough to ask a question:
why do you separate the offset components instead of having a vector?
why do you separate the offset components instead of having a vector?
Good point That's how it'll be in the update then.
As for the in/out issue, I've decided to stick to the "in" interpretation that's already in the editor. It just feels more natural that a frame carries the information of where the object "is" not where it "will be". As for pre-emptive collision handling, I'll find some other way of conveying the next frame position information on the C/C++ side. When you consider that there could be multiple choices for the next frame, you need a more general approach anyway.
My observation that a frame event is fired after the frame is correct, right? I guess that means I need to handle the first frame offset in the "OnAnim" callback.
I'm looking forward to pushing the update, I hope it'll be a useful tool.
"In" definitely feels like the way to go to me too.
As for the events, from memory, they get fired right after we've updated the current frame pointer: we then fire all the events that happened between last update and the current one.
It's supposed to be "simultaneous" from a logical point of view and should be considered as such. Both events and animation update will happen before any other logic or physics update can take place within the same frame.
If you'll fix that, than I won't touch the editor.
This brings us to the major update then! I've pushed the update to both the github repository, and also the .jar link. I would like to announce the animation editor to be in its beta stage! From now on, I'll stop adding features to it for a while (possibly forever considering the Orx Studio initiative), but I'll fix bugs when people spot them. I'm determined to keep the animation project files created from now on to be compatible with all future versions of the editor.
This final version of the editor contains the following new features:
- Config export diagnostics. Name collisions, invalid fields (such as no texture specified for a texture) etc. are detected while exporting to a config file, and reported.
- A more useful animation viewer. Now the viewer has a frame & animation queue to be displayed. The animation view display can also be panned and zoomed
- Tidier frame editor. Now all editing is done via right-clicking with the mouse. The behavior is set by the buttons on the toolbar.
- 2 additional ways of setting the offset of a frame, making pixel perfect animations much easier to specify.
- Specify a root folder (other than the target config file) for the image paths.
- Specify animation links as "immediate"
- Project changes are caught, and while closing a project, if there are any changes, a "save changes?" prompt is shown.
- Extended drag and drop support.
I hope you get a chance to review the current state of the animation editor. It ended up being a very lightweight (pocket size ) tool. I'd love to receive feedback!
I don't think I'll have time to try it over the week end but I'll try sometime next week.
As for orx, if you sync the hg repo on bitbucket, it should be fixed.
Last thing, would it be ok if I cloned your git repo on the official orx bitbucket site? (http://code.orx-project.org)
Even better, if you have an account there you could do it yourself.
I've just created a bitbucket account, my username is enobayram there as well. It's my first time with bitbucket, but I guess I need some write permissions, right? Also, should I clone it as a git repository or a mercurial repository (what a redundant question )?
If you think my chances of messing something up as a first-time mercurial user multiplied by the amount of time you'll have to spend cleaning it is higher than cloning it yourself, it's perfectly OK for me, if you choose to clone it yourself.
As a side question, what happened to the orx svn repository? Is it abandoned?
You now are part of the orx team on bitbucket, and as such have write access there, including adding new repositories.
There are already a mix of git and hg repo there, so it doesn't really matter much which one you choose I guess.
That being said, there isn't much chance you'd screw anything with hg as they both share the same philosophy and there's almost a 1:1 match between them.
The orx svn repo is going in read only mode and will stay up for reference (I didn't import all the closed branches in the hg repo to make it lighter) but no development will happen there anymore.
Exactly in the same way it happened with orx's previous sourceforge repo at http://sf.net/projects/arcallians, its first public home.
Mmh, have you tried cloning that new repo locally, add your files there, and then commit/push everything back to bitbucket?
Yes, that's what I've done, shouldn't I have? Is there a better way of importing from git to mercurial? Or are you referring to my point about the .jar file? I was talking about just the binary, which I think should be an individual download, right?
That being said, there isn't much chance you'd screw anything
Ah, OK, how do you suggest we distribute the binary then? After all, that's the best thing about a Java project. Should I keep the download link active at the beginning of this thread?
Well it worked for me so there's a version available for download but I'm not sure it's the latest one.
Well then, we've the latest version in the downloads for now. In the long run, I'll get down to the wiki as soon as I can, but still, there's the question: is there a preferred place to host the file?
As a side question, I've been trying to clone the orx hg repository, but it's a large chunk, and I've two connections, one of which is a very limited broadband, and the other is an unlimited but very unstable connection. So, I really have no way of cloning the repository at one go, to get started. Do you know of a solution for this?
Well it worked for me so there's a version available for download but I'm not sure it's the latest one.
Well then, we've the latest version in the downloads for now. In the long run, I'll get down to the wiki as soon as I can, but still, there's the question: is there a preferred place to host the file?
I usually offer some download space on orx's site with an associated sub-domain. If you're interested I'll be happy to set one up for you (comes with a FTP account, of course).
As a side question, I've been trying to clone the orx hg repository, but it's a large chunk, and I've two connections, one of which is a very limited broadband, and the other is an unlimited but very unstable connection. So, I really have no way of cloning the repository at one go, to get started. Do you know of a solution for this?
Mmh, I'm afraid I'm not expert enough in hg for that but I'd think there'd be ways of syncing partially a repo (or syncing the whole repo in a few tries).
Worst case scenario I can put a copy of the full repo somewhere that can be accessed via FTP.
I usually offer some download space on orx's site with an associated sub-domain. If you're interested I'll be happy to set one up for you (comes with a FTP account, of course).
That would be nice, I think it'd be neater if the binary were also hosted here. As for the wiki, I've created an account (guess with what username ) but I seem to need write permissions.
Worst case scenario I can put a copy of the full repo somewhere that can be accessed via FTP.
Thanks for offering this, but I've finally managed. In the end, I've written a script to pull the repository 10 revisions at a time , so it completed overnight. That means I've also tried the animation event firing issue, and it works correctly now, thanks
Comments
Could you elaborate a bit more on event synchronization? As it stands, I was planning to attach a custom "Offset" field to each frame, and use it to offset the pivot in the viewer. I would then also export that field to the config file. I'd prefer to do it as "standard orx" as possible though.
Right now you can add custom events to animation frames, in config.
An event also comes with an optional numerical value that will be sent along the event.
I believe that's how sausage did his pixel-perfect synchronization by sending the amount of translation via those events and handling it in the code, isn't it?
Those events can be used for anything, really, from footstep sound/FX synchro to firing bullets, etc.
More info on the current syntax here: http://orx-project.org/wiki/en/orx/config/settings_structure/orxanim
Sausage, do you think this approach will fit your current purposes?
BTW, Iarwain, how would you go about, if you wanted to have an offset in X and Y? It seems that the event receives only a single float.
Sorry, enobayram, I didn't get a chance to get that config to you today.
But in the mean time I did an explaiation of the method in the wiki here:
http://orx-project.org/wiki/en/orx/tutorials/community/sausage/realistic_walk_movement
It should be everything you need. Explains how the eventvalues are stored in the animation frames and how the value is picked up in the event handler and used to update movement.
Really got to hit the hay. But I'll get my other examples to you tomorrow.
@sausage Thanks, this link should be enough for implementation. What does AR1 stand for BTW? Should I export this as the event name?
On a separate note, we've a new version of the editor up now. The changes are purely cosmetic, but I believe you'd like them. Now the Animation Manager supports conventional drag and drop with full visual feedback. You can even press CTRL while dragging to copy instead of move. The drag and drop support is purely within the Animation Manager for now, but I'll soon implement drag and drop for many operations between panels (such as for inserting an animation into an animation set).
There are many more tiny cosmetic changes (such as better visual feedback while editing the name of an object) that I don't even remember
The next item on the to-do list is to implement offsets then!
I'm back with yet another update, now we've frame offset support in the editor. I've tried to rebuild the config files for your tutorial; you can get the .oap (orx animation project) file (along with the image for convenience) [strike]here:[/strike](Sorry I've uploaded a new version)
Simply unzip this archive somewhere, download the latest editor version, and open the tutorial.oap in the editor. You can then see how the animations look with the offsets.
When you're done editing, you can then write to the target ini, I've already set it to be tutorial.ini. I'd be glad if you tried the resulting ini with the actual engine, and see if it works.
BTW, note that I'm also exporting an offset in y with an event name "AR2".
https://forum.orx-project.org/uploads/legacy/fbfiles/files/Tutorial.zip
There's a new version of the editor up. With this update, drag and drop became quite robust and well-integrated. I've extended the drag and drop support to the animation set editor as well. So, you can now just add animations to an animation set by simply dragging them from the animation manager.
I've also removed the unnecessary "delete animation" and "delete link" buttons in the animation set editor, since now you can just do that by selecting and pressing delete.
The Animation Manager also behaves much more naturally. For instance, when you create a new frame inside an animation, the animation is automatically expanded and the new frame selected. You can then press Enter (new feature) to start editing its name.
In the next update, I'll make the whole export process much more robust, with some diagnostics. So that, what gets written to an .ini file will definitely reflect what you see in the editor. The problem right now, is that you can have duplicate names, and they'll be silently written, over-writing each other.
And in the update after that, I'll make some changes to the Animation Viewer, and you'll love it
Cheers!
Based on the current activity around the Orx Studio, you might have thought that the stand-alone animation editor has stopped development. Well, that's not true. I'm about to make a hefty update to the animation editor. I'm actually planning to call the animation editor at its beta stage with the update, because it will have all the features I thought I would add in the beginning.
There's one thing I'd like to discuss with you before I make this update though. As you know, a recent addition has been the frame offsets. Now they're in the editor, and with the coming update, they become very easy to edit, with 3 different ways to set them.
The problem is how to define the offsets. Currently, when you define an offset for a frame the following is written to the target config file:
So, the event handler can look like:
One could of course do more efficient things like caching (though I don't know it that's really necessary).
How do you feel about this way of handling offsets?
Another point is about whether the offset is "in" or "out", I mean, is the offset applied before or after the frame? I personally thought that the offset of a frame should be applied when the frame is first shown, because it felt more natural. The editor currently assumes that's what you mean by the offset. Though another interpretation could be that the offset is applied at the end.
I have a feeling that the engine supports the latter better. If I'm not mistaken, the event synchronized to a frame is fired at the end of the frame. And further, that if an "immediate" animation link is followed, the event is never fired.
I'm really trying to decide which view is better and how one should implement it. When you actually consider the fact that the collisions are best handled before they take place, each frame defining the transition to the next makes sense. For instance, if the object has the running animation, and if you realize the object is going to collide with a wall in the next frame, you could immediately switch to the bumping animation and cancel the offset.
There's yet another point though: If you define offsets to be after-frame, then the first frame of every animation has to be static (or follows the offset from the previous animation). Take the running-bumping example above. You could want to come up with a sophisticated animation system, such that depending on the speed of collision, you want the object to bounce with different speeds, and for each different speed you have a different animation. In this scenario, simply canceling the frame offset in the event of a collision will not give you the fine control you might want (i.e. finer than simply either current frame offset or zero).
Now I conclude that the most general approach is to be able to define the offset both into and out of a frame. What do you think about the "in" "out" issue? and do you have any implementation suggestions?
nice update. I'm much too tired at the moment for thinking about the in/out issue, but I'm awake enough to ask a question:
why do you separate the offset components instead of having a vector?
Something like this would still work:
Good point
As for the in/out issue, I've decided to stick to the "in" interpretation that's already in the editor. It just feels more natural that a frame carries the information of where the object "is" not where it "will be". As for pre-emptive collision handling, I'll find some other way of conveying the next frame position information on the C/C++ side. When you consider that there could be multiple choices for the next frame, you need a more general approach anyway.
My observation that a frame event is fired after the frame is correct, right? I guess that means I need to handle the first frame offset in the "OnAnim" callback.
I'm looking forward to pushing the update, I hope it'll be a useful tool.
Cheers
"In" definitely feels like the way to go to me too.
As for the events, from memory, they get fired right after we've updated the current frame pointer: we then fire all the events that happened between last update and the current one.
It's supposed to be "simultaneous" from a logical point of view and should be considered as such. Both events and animation update will happen before any other logic or physics update can take place within the same frame.
The animation config section
The code to handle the events:
A section from the program console output:
To me, this looks like KeyEventNameX is fired when KeyDataX is being discarded.
Cheers!
I'll fix that tonight.
This brings us to the major update then! I've pushed the update to both the github repository, and also the .jar link. I would like to announce the animation editor to be in its beta stage!
This final version of the editor contains the following new features:
- Config export diagnostics. Name collisions, invalid fields (such as no texture specified for a texture) etc. are detected while exporting to a config file, and reported.
- A more useful animation viewer. Now the viewer has a frame & animation queue to be displayed. The animation view display can also be panned and zoomed
- Tidier frame editor. Now all editing is done via right-clicking with the mouse. The behavior is set by the buttons on the toolbar.
- 2 additional ways of setting the offset of a frame, making pixel perfect animations much easier to specify.
- Specify a root folder (other than the target config file) for the image paths.
- Specify animation links as "immediate"
- Project changes are caught, and while closing a project, if there are any changes, a "save changes?" prompt is shown.
- Extended drag and drop support.
I hope you get a chance to review the current state of the animation editor. It ended up being a very lightweight (pocket size
Cheers!
I don't think I'll have time to try it over the week end but I'll try sometime next week.
As for orx, if you sync the hg repo on bitbucket, it should be fixed.
Last thing, would it be ok if I cloned your git repo on the official orx bitbucket site? (http://code.orx-project.org)
Even better, if you have an account there you could do it yourself.
I've just created a bitbucket account, my username is enobayram there as well. It's my first time with bitbucket, but I guess I need some write permissions, right? Also, should I clone it as a git repository or a mercurial repository (what a redundant question
If you think my chances of messing something up as a first-time mercurial user multiplied by the amount of time you'll have to spend cleaning it is higher than cloning it yourself, it's perfectly OK for me, if you choose to clone it yourself.
As a side question, what happened to the orx svn repository? Is it abandoned?
There are already a mix of git and hg repo there, so it doesn't really matter much which one you choose I guess.
That being said, there isn't much chance you'd screw anything with hg as they both share the same philosophy and there's almost a 1:1 match between them.
The orx svn repo is going in read only mode and will stay up for reference (I didn't import all the closed branches in the hg repo to make it lighter) but no development will happen there anymore.
Exactly in the same way it happened with orx's previous sourceforge repo at http://sf.net/projects/arcallians, its first public home.
I've added the Animation Editor repository. I couldn't upload the .jar file though; when I try to add it through the "downloads" tab, it always fails.
I'm glad that the Animation Editor is officially in, I hope it helps some people in the community.
Cheers!
Yes, that's what I've done, shouldn't I have? Is there a better way of importing from git to mercurial? Or are you referring to my point about the .jar file? I was talking about just the binary, which I think should be an individual download, right?
See, never underestimate people
If you wanted to keep the history, you could have cloned the git repo directly with hg (it can import hg, svn and some other popular VCSs directly).
As for the download part, haven't tried it myself, so not sure what can be done there.
A wiki page about the editor would make it easier to find all the info, including the download link I guess. :P
Well then, we've the latest version in the downloads for now. In the long run, I'll get down to the wiki as soon as I can, but still, there's the question: is there a preferred place to host the file?
As a side question, I've been trying to clone the orx hg repository, but it's a large chunk, and I've two connections, one of which is a very limited broadband, and the other is an unlimited but very unstable connection. So, I really have no way of cloning the repository at one go, to get started. Do you know of a solution for this?
I usually offer some download space on orx's site with an associated sub-domain. If you're interested I'll be happy to set one up for you (comes with a FTP account, of course).
Mmh, I'm afraid I'm not expert enough in hg for that but I'd think there'd be ways of syncing partially a repo (or syncing the whole repo in a few tries).
Worst case scenario I can put a copy of the full repo somewhere that can be accessed via FTP.
That would be nice, I think it'd be neater if the binary were also hosted here. As for the wiki, I've created an account (guess with what username
Thanks for offering this, but I've finally managed. In the end, I've written a script to pull the repository 10 revisions at a time