Using the bevy asset system as a file resolver

[reef oxide]

I'm trying to integrate the bevy asset loader with a third party crate that generalises over file system access, and to do this I need to be able to get the raw bytes of a file (it handles actual processing of data of various kinds, some overlap with the file types bevy will greedily process). I'm aiming to target both web and native platforms, so I can't just bodge it and use "normal" file loading for the file system access without duplicating some of the work the bevy asset system is doing.

What I'm looking for is something that looks like AssetServer::load_with(PathBuf, Fn(Bytes) -> T) -> Result<T, ...>. Best I can find is that this kind of functionality has been removed, but I'd be interested in hearing if there's a workaround or supplanted method of any kind.

(specifically, I'm trying to integrate typst-as-lib and its FileResolver trait)

[buoyant salmon]

Perhaps you could write an adapter between bevy's impl of AssetReader and typst's FileResolver.

typst is pretty cool. I'm interested to see what you can do with it plus bevy.

Do you run typst in its own thread? I see the FileResolver is synchronous and bevy's asset reading is asynchronous.

[reef oxide]

I don't currently, it's an approach I have in mind for the future.

but for now I'm just trying to get my design tooling together for my project. I'm using typst for [card faces in a card game](#showcase message)

typst-as-lib is a third party (to typst) crate so I'm not against just forking it and seeing if async can be dragged into it

(and relatively small)

[buoyant salmon]

I think in order to work between the typst's synchronous API and bevy's asynch, that's probably what you'd need to do. Run typst in its thread. Have some channels: requests to typst from bevy (e.g., render this), and results (e.g., image) from typst. Then in your fileresolver impl, you'll have a few more channels: requests for file (e.g., Path) to bevy, and results (e.g., Vec<u8>) from bevy.

But if you're still prototyping and don't need it to be web compatible yet, I might just try and give typst regular file system access and see what you can get away with. (Perhaps that's what you've already done?)

[reef oxide]

that's a shame, I did just want a "this sucks for now but I'll fix it later" escape hatch until I had time down the line to rework it.

[buoyant salmon]

Well, I mean, you could expose a little typst server that changed your problem into a bevy does http request and waits for asset from server. That'll work.

[reef oxide]

Mhmm

I think I'll just have to bodge it for now :/

thanks regardless

it's been some helpful information

[reef oxide]

might just be "prefetch using the StaticFileResolver" unless that gets in the way of taking advantage of typst packages.

[toxic shore]

I have been working a lot with Typst lately. Not in combination with Bevy, but I think I would try a slightly different route if I were to combine them. I don't really know typst_as_lib, but to be honest, integrating Typst directly is not that difficult.

I would define an asset type that is some kind of zip file containing your Typst project. Then implement your Typst world (fonts and file access stuff) using that asset.

You will have to download dependencies when zipping your project if you want to use any in your template. If you wait a bit you might be able to use my project for that ^^

[reef oxide]

I imagine it's not that difficult as you say but I have a very long todo list outside of typst integration (which typst-as-lib already exposed a very easy mode for)

[toxic shore]

That's totally fair of course. It just looks as if typst_as_lib forces you to use the file system access of their Typst World implementation. In my opinion that's what is making this integration more difficult.