pic shows room with racks, room has no parent ,rack`s parent is an ObjectContainer3D,problem is if rack positioned in the room, rack can`t accept MouseEvent3D listener,but above room`s bound it can work.

Are you saying that if you change the Y position, and nothing else, of the racks they will suddenly start reacting to mouse input? If that’s the case it sounds like a bug. Please file it at http://github.com/away3d/away3d-core-fp11/issues

Thanks!

Hey datouaizi, I helped design the picking on 4.0, so if there’s a bug we’ll fix it! Can tell me a bit more of how you are setting up the picking on your scene, or perhaps send me some code? I need to know more to be sure this is a bug…

hi! if black rack body out Bound(room) ,mouseEvent3D can input ,but rack
has totality been contained by rom Bound and room also accept mouseEvent3D listener ,rack mousevent3D will be stop by the room

they are all seperated obj!

I have experienced this same issue. Picking objects that are within the bounding of another doesn’t give you the object you clicked on, but the surrounding object.

I see. Yeah this is a serious but at the same time hard-to-fix problem if you’re only doing bounds checking. Try doing any one of the following:

1. Disable mouse interaction on the walls (unless you need them, of course) using mouseEnabled = false.

2. Set the pickingCollider of the walls to PickingColliderType.AUTO_FIRST_ENCOUNTERED. This should only detect a hit on the walls if it actually hits one of it’s triangles.

3. Swap to using GPU picking by setting View3D.mousePicker to PickingType.SHADER. This will use a completely different picking approach that should not have these problems, but might be slow on some hardware.

thanks for your solutions,but not my need,Beta-away3d only has segment display bug,why don`t repair Beta version?that i can finish my project.

Away3D beta had tons of issues that we have solved in the gold version. Somewhere around 150 bugs were closed during the beta cycle, and then there were some refactors for better long-term performance, stability and extensibility, like this mouse refactor.

Are you saying that none of my suggestions above fixed the issue you were having? If you swap to GPU picking (as suggested as option 3 above), there is almost no chance that this issue would remain, because then bounding boxes would be completely ignored by the picking system.

As a last resort, you could of course just split your building mesh apart so that each wall is a separate mesh, thereby making sure that their bounding box does not cover the rest. That’s probably the best solution from a performance point of view, as it would mean that the picking system could still rely solely on bounds checking, which is fast.

o ,sorry for trouble you ! when mouse over mesh ,a red box fixed mesh will be show ,mouse out it will disappear.if I use view.mousePicker = PickingType.SHADER; when over mesh ,red box is flaming(hide and show)

if you will I will send My project to you .

thaks!

Just set the red box as mouse disabled, which should ignore it in the picking (and fix the flickering.)

I hava done that alerady.

If the red box still steals mouse events then that sounds like a bug. We will take a look at it ASAP.

However, my recommendation about breaking apart the walls mesh still stands. That way the mouse picker can use bounds checking much more efficiently, and you don’t have to use the shader picking method (which, as previously explained, also has some drawbacks.)