Skip to content

Expose omagari library#2

Open
Nub wants to merge 4 commits intohexroll:masterfrom
Nub:master
Open

Expose omagari library#2
Nub wants to merge 4 commits intohexroll:masterfrom
Nub:master

Conversation

@Nub
Copy link

@Nub Nub commented Aug 9, 2025

Began a light refactor to move omagari to use more rust-ful patterns.

  • Expose omagari as library thats useable externally to load omagari projects
  • Add file picker for opening omagari project

@Nub Nub changed the title Expose omagari as a library to allow omagari project files to be loaded and used by projects. Expose omagari library Aug 9, 2025
@hexroll
Copy link
Owner

hexroll commented Aug 13, 2025

Thank you! so much for the PR. I'll review within the next few days.

@hexroll hexroll self-assigned this Aug 17, 2025
@hexroll
Copy link
Owner

hexroll commented Aug 17, 2025

Hiya @Nub \o/ - I started reviewing and I have a few quick questions:

  • I noticed the file dialog cancel is ignored. Can this be fixed?
  • It looks like there's a hard-coded texture reference for cloud. Is this intentional?
  • Looks like effects parenting is not supported via the lib reflection of the project?

@hexroll
Copy link
Owner

hexroll commented Aug 17, 2025

Another thing I noticed is that in the PR, OmagariProject is used to .produce() the effect for the lib, but I think this is not really needed when you have the exported .ron file, as it is already a valid Hanabi EffectAsset ready to be added to Assets<EffectAsset>.

@hexroll
Copy link
Owner

hexroll commented Aug 17, 2025

Regarding exported projects, looks like the PR also removed the export functionality altogether - was that intentional?

@LukeThayer
Copy link

Hi I was working with the author on this PR.

the exported ***.hanabi.ron is not a valid hanabi file due the data being wrapped with omnigari specific data such a list of effects, and a hard coded id of an effect. Due to this it makes more sense to actually just load the ***.omnigi.ron directly, this would allow us to generate the hierarchical particles that are supported in in omnigari in any app without addition unique support code.

parenting is not currently supported.

the reason that cloud is hard coded is because there will need to be another rework of loading the assets. in the current omnigari implementation it is only possible to load assets from a hard coded list using an index into the list, where this needs to change from using an id to being a Path this PR starts that process.

I hope that answers some questions, I am interested in working with you to support this crate if you are interested!

@hexroll
Copy link
Owner

hexroll commented Aug 25, 2025

I hope that answers some questions, I am interested in working with you to support this crate if you are interested!

Starting with the most important thing :) Absolutely interested \o/

the exported ***.hanabi.ron is not a valid hanabi file due the data being wrapped with omnigari specific data such a list of effects, and a hard coded id of an effect. Due to this it makes more sense to actually just load the ***.omnigi.ron directly, this would allow us to generate the hierarchical particles that are supported in in omnigari in any app without addition unique support code.

This is my fault - I omitted the part hexroll is using to load the exported asset file. I now pushed a branch with this code organized into lib.rs at https://github.com/hexroll/omagari/tree/omagari-lib-with-asset-loader. This has a custom asset-loader that is capable of directly reading the exported hanabi.ron files like so:

    let blood_effect: Handle<EffectComplex> = asset_server.load("blood.hanabi.ron");
    let magic_effect: Handle<EffectComplex> = asset_server.load("magicburst.hanabi.ron");
    let explode_effect: Handle<EffectComplex> = asset_server.load("explode.hanabi.ron");
    let defense_effect: Handle<EffectComplex> = asset_server.load("defense.hanabi.ron");
    let vapor_effect: Handle<EffectComplex> = asset_server.load("vapor.hanabi.ron");

Which in turn can be spawned by accessing Res<Assets<EffectComplex>, calling spawn and passing a Vec of textures, similar to:

vec![
  asset_server.load("omagari/cloud.png"),
  asset_server.load("omagari/cloud2.png"),
  asset_server.load("omagari/spark1.png"),
  asset_server.load("omagari/spark2.png"),
  asset_server.load("omagari/spark3.png"),
  asset_server.load("omagari/glow1.png"),
  asset_server.load("omagari/splat1.png"),
]

(These are excerpts from hexroll, but I should write a proper example)

This also supports hierarchical effects.

Keeping in mind this code is not perfect, what do you think about this strategy?

(Edit: the reason I use ExportedProject rather than the Omagari project is to avoid the bloat of importing unneeded omagari constructs into your game)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants