Lifetime issue

[beltegeuse]

Hi Will,

I tried to integrate your library to my renderer, but I have some issue with lifetime definition. Indeed, I want to "encapsulate" some embree_rs objects inside a single struct to make my code modular (code example below).

pub struct EmbreeAcceleration<'device, 'scene> {
    pub device: embree_rs::Device,
    pub scene: embree_rs::Scene<'device>,
    pub rtscene: embree_rs::CommittedScene<'scene>,
    pub trimesh: Vec<embree_rs::TriangleMesh<'device>>
}
impl<'device, 'scene> EmbreeAcceleration<'device, 'scene> {
    pub fn new(meshes: &Vec<geometry::Mesh>) -> Self {
        let device = embree_rs::Device::new();
        let scene = embree_rs::Scene::new(&device);
        let mut trimesh = vec![];
        for m in meshes {
            // TODO: Create trimesh and register it
            unimplemented!()
        }
        let rtscene = scene.commit();
        EmbreeAcceleration {
            device,
            scene,
            rtscene,
            trimesh,
        }
    }
}

Note that the code above does not compile. Have you tried to do a similar thing with this library in one of your projects? If you know a solution, it will be much appreciated 😄

Cheers,
Adrien

[Twinklebear]

Hm it will be tricky with some of the lifetimes here, since the scene borrows the device, and the committed scene borrows the scene. So it's a bunch of self-referencing objects in the same struct.

For the triangle geometry it's also similar, but for that I'd recommend not keeping the trimesh vector on your application side and instead storing the IDs of the meshes if you need to look them up again. For example in the OBJ viewer example I use drain on the list of triangle meshes. Then you can use the Scene::iter or iter_mut method to iterate through them, since the Scene hangs on to them for you. There's also get_geometry and get_geometry_mut to get a specific geometry by ID. Then if you ever need to move some mesh to another scene when you detach it the Geometry is returned back to you. It kind of works like the scene takes ownership of the geometry while it's attached.

I'm not sure on the others though, the easiest might be to push them into Box's or Arc's so they're on the heap instead of the stack. It's a bit annoying but may work. I would like to have this work as a use case, since I think that's how I'd also likely end up using this library in some future projects. Especially if you want the option to swap out Embree easily for some comparisons. I can also try out pushing these into some Box/Arc wrappers

[Twinklebear]

Seems like the issues are kind of similar to what tomaka was finding with vulkano https://gist.github.com/tomaka/da8c374ce407e27d5dac , his mention about Arc is why I've been trying to avoid introducing them into the main API. That is a pretty old post though, so I wonder if there's been some developments since.

[Twinklebear]

It looks like there's now a Pin type in the Rust standard lib for making these kinds of self-referential structs: https://doc.rust-lang.org/std/pin/index.html , I wonder if this will work here? Then just your EmbreeAcceleration would need to be put behind a Box or Arc (since moving it would invalidate the internal refs) but it should be possible to create one of these objects, but that's probably ok compared to having each member in a Box or Arc.

[beltegeuse]

Hi Will,
Thanks for all these answers! I am still not sure how to use Pin but I will figure out.
I will close the issue for now and re-open if necessary.
Thanks for your hard work on embree-rs :)

[Twinklebear]

Let me know how it goes with Pin, I'm curious how it works as well since I've run into similar issues in Rust. It seems like Pin is designed to solve this, but I also just learned of it in searching around for this issue, so am also not sure how to use it.

[kubo-von]

Hey @Twinklebear and @beltegeuse ,
I've ran into the same issue while trying to multithread rendering using embree-rs. I was wondering if any of you find some solution in the end ? I've tried putting the scene into pinned boxes and arcs but it does not seem to change anything.
Cheers
Jakub

[beltegeuse]

Hi @kubo-von,

Do you want put all the different embree_rs objects inside a same struct like:

pub struct EmbreeAcceleration<'embree> {
    pub device: &'embree embree_rs::Device,
    pub scene: embree_rs::CommittedScene<'embree>,
}

Because, at my best knowledge, this is not possible with Rust yet. Indeed, you cannot self-referential lifetime inside the same struct. For more information, you can look at this post: https://users.rust-lang.org/t/how-do-i-create-self-referential-structures-with-pin/24982/11

The only plausible workaround I see is to have an Arc pointer inside the CommitedScene object so that you can get rid of lifetime dependency. I think this is an acceptable solution as you only need to access the device a few times. But as @Twinklebear said before, introducing Arc inside the library might be not ideal.

[kubo-von]

Hi @beltegeuse,
I'd like to do that eventually, to make my code more clean and modular.
But right now I'm just trying to multithread my rendering process, so I need all the threads to access the same commited embree scene. What I've done is:

• put the commited embree scene in new Arc
• clone the arc, start a new rendering thread using thread::spawn(move ||{....}) which moves the clonned arc into the closure.

But that does not work, because of the life time of embree device which is referenced inside the commited scene, I assume this is the same issue that prevents it to be in the same struct. So I was just wondering if you've managed to solve your life-time issue in the end or if you've ever sucessfully multithreaded the rendering process with embree in rust ?

By having Arc inside the library, you mean forking embree-rs and modifying in a way that there's an Arc instead of reference ?

Thanks!
(I'm new to Rust and this level of programming in general so sorry if my questions are a bit dull)

[beltegeuse]

Hi @kubo-von,

You only need to keep borrowing when using a committed scene (in the usual scenario). Indeed, usually, you do not need to update the scene information when achieving rendering, so having read-only access to the committed scene is not an issue.

I have attached a modified version of "obj_viewer" that you can found inside the examples directory. Here I use rayon to achieve parallelization over image rows. You should decompress the archive inside examples directory if you want to built it.

obj_viewer_parallel.zip

[Twinklebear]

@beltegeuse the parallel OBJ viewer with rayon is really cool! Would you mind opening a PR to include it as an example in this repo?

[beltegeuse]

@Twinklebear Sure I can do that. Or maybe an AO integrator? (as primary ray intersection is usually quite fast with Embree). What do you think?

[Twinklebear]

Yeah @beltegeuse an AO integrator would be a great example to include!

[kubo-von]

Thanks a lot for the example @beltegeuse !
That'll be a huge help.

[kubo-von]

So the rayon worked great, but I wanted more control over the number of threads using Threadpool and I've run into the lifetime issue again, with embree device and embree scene not living long enough.
It the end the Leak Crate solved it for me. By putting the embree device and the embree scene (before commiting) into Boxes and calling .leak() on them the lifetime issue was solved.
Not sure how safe/smart solution it is but might help someone.