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.
mesh mouseEvent3D problemSoftware: Away3D 4.x |
||
|
||
Richard Olsson, Administrator
Posted: 19 July 2012 01:24 PM Total Posts: 1192 [ # 1 ] 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!
|
||
Alejandro Santander, Administrator
Posted: 19 July 2012 01:37 PM Total Posts: 414 [ # 2 ] 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…
|
||
|
||
theMightyAtom, Sr. Member
Posted: 20 July 2012 08:51 AM Total Posts: 669 [ # 4 ] 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.
|
||
Richard Olsson, Administrator
Posted: 20 July 2012 10:48 AM Total Posts: 1192 [ # 5 ] 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.
|
||
|
||
Richard Olsson, Administrator
Posted: 20 July 2012 01:49 PM Total Posts: 1192 [ # 7 ] 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.
|
||
datouaizi, Member
Posted: 20 July 2012 02:03 PM Total Posts: 98 [ # 8 ] 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!
|
||
Richard Olsson, Administrator
Posted: 20 July 2012 02:06 PM Total Posts: 1192 [ # 9 ] Just set the red box as mouse disabled, which should ignore it in the picking (and fix the flickering.)
myRedBox.mouseEnabled = false;
|
||
|
||
Richard Olsson, Administrator
Posted: 22 July 2012 01:29 PM Total Posts: 1192 [ # 11 ] 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.)
|