So another day has gone by, I've managed to get the system culling objects, but not correctly. Having glanced through the AABB code and frustum code, I'd have to assume my issue right now is with the frustum, as the AABB code is giving consistent results. The frustum code has been reused from the old implementation (which I firmly now believe didn't actually work correctly, at least not in the latest build) and it seems to be the source of my trouble, I am considering simply writing a new one from scratch, shouldn't take more than half a day.
At the moment, the system isn't actually even using the octree, instead using the isolated AABBs of each object to do its culling. I plan to make use of the octree, but not until I have it correctly culling at the AABB level, once that works, I know the frustum code is working correctly.
I plan to get this completed within the next few days, a week tops. But the fact that I haven't submitted anything for 0.4 yet is too pressing. I am going to be submitting this current build as my 0.4, I have gotten a fair bit done, so hopefully it will suffice. I really wish I had picked up this bug for my 0.3, everything would have sorted out much better. I will continue working on the bug and blogging about my progress each day, and with Humph's permission, update my 0.4 submission as I make progress. But for now, this is where I am marking my 0.4.
Below will be a short list of what has been accomplished for my 0.4 as of the time of this blog being published:
-Octree tests brought back to operational status
-Old octree implementation stripped out (Frustum code salvaged)
-New octree code added as module
-Octree components tied into system (migration about 70% done)
-Scene now culls scene objects using frustum and object level AABBs (frustum incorrect, causing unwanted culling)
Wednesday, December 14, 2011
Tuesday, December 13, 2011
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...
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...
Sunday, December 11, 2011
CubicVR Octree progess part 2
So the tests are working, the changes had to be made in the Scene object, not sure if the changes I made follow standards, but I simply added the variables to the local object (added this.) and the variables were no longer falling out of scope. This shouldn't cause too much of a problem since these variables are reset every render pass and are hooked into the Octree object, so it shouldn't conflict with anything else. I'll ask for a code review on the change when I make a pull request.
Been analyzing how CubicVR uses its current octree implementation to see what I have to change and where. I was hoping their operations would line up a bit more seamlessly, but its gonna take some modding on both ends (the new octree system as well as many of the CubicVR source files) before I can get them working together correctly. I am hoping to have this finished up by the end of the night, the fact secretrobotron hasn't been on IRC today makes this a little more difficult as he would know the most about what can and cannot be changed in the new octree implementation, but I'll do what I can. If I change something I am not supposed to, hopefully it will be picked up during the code review. Obviously, with the tests now working, I should be able determine if everything is running correctly. I've already benchmarked the old implementation, and am hoping to see some improvements with the new one, if not, I hope to not see a drop in performance, as that would likely indicate I may have messed it up some.
Been analyzing how CubicVR uses its current octree implementation to see what I have to change and where. I was hoping their operations would line up a bit more seamlessly, but its gonna take some modding on both ends (the new octree system as well as many of the CubicVR source files) before I can get them working together correctly. I am hoping to have this finished up by the end of the night, the fact secretrobotron hasn't been on IRC today makes this a little more difficult as he would know the most about what can and cannot be changed in the new octree implementation, but I'll do what I can. If I change something I am not supposed to, hopefully it will be picked up during the code review. Obviously, with the tests now working, I should be able determine if everything is running correctly. I've already benchmarked the old implementation, and am hoping to see some improvements with the new one, if not, I hope to not see a drop in performance, as that would likely indicate I may have messed it up some.
Progress on CubicVR octree migration
I was assigned issue 26 earlier in the week, which is about migrating a new octree system written by secretrobotron into CubicVR.
I started out by testing that the current octree tests were working, so I could benchmark the current implementation and test and benchmark the new implementation to see that it has been implemented correctly. Unfortunately, almost all the tests were either partly or completely broken. I informed the people in the #paladin channel on Moznet, and I volunteered to get those working as well. This naturally pushed back my schedule, but there really wasn't a way around it.
Thus far I've found one of the bugs, which fixes about half the tests, which was a function call that hadn't been updated to keep with the changes of the octree. The other breaking bug seems to be that a variable is falling out of scope, though I'm not sure why. Once these tests are fully functional again, I'll head to work on the actual migration again.
On another note, the tests for Mouselock weren't added to the patch because they were not working correctly. I had done a test review for one of the tests, but no one noticed that there was a duplicate on the list (of 20 items) and that what I was working on had already been done, so that was a great waste of time. More work needs to be done on the test reviews, but I need to finish my work for CubicVR first. If there is still work to do when I'm done, I'll gladly help finish this out.
I started out by testing that the current octree tests were working, so I could benchmark the current implementation and test and benchmark the new implementation to see that it has been implemented correctly. Unfortunately, almost all the tests were either partly or completely broken. I informed the people in the #paladin channel on Moznet, and I volunteered to get those working as well. This naturally pushed back my schedule, but there really wasn't a way around it.
Thus far I've found one of the bugs, which fixes about half the tests, which was a function call that hadn't been updated to keep with the changes of the octree. The other breaking bug seems to be that a variable is falling out of scope, though I'm not sure why. Once these tests are fully functional again, I'll head to work on the actual migration again.
On another note, the tests for Mouselock weren't added to the patch because they were not working correctly. I had done a test review for one of the tests, but no one noticed that there was a duplicate on the list (of 20 items) and that what I was working on had already been done, so that was a great waste of time. More work needs to be done on the test reviews, but I need to finish my work for CubicVR first. If there is still work to do when I'm done, I'll gladly help finish this out.
Friday, December 9, 2011
Burning the midnight oil....
So, as I figured, the IRC channel came alive later in the night. I noticed no one had grabbed the test_syntheticMouseEvent test review and went underway. After making a series of changes, mostly stylistic and only a few that actually affected code, I configured it to work with the harness and it was ready for testing. rhung had been complaining that he was unable to get the tests to run correctly, so I pulled from his repo and attempted to run them, but it didn't work, not because it would fail, but because the tests would simply lockup and not proceed. Not sure as to why it is failing. Really I am writing this blog to pull myself away from issue for a minute while I try to think of what could be causing the problem...
My posts often lack anything particularly helpful to the reader, so I'm just gonna list some tips I've either found or been given. Just to make this worth your time reading.
1) Its always a good idea to keep your whitespace clean in your code, heres a few regex commands that can help keep your code nice and clean (mind you these are all for vim, but you should be able to translate most of them to other apps(ignore the %, thats vim only)):
-Remove whitespace at the end of a line: %s/\s$//
-Replace tabs with (2)spaces: %s/\t/ /g
-Replace (2)spaces with tabs: %s/ /\t/g
NOTE: These are obviously not made to be safe with string in your code, they will manipulate anything in the file
2) Build tips for linux:
-When using a make file use the -j# argument to specify how many jobs this make uses, generally you should use the number of core your computer has plus one. So on a quad core computer it should look like: make -j5
-For time consuming builds, screen can be a lifesaver. Screen is a linux utility you can use that will essentially make a virtual client, one that does not expire when you close your SSH connection. So you can start a build on a server, and leave it running, close your connection and come back to it later. I'll list the basic commands here, for more detail go here.
$ screen <-- open a new virtual client
(Once in a 'screen') Ctrl+a d <-- detach from the screen
$ screen -R <--Reconnect with the screen
NOTE: if you use screen twice instead of using -R, you will make a second client, and -R will no long work, you will need -r and specify the screen id
Thats all the tips I can think of right now. Hope this helps someone.
My posts often lack anything particularly helpful to the reader, so I'm just gonna list some tips I've either found or been given. Just to make this worth your time reading.
1) Its always a good idea to keep your whitespace clean in your code, heres a few regex commands that can help keep your code nice and clean (mind you these are all for vim, but you should be able to translate most of them to other apps(ignore the %, thats vim only)):
-Remove whitespace at the end of a line: %s/\s$//
-Replace tabs with (2)spaces: %s/\t/ /g
-Replace (2)spaces with tabs: %s/ /\t/g
NOTE: These are obviously not made to be safe with string in your code, they will manipulate anything in the file
2) Build tips for linux:
-When using a make file use the -j# argument to specify how many jobs this make uses, generally you should use the number of core your computer has plus one. So on a quad core computer it should look like: make -j5
-For time consuming builds, screen can be a lifesaver. Screen is a linux utility you can use that will essentially make a virtual client, one that does not expire when you close your SSH connection. So you can start a build on a server, and leave it running, close your connection and come back to it later. I'll list the basic commands here, for more detail go here.
$ screen <-- open a new virtual client
(Once in a 'screen') Ctrl+a d <-- detach from the screen
$ screen -R <--Reconnect with the screen
NOTE: if you use screen twice instead of using -R, you will make a second client, and -R will no long work, you will need -r and specify the screen id
Thats all the tips I can think of right now. Hope this helps someone.
Thursday, December 8, 2011
Freedom and confusion at the end of the day
Luckily I am now done all my work for other courses, so I can pretty much submit all my time to OSD, which I am pretty happy about. Things are moving around quite randomly with the mouselock implementation at the moment, making trying to contribute to it fairly difficult... NorthWind and myself have been trying to get a piece of work for the reviews for the past few hours, but have been unable to find anyone to give us a solid answer on how things are being distributed. The IRC channel has been surprisingly dead considering it is the end of the semester, perhaps not everyone is scrambling to finish work for other courses at the time. So for the time being, I'm avoiding working on it entirely, as I don't want to end up wasting my time or breaking someone else's work. I would have hoped it worked out like the test assignment did, that we all had a central point to contact (in the case of the test assignment, rhung) to figure out who was doing what and how things were supposed to flow together, but alas, no dice.
Instead I am getting back to work on my involvement in the CubicVR project. I have been assigned the task of migrating an octree implementation into CubicVR and removing the current implementation. I am hoping to have this fully implemented and tested before next week, and have it land next week. Hopefully this will suffice for my 0.4 assignment. Luckily I already have a decent understanding of how octrees work, so the migration will hopefully be a piece of cake.
If people start showing up and talking in the IRC channel at some point today, I am likely to redirect my efforts back to the mouselock, but until then, I'll put myself to work on CubicVR.
Instead I am getting back to work on my involvement in the CubicVR project. I have been assigned the task of migrating an octree implementation into CubicVR and removing the current implementation. I am hoping to have this fully implemented and tested before next week, and have it land next week. Hopefully this will suffice for my 0.4 assignment. Luckily I already have a decent understanding of how octrees work, so the migration will hopefully be a piece of cake.
If people start showing up and talking in the IRC channel at some point today, I am likely to redirect my efforts back to the mouselock, but until then, I'll put myself to work on CubicVR.
Saturday, November 26, 2011
0.3 material testing system
I got all the common material types working into the testing system, and got the camera controls working so the materials could be more accurately checked. Not much else was added to the tester. I attempted to get another bug to work on, but the ones listed were either already taken or seemed like to large of bugs to pick up at this one. I'll leave ccliffe a message in hopes he can get me some more work to do. I feel the work done in this tester wasn't good enough to account for 0.3, so I guess my only option is to do an extra amount of work for 0.4 to make up for this.
Subscribe to:
Posts (Atom)