Reference implementations of use cases of Inox2D

[orowith2os]

For the core of Inochi2D, you have Session, Creator, and the main library. However, Inox2D doesn't have the same reference implementations. Having some use cases implemented as reference implementations could be useful for actually using Inox2D.

This would require feature parity with Inochi2D, and some better documentation on Inochi2D's side of things, both of which are to-do.

And, when possible, a reference Godot, Bevy (#1), and some other misc use cases implementations, like in the web.

[dayswith]

The reason I push a lot for Bevy is for anime game use cases. Japanese musical gacha games like Hatsune Miku: Colorful Stage uses Live2d to animate their character avatars in 2d dialogs. Like this one.

I am working on a project called Project Flara that is basically a collection of support for making these kinds of games, but I'm just a single woman in tech, and I have full-day schools during the weekdays, and full night study too, soo it's not easy for me to work alone.

I wonder what the other use cases for this project probably. We have to consider than Luna too is planning to write Unity and Godot plugin (if I am correct?) once she got 1.x releases.

[dayswith]

I guess the main thing about how Inochi2d is written in Dlang makes it harder to integrate with other languages through FFI. I guess we need to excel at that.

[orowith2os]

I wonder what the other use cases for this project probably.

A use case I have would be a Session alternative, since Inox2D can be more performant and being Rust-based allows for some more options, like using GTK as a UI for a Session alternative, which allows for more integration with Linux.

[Speykious]

and some other misc use cases implementations, like in the web.

Web is actually a priority use-case for Inox2D, as the project emerged from the idea of making it possible to run a direct demo of Inochi2D on the web, which is currently impossible with the reference implementation in D since D's garbage collector is incompatible with WASM.

It's gonna come eventually, but the library is not in a good enough state to start caring about the use-cases yet. I need to finish the OpenGL renderer, and when that's done, we need to focus on parameters and deforming the model. Basically feature parity with Inochi2D as you said.

[Speykious]

I wonder what the other use cases for this project probably.

A use case I have would be a Session alternative, since Inox2D can be more performant and being Rust-based allows for some more options, like using GTK as a UI for a Session alternative.

I personally don't like using GTK, Qt or any other non-Rust framework for UI... And I'm not sure how cross-platform it would be too. Maybe if I decide to not be pedantic about GUI I'd use something like Flutter to have something truly cross-platform, but the ideal would be a pure Rust GUI solution on top of something like Miniquad so that we get a performant GUI framework that works both on mobile and desktop.

[Speykious]

I guess the main thing about how Inochi2d is written in Dlang makes it harder to integrate with other languages through FFI. I guess we need to excel at that.

Definitely! We have to think about FFI at some point. But feature parity first :v

[orowith2os]

I personally don't like using GTK, Qt or any other non-Rust framework for UI... And I'm not sure how cross-platform it would be too.

My use case would be more or less Linux-only, I don't deal with Windows and macOS. Though this is just my use case, and is sort of out of scope for discussion here currently.