099.23680 Ouster

This is not technically a bug, I do think the behavior is non-ideal.

Working on a project with an ouster - in this case we’re using the ouster as a tool for the monitoring the movement of people in a space. As we’re not using the ouster’s feed directly, but using some network processing, we’ve run into a circumstance where our tracking solution stops updating when not looking at the portion of the network that contains the ouster TOP.

I think this is the expected behavior of TOPs - as you want them to stop cooking when not being viewed directly. In this case, however, I want that TOP to always be cooking. A proposed solution here would be to add a toggle to the Ouster TOP for continuous cooking.

I realize this is more of a RFE, so please feel free to move this to the other category after review. :slight_smile:

Thanks for the report. Just to confirm, you don’t have anything that is referencing the Ouster TOP, but just want to ensure that it continues processing the sensor data in the background?

Unfortunately we don’t have access to an Ouster unit right now to test, but I’ll check with the rest of the dev team and see what a good solution might be here.

@robmc - that’s correctly, mostly. We have a render network set-up that instances based off the point cloud, then use a blob track TOP to do some simple tracking. That then runs through a CHOP network to measure our confidence in the blob being a person, and finally that gets packed into multi sample CHOP that’s used to drive user interaction.

So, even if we’re looking at the CHOP data, the ouster stops cooking, and our tracking stops working. Right now, as a work around, if I comp the ouster’s output into our scene, then use a level, TOP to turn the opacity to 0. This works, and keeps the Ouster cooking, it just seems like a bit of a hack.

Thanks for the details. So you’re referencing the Ouster TOP point cloud to run instances in the Geometry OBJ, but that’s not causing it to cook? I’m kind of wondering if there isn’t some other cooking bug in the chain there.

I’m a little hesitant to complicate things with an always cook parameter, since users might not be clear when they need to use it. I’ll do a little more investigating and get back to you.

@robmc I can see the challenge of opening up a part that might be confusing. If it’s helpful I can try to set-up a simple example while I have an ouster on hand. Let me know, and I can send it to support. :slight_smile:

As it stands, if I’m understanding things correctly, it feels like there might be a bug in there so an example would be great if it’s not too difficult.

I tried setting up my own network doing the ouster -> geo instance -> render top -> blobTrack -> Info and put it all inside a base component, but everything still cooks as I would expect.

Re: the auto-cook parameter, it should only be necessary if the node is outputting something externally that the cook system isn’t aware of.

I’ll be back in our studio space with the Ouster tomorrow and I’ll get an example together.

hey @robmc - I shot you a message with an example file. let me know if there are other questions I can answer about this setup.

Thanks in advance!