Extending Picking Functionality
Andor Salga | 14 May, 2009 | 13:09
When picking was added to the library, we did not anticipate anything else being picked other than 3d meshes. To obtain the data calculated by the internal picking function, users have to write a callback function:
This worked, but only up until now. Points need the same picking functionality, however points were not designed as objects, but as part of a point list. This difference creates a problem in the picking callback interface (How can they be returned?). Additionally, if a new type of object is added to the library, the potential for it to be pickable must be considered, therefore an extensible interface is required.
One way to address this problem is to simply keep adding arguments to the picking callback, but this approach is not very elegant. Another possibility is to make the individual points and lines classes themselves, however this would require more changes to the PointList and LineList classes which would need re-testing. Not changing the picking callback function now would also force any future object to be implemented in a certain fashion.
I’m proposing a change to the picking callback function. This would break old code, but would create an extensible interface to handle future types of objects and functionality. Instead of having the callback receive three arguments, it would accept a single pickingObject.
/**
@param {int} buttonUsed Defines what mouse button was pressed when the user
clicked on the canvas.
@param ObjectsHit {Array} Array of integers which are the array indices of
the objects in the object list array of the scene.
@param Scene {c3dl.Scene} Scene which was clicked. There may be many
canvases on the page rendering their own scene.
*/
onPick( buttonUsed, ObjectsHit, Scene)
{
//...
}
The user would then check to see if any objects were hit and possibly which button was used. They could then perform any necessary logic.This worked, but only up until now. Points need the same picking functionality, however points were not designed as objects, but as part of a point list. This difference creates a problem in the picking callback interface (How can they be returned?). Additionally, if a new type of object is added to the library, the potential for it to be pickable must be considered, therefore an extensible interface is required.
One way to address this problem is to simply keep adding arguments to the picking callback, but this approach is not very elegant. Another possibility is to make the individual points and lines classes themselves, however this would require more changes to the PointList and LineList classes which would need re-testing. Not changing the picking callback function now would also force any future object to be implemented in a certain fashion.
I’m proposing a change to the picking callback function. This would break old code, but would create an extensible interface to handle future types of objects and functionality. Instead of having the callback receive three arguments, it would accept a single pickingObject.
onPick(pickingObj)
{
// get an array of references to objects which have been picked.
var objectsPicked = pickingObj.getObjects();
// we can query the picking object and find out which button was used
// for the pick.
if( pickingObj.getButtonUsed() == 1)
{
//...
}
// we can get the number of objects/models the user picked by
// getting the length of the array of references.
if( objectsPicked.length > 0)
{
// ...
}
// how many pointlists had at least one of their points picked?
var pointLists = pickingObj.getPointLists();
// iterate over all the point lists which have been picked.
for( var i in pointLists )
{
// since we have the reference, we can call the pointlists
// methods easily without needing to get the reference
// from the scene.
// ie. scene.getObj(i)
if(pointList[i].getName() == "whatever")
{
// for this particular pointlist, we'll need to
// get which points were picked. getPoints()
// will return the indices of all the picked points
// for pointList at i.
var pickedPointsIndices = pickingObj.getPoints(i);
// let's say we want to change all the picked
//points to red.
for(var j in pickedPointsIndices)
{
pointList[i].setPointColor(
pickedPointsIndices[j], [0,1,0,1]);
}
}
}
}
If this implemented, some of the functions of the pickingObject will include:
// get an array of references of pointLists which had at least
//one of their points picked.
getPointLists();
// get an array of indices of points which were picked for pointList at 'i'.
getPoints(int i)
// get the mouse button which was used for the pick.
getButtonUsed();
// get an array of references of objects picked
getObjects();
// get the canvas which was picked. From the canvas we can get the scene.
getCanvas();
// get an array of references of lineLists which had at least
// one of their lines picked.
getLineLists();
// get an array of indices of lines which were picked from LineList at
// index i of the list of linelists
getLines(i);
[...] lists introduces some convention inconsistencies when querying the pickingObject
Canvas 3d JS Library » Replacing PointLists and LineLists | 20 May, 2009 | 13:08[...] lists introduces some convention inconsistencies when querying the pickingObject for its data. see Extending Picking Functionality. Points and lines were designed to be grouped into lists because rendering a large number of [...]