Incorrect expectations: Octree.js migration into CubicVR

As the title describes, my initial expectations about this migration were not accurate. I went into this with the expectations that the octree.js code had been coded towards use in CubicVR, but instead it seems to have been coded as a simple stand alone octree system, and at that, not a fully complete one. I am a little confused as to why they seem so interested in integrating this new octree system though it lacks much of the functionality of the current one. These are questions I am gonna have to ask them about tomorrow I guess.

So far, the two sound things I think I've managed to accomplish has been bringing the old tests back to operable status (patch has already landed), and the migration of much of the math work in octree.js into the CubicVR.Math.js (scratching the redundant code). After that, I am really unsure whether or not I am going in the correct direction with this work. I am rather chaotically patching the new system into place, and have recently just got the octree "operational". I am unsure as of now if the octree is actually doing anything or is simply wasting cycles accomplishing nothing, but it was my goal for tonight to get the octree.html test running with the new system in place. This system implementation into the scene object just sits on top of all the old stuff, for simplicity for now, I plan on cleaning it out, but on the other hand, perhaps I should consider scrapping this whole bunch of code and starting from scratch with a better idea of what I am getting into....

The biggest thing I have against scrapping what I have done is simply that my 0.4 for OSD600 was due days ago, and I still have nothing submitted. I'd really like to have this whole thing implemented, reviewed, and completed properly before submitting it as my 0.4, but for it to reach that status may take another week, especially considering I have exams this week. I am pretty much completely out of time, so perhaps a somewhat rickety implementation submitted tomorrow would be better than a correct implementation submitted in a week.... not sure, hopefully D. Humph can give me advice on this.

If I were to scrap what I have, I'd think I'd take a more orderly approach to it, first tearing out all of the octree related stuff from the current build of CubicVR and getting it back to operable status again, then starting to add in the new implementation piece by piece on a more or less clean slate. SecretRobotron wasn't around today, so hopefully I can talk to him and ccliffe and see what they thing the best choice would be, and weigh that with my already late submission...