search

loopier / animatron-godot3

Yet another implementation of Animatron, but in Godot
GNU General Public License v3.0
17 stars 1 forks source link

Load sources dynamically #3

Closed totalgee closed 2 years ago

totalgee commented 3 years ago

From #1 :

I'd already started to look into what our options are here, as it was not evident at first look. It seems Godot normally requires/expects imported assets, which are converted to another format *.pck). That being said, there are ways to load images at runtime, which I plan to experiment with. At worst, we'll prepare an easy workflow to create the required "imported" (packed) data without rebuilding and exporting the Animatron project again

See: https://github.com/godotengine/godot-proposals/issues/1632

totalgee commented 3 years ago

Also, here's a "formula" to load an image into a texture at runtime:

func get_external_texture(path):
    var img = Image.new()
    img.load(path)
    var texture = ImageTexture.new()
    texture.create_from_image(img)
    return texture
totalgee commented 3 years ago

Initial version handled by dd1ce3b and a1c8e1f.

loopier commented 3 years ago

Cool. I have a stupid question: whay the _s? I thought you hated them. Since you told me you did I hate them, too, and changed to -. Should we stick to our taste?

totalgee commented 3 years ago

What do you mean, the underscores in the naming convention? It can be whatever. I noticed you used hyphen - in the anim names, so I wanted to allow those to continue. The _ is easy to parse as a "different" suffix to specify the NxM and fps parts... But the file naming convention can be anything you prefer, I don't mind!

| e.g. the-name-part_the_meta_part.png -> an anim called the-name-part

totalgee commented 3 years ago

Oh, I guess you meant in the code example above, duh. That's because it's an example I pasted from someone else. For variables and methods I do prefer camelCase, but it's not the standard with Godot (which definitely prefers snake_case). For our code, I've been sticking to my "usual" C++ approach of camelCase, in spite of the Godot convention. As long as we're consistent, it doesn't matter since it's our own code. But again, I'm open...

All Godot methods and properties are snake_case(). But you'll note that my version of the above function in our code is actually called getExternalTexture(). ;-)

totalgee commented 3 years ago

Next:

totalgee commented 3 years ago

Example/proposal of file layout for runtime animations:

runtime_data/
├── happy-walk.png
├── lazy-walk_4x4_12fps.png
├── pickaxe_6x4_24fps.png
├── thumbs-up/
│   ├── thumbs-up-01.png
│   └── thumbs-up-02.png
├── video/
│   ├── video-001.jpg
│   ├── video-002.jpg
│   ├── ...
│   └── video-120.jpg
├── walk/
│   ├── walk-n_4x4_24fps.png
│   ├── walk-ne_4x4_24fps.png
│   ├── walk-e_4x4_24fps.png
│   ├── walk-se_4x4_24fps.png
│   ├── walk-s_4x4_24fps.png
│   ├── walk-sw_4x4_24fps.png
│   ├── walk-w_4x4_24fps.png
│   └── walk-nw_4x4_24fps.png
└── zebra-jog_4x2_12fps.png

These would add the following animation types (that could be created using /create "bob" "thumbs-up"):

happy-walk, lazy-walk, pickaxe, thumbs-up, video, walk, zebra-jog
totalgee commented 3 years ago

Idea from @loopier : don't load any animations by default at startup. Instead, use OSC scripts (list of commands) to do this.

For example: /load "pickaxe", 24 would load pickaxe_dims_fps.jpg from disk and create an animation named pickaxe). The 24 argument is the frame rate, which (if specified) would override the frame rate in the file naming convention.

So there would be unloaded "possible files" and loaded ones would be returned when you call /types? Or maybe we should have:

/list or /list/anims (would list instantiated anims) Maybe this should be called /anims to be consistent. /list/files or /files (would list "available" files on disk that could be loaded — essentially list the directory) /list/types (same as /types now, it shows loaded sprites that are ready to be instantiated as anims)?

What is good wording for the two kinds of things? 1) "files" on disk that are in the animations directory and could be loaded. These are not literal filenames, and e.g. may be a sequence/directory, and could be obtained by /list/files (better naming welcome 😉). 2) "types", which I've been using to refer to loaded animation sources that can be instantiated, and obtained by /types (currently) or /list/types. I'm not convinced "types" is the best word here, but...what?

We've been using "anims" to refer to instantiated animations, we'll probably stick with that, after all Animatron...

loopier commented 3 years ago

Naming is a tricky picky subject.

I'm not sure anims is appropiate, because we might want to have an instance that is just a static image, like a background or a prop. I used node in my previous iteration, and since Godot uses it, too, maybe it's not such a bad choice.

Reading your comment, it seems natural to use: /list/loaded for loaded content /list/unloaded for unloaded resources

As for /types, not sure what's a good option. But, in the end, isn't it the same as /loaded?

Again, in my previous iteration I used /listresources to see available files, /loadresource name to load a specific one, and /loadresources to load everything with one command. But I don't like the word resource. So I'm not sure about this.

As for semantics, I tend to prefer to use one word, without spaces or uppercase (no camelcase either), even if it's harder to read. So I prefer /loadfiles over /load/files. I have my reasons for that, but knowing it's not kosher at all I'll adapt to whatever you find is OK, like /multiple/slashing.

totalgee commented 3 years ago

Node is a good word for technical people, and describes the implementation (and is nice and short), but doesn't really describe the idea in Animatron. A better word might be instance (though a bit long)

file - type - anim unloaded - loaded - node resource - template - instance

Or maybe use "made up" or not 100% related short words, like anim or seed?

loopier commented 3 years ago

mmm... well, node might be technical, but so is instance. And, aren't we technical people? Aren't technical people those who would use it? It's live coding.

loopier commented 3 years ago

how about object or unit?

totalgee commented 3 years ago

I was thinking more about the "code as poetry", and trying to make it as friendly as possible and making sense with non-technical language. At least "instance" does has a non-technical meaning -- as a "concrete example" or illustration of something, whereas "node" has a more graph-based meaning (to do with its connectedness in a tree, in this case, but the user shouldn't have to think of the anims as connected). "object" and "unit" are also very general. I don't know... We could stick with "anim"... ;-) Or just use node after all. I don't really mind any of these too much. Another possibility is "actor", I guess.

loopier commented 3 years ago

Oh, I see what you mean. I was thinking in two layers: a functional one, like we've been doing all along these years; and the poetic one, which would be the use we give to this functionality, how we would call these functions. That can be in any language that sends OSC messages or a custom set of OSC messages mapped to the functional ones. But that's just how I was thinking about it. Any approach is good for me. We have used "actor" before and worked pretty well :)

totalgee commented 3 years ago

Meeting today -- decided to use the following terminology:

asset --> anim --> actor (even if not all "anims" are actually animations -- some may be still images)

An asset represents a file (or set of files) on disk, unloaded. An anim represents a loaded asset, ready to be instantiated into the world/scene. An actor is a specific named instance, active in the scene.

So we will have /load "assetName" (by default will create an anim with the same name as the asset) and (as now) /create "actorName" "animName"

totalgee commented 2 years ago

The basics of runtime image/animation loading were handled by: