It’s my pleasure, and I’m glad that you found a solution to the issue! 
I wasn’t sure myself, to be honest, but a quick forum-search turned up an answer, starting in the third paragraph of the below-linked post:
I still suspect that there’s some problem with the way that you were copying those elements, something that was resulting in the collision objects either not being at their intended locations, or not having their intended shapes. Perhaps it was the matrix-assignment that I pointed out earlier. Perhaps collision-objects don’t respond well to “deepcopy”. Perhaps it’s something else. I’m not sure, I’m afraid.
Ah, wait! I think that I may see the problem: Your ray wasn’t a child (directly or indirectly) of “oocnp”, and nor did it have a common parent with “oocnp”. In short, the ray and the collision-objects were on separate scene-graphs, and thus didn’t interact.
Part of this, I think, is that you’re calling “pickerNode.setFromCollideMask(GeomNode.getDefaultCollideMask())”. That line causes the ray to collide with anything that has GeomNode’s default collide-mask–which is to say, any (unmodified) GeomNode. It thus causes the ray to collide with things like visible geometry.
If you remove that line, your ray should collide only with collision objects, which may fit better with what you seem to be doing.
And if you want to collide with only a sub-set of your collision-objects, perhaps more reliable than "deepcopy"ing would be to temporarily reparent your objects to a separate NodePath–one that’s nevertheless attached to render, directly or indirectly–using “wrtReparentTo” in order to preserve the relative transformations of the objects. Once the traversal has been done, you could then use wrtReparentTo in order to transfer the objects back to their proper parentage.
Hm… I don’t know offhand, I’m afraid. You could dig through the API, however!