Replacing PointLists and LineLists
Andor Salga | 20 May, 2009 | 13:08
Cathy suggested the interfaces for PointLists and LineLists should be changed to Point and Line. One reason for this change is the current method of collecting points and lines into 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 points or lines could incur a performance hit. If there were disconnected points in a scene, every frame the renderer would have to iterate over all the points in the scene and copy their coordinates to a simple array. This array could then be passed to drawArrays(). By grouping the coordinates of points into a list within the scene class and exposing points as simple indices, the list would not have to be copied and can be directly passed into drawArrays().
I had not actually tested what the rendering hit would be, but realized it could be mimiced easily. For every frame, I took the contiguous list of coordinates and copied its elements into another newly allocated array. This roughly imitated what would be happening if the scene had to find all the points and copy each coordinate into an array before calling drawArrays(). I noticed there was a significant slowdown, from 60 FPS to 24 FPS, but it was not because of the code I just changed. Hitting refresh resized the canvas slightly, which I didn’t notice. This will be addressed in a blog shortly. In the end, the mocap demo does not seem to slow down, so to increase consistency within the library, PointList and LineList will be changed to Point and Line. Any performance issues which surface can be addressed in the library without the need to change any interfaces.
The next question is should each point be rendered individually? Would this slow down rendering? To test this, I just called drawArrays() for every point. The performance lagged a bit, there was a drop from about 66 FPS to 45 FPS. This means points may not need to be grouped into an array before being rendered. This could allow such flexibility as assigning each point its own attenuation and smoothing. However, this can also create some confusion.
The change will remove functions getPointLists(), getPoints(), getLineLists() and getLines() from the pickingObject class. This simplifies the object, but also makes it the user’s responsibility to check types since points, lines and models will all be in the list returned by getObjects(). This introduces the potential getType() method which each of our renderable object can implement.
Points and lines were designed to be grouped into lists because rendering a large number of points or lines could incur a performance hit. If there were disconnected points in a scene, every frame the renderer would have to iterate over all the points in the scene and copy their coordinates to a simple array. This array could then be passed to drawArrays(). By grouping the coordinates of points into a list within the scene class and exposing points as simple indices, the list would not have to be copied and can be directly passed into drawArrays().
I had not actually tested what the rendering hit would be, but realized it could be mimiced easily. For every frame, I took the contiguous list of coordinates and copied its elements into another newly allocated array. This roughly imitated what would be happening if the scene had to find all the points and copy each coordinate into an array before calling drawArrays(). I noticed there was a significant slowdown, from 60 FPS to 24 FPS, but it was not because of the code I just changed. Hitting refresh resized the canvas slightly, which I didn’t notice. This will be addressed in a blog shortly. In the end, the mocap demo does not seem to slow down, so to increase consistency within the library, PointList and LineList will be changed to Point and Line. Any performance issues which surface can be addressed in the library without the need to change any interfaces.
The next question is should each point be rendered individually? Would this slow down rendering? To test this, I just called drawArrays() for every point. The performance lagged a bit, there was a drop from about 66 FPS to 45 FPS. This means points may not need to be grouped into an array before being rendered. This could allow such flexibility as assigning each point its own attenuation and smoothing. However, this can also create some confusion.
The change will remove functions getPointLists(), getPoints(), getLineLists() and getLines() from the pickingObject class. This simplifies the object, but also makes it the user’s responsibility to check types since points, lines and models will all be in the list returned by getObjects(). This introduces the potential getType() method which each of our renderable object can implement.
// get the first object in the list.
var obj = pickingObject.getObjects()[0];
// get the type
if( obj.getType() == c3dl.const.POINT)
{
// ...
}
else if( obj.getType() == c3dl.const.LINE)
{
// ...
}
