http://www.xj3d.org/extensions/
http://www.xj3d.org/extensions/picking_examples.html
- BasicBoundingBox.wrl
- DynamicPicker.wrl
- PickGroups.wrl

A. Q. Should we even bother with PickSensor component at all, since few others are:
	http://www.web3d.org/wiki/index.php/Player_support_for_X3D_components
	- Xj3D and Flux/Vivaty listed as supporting picking component
	x problems running xj3d on win10 - doesn't run for dug9
	x neither vivaty studio nor vivatyplayer have it, just something called PickGroup with enable field
	x cobweb not listed, but on their site they don't mention PickSensor component
	* dune has the nodes, 
		x but doesn't seem to generate proper parent-child at design-time: 
		- picksensor.pickingGeometry should be a geometry node

B. New theory of operation for PickSensors (July 2016, dug9):
1. like the new do_TransformSensor - all you need is do_PickSensorTick and VF_USE and usehit_ functions.
	- picksensor and target nodes are flagged here with VF_USE
	- then on next frame/tick the picksensor and targets are recovered here with usehit_ functions, including their modelview transform
	- and all the work is done here in do_PickSensorTick
2. we'll simplify assumptions:
	- if target is geom, then can do BOUNDS or GEOMETRY intersection
	- if target is 'chunk of scenegraph' ie Group, Transform or PickableGroup, then 
		for now july 2016: we do only BOUNDS, 
			- taking only the _extent of the (topmost) target node, 
			- not delving/probing into children/descendants
		future: do a special setup of render_node(node) and children recursion for picking that examines each descendant
			- and/or over-ride rayhit functions
			- push and pop X3DPickable state according to X3DPickableGroup in the transform hierarchy
	- ^^the pickingGeometry SFNode is not a USE reference, it has only this node as parent (or we'll ignore any other USE)
3. different than transformsensor:
	- transformsensor did its work in transformsensor node space (where the transformsensor was in scenegraph)
		- so any evenouts were in transformsensor space
	- in theory this could do its work in 
			a) world space (by taking view off modelview matrix, and doing one-way transforms local2world for all 3 parts), or 
			b) pickTarget space (as we do with mouse picking, transforming the pickray on each transform stack push), or 
			c) pickingGeometry space (we'll assume^^ this is the same space as d) picksensor)
			d) pickSensor space (like transformSensor)
		-each option would/could affect function design
	- for now we'll do work in d) picksensor space, so 'closest' is easy to sort relative to 0,0,0
		and that means transforming pickTarget to picksensor space (^^ and assuming pickingGeometry is already in picksensor space)