I posted a demo of the LineList, which still needs to be cleaned up, but the basics are there.

An interesting thing I noticed is that the width can only be set a few pixels, then it caps out. This could be implementation dependent. Again, like the point size, it will be up to users to handle that.

Our front page has been ported over to the new Canvas 3D 0.4.2 release. If you are viewing our site using Firefox 3.0x with Canvas 3D 0.2 it will no longer work. To view it, please use a firefox 3.5 nightly along with the new Canvas 3D 0.4.2 extension.

All the old demos written for Canvas 3D 0.2 have also been moved to a different category. (you can still see them from a menu item on the side bar near the bottom). Over the next week we will be porting over these demos to the newer Canvas 3D 0.4.2 release. Some of these demos will be easier to port than others but we hope to port most of them over evetually. Here, I’ve made a simple demo, using the collision detection.
The edge of the canvas serves as the boundary, and the balls are only moving side to side. Whenever any objects have a collision, it will move in the opposite direction.
See Here.
This one is a similar demo but with more balls and moving in multi-directions, bouncing off each other.
See Here. Play Here

Side note, update with current status of collision detection here.
The demo above may take a while to load.

While working on putting points into the library, I became concerned about a possible performance hit if implemented in the way I spec’ed it out some time ago. After a bit of brainstorming, I came up with another way to represent them. Instead of creating individual points, users create a list of points. I re-spec’ed out the interface and wrote the class and new vertex and fragment shaders.

Not suprisingly, there is a performance gain when rendering mocap data using points versus spheres. Albeit, I did find an interesting slowdown when rendering points with a large point size. If the point size of a list is set to several hundred pixels in diameter, the rendering suffers greatly. This may be due to having to calculate which fragments fall into the point’s radius, but that’s just a guess. We’ll have leave it up to users to create implementation specific point size caps.

PointList

I may change some function names slightly, but here is the current interface for the PointList class:
  • init(numPoints) //Initialize the points
  • setPointCoord(index, coordinate) //Set the position of point at index ‘index’.
  • setPointColor(index, color) //Set the color of a particular point.
  • setVisible(visible) //Set the visibility of the PointList.
  • setSize(size) // Set the size of all the points in this PointList in pixels.
  • getSize() //Get the size the points will be renderd in pixels.
  • getVisible() //Are the points drawn on render?
  • getNumPoints() //Get the number of points in this PointList.
  • getPointCoord(index) //Get the coordinates of point at index ‘index’.
  • getPointColor(index) //Get the color of point at index ‘index’.

TODO

I figured changing the alpha/intensity value of a point would change the entire color intensity. Instead it seems to produce a border around the point which creates a sort of scintillation when using point smoothing. I’ll need to figure out exactly why this is happening.

One useful function would be point picking. This is something I will add once the LinesList is complete.