No hit when used in `PostUpdate` system

[thmxv]

I use the immediate mode to cast rays in a system and it works well if the system is in Update. However I needed to move this system to PostUpdate (for reasons unrelated to this mod but related to egui) and, with this change, the ray cast never returns any hit. Is this a known/normal limitation (but undocumented) or is this a bug?

[aevyrie]

I can't replicate this. Setting the raycasting system in minimal to run in PostUpdate works just fine.

Edit: also checked mouse_picking and reflecting_laser.

[thmxv]

Thanks and sorry. I thought it was replicated in the minimal example for some weird reasons but that is not the case. Pretty dumb on my part.

However. In my camera controller, I use a ray-cast from the mouse cursor to rotate/orbit around the intersection of the ray-cast with the geometry (like in Blender with auto_depth enabled). This works well if the camera controller system is in Update but not if it is in PostUpdate. The Res<CursorRay> has a correct origin and direction but the (immediate) cast_ray() does return an empty slice of intersection.

Any way, thanks for checking and correcting my mistake and thanks a lot for this mod.

[aevyrie]

That is possibly happening if you are running the raycast after bevy's transform propagation happens in PostUpdate.

[thmxv]

Thanks (once again). But no the system is set to run

...
    .before(CameraUpdateSystem)
    .before(TransformSystem::TransformPropagate),

[thmxv]

So weird:

• I, previously, tried to mess around with the system ordering and all that without any success
• I switch my attention/work to something else totally unrelated
• The only semi-related thing I have done is to modify the code (that can be found here in issue #112) for the ray cast cull mode to be the same as the material cull mode: I switched a match with a single matching case to a if let (because clippy)
• Now after a few hours, I try to refocus on this issue, but now it works fine with exactly the same code and system ordering constrains as before. Same code totally. I also used git to make sure the camera controller files were not touched and to revert to a previous state.

I do not know what to do really. It is probably due to some other issue of system ordering that can reappear at a latter stage.

[aevyrie]

If it's inconsistent, it's likely a system ordering ambiguity, and can differ from run to run. I'd suggest taking a look at the ambiguity checker.