It took me some time to figure out how CubicVR works, but now I have a basic understanding of its workings and was able to create a 0.1 release that isn't completely worthless. The issue was that when a material was initialized with an opacity of 1.0, it could not because changed because the shader was already setup not to do alpha blending for performance reasons. Subsequently, material that started opaque could never change.
My development proceeded in three steps. First, I created a tester page to recreate the bug so that I could test to see if my solutions had fixed it or not. This tester can be found here. I simply displayed two boxes on screen with the camera spinning around it with controls at the top to adjust one of the box's material's opacity, which started at 1.0. This tester was partially based off of the Normal Mapping render tester that was already on the repo.
The second step was a very simple fix by forcing all opaque objects to having blending on them. This fixed the issue but at a needless cost, so I had no intention of considering it an actual fix.
The final step was the development of the fix submitted as the 0.1 release. This fix kept track of whether or not the material had blending enabled on it, while the system was rendering the materials if it came across a material with blending not enable and an opacity below 1.0, the shader would be cast aside and a new one generated on the spot. Its obviously not the best solution, but it seems to work well enough for the time being.
Thursday, September 29, 2011
CubicVR Material Bug
I have been suited with a material transparency bug for the CubicVR 3D graphics system. The problem seems to be that when a material is initialized with an opacity of 1.0, that it cannot be changed afterwards. It was mentioned that the material system might just as well benefit from some form of dirty flag that will force the material to be regenerated during the next cycle so that inconsistencies like this should not be an issue any longer. I had a fair bit of experience in 3D graphics (for about a year now) so I was also asked to look into another issue, which is to create an automated test suite for the all of the commonly used material types. If no one else ends up wanting to grab that one, I might take it on board as well.
I have just recently completed a small test page that replicates this issue so it should make it easier to identify the state of my bug fix as I am developing it. It is a simple pair of boxes with the camera spinning around it and a control at the top of the page to allow you to change the transparency of one of the boxes, using the other box as a reference point. Its nothing spiffy but with it complete I am hoping I can have a rough bug fix ready before mid-night.
I have just recently completed a small test page that replicates this issue so it should make it easier to identify the state of my bug fix as I am developing it. It is a simple pair of boxes with the camera spinning around it and a control at the top of the page to allow you to change the transparency of one of the boxes, using the other box as a reference point. Its nothing spiffy but with it complete I am hoping I can have a rough bug fix ready before mid-night.
Wednesday, September 28, 2011
The Open Source Community Readings
The readings for week 2 were pretty interesting , both based around the same concept, the open source community, but both presented in different and interesting ways. Both of their concepts seemed to be tried to inspire the same thing, the motivate people into jumping into the open source community, because they David said, you are not going to be invited in.
The most powerful idea they both seemed to be presenting was that, trying to wait and build up your skills before jumping into the open source community is a flawed approach, though one that is pretty much the standard approach used elsewhere. They tried to emphasize that its OK to just jump in and absorb whats going on around you, its OK to try and fail. By simply taking part in any small part of the community, you are helping build the community, and even if what your attempting to do fails, you will learn enough not to make the same mistakes the next time and you will grow more integrated into the community.
One thing that struck me about what Mike Beltzner said was that one of the most useful skills you will learn in the open source community is who you should listen to, and who you can safely ignore, and that you can probably safely ignore 80% of the those who are communicating in the community. This spurred a few conflicting thoughts in my head, while I would naturally completely agree with such a statement, that most talk is simply noise, it makes me wonder if that means in the open source community, if you are just entering the scene, does that mean your goal is to try and fight your way into the 20% margin of people worth listening to? Or is it OK to simply go ignored until you have done something worth listening to, though this sorta conflicts with the idea that you should just jump in and try....
One last thought I had came from David's speech about the festivals. By simply going to the festival, does that really make you part of the community? Or are you simply there to utilize the fruits of the community's efforts? What I am trying to differentiate is the use of the community vs participating in the community. A festival doesn't come together the day of, it requires much planning and preparation, and by simply going to the festival doesn't make you a part of it. How do you make the transition from festival goer to actually participating in it? While I believe there is value in going and seeing and understanding the activities, the transition into actually becoming a part of it hasn't been well illustrated here...
The most powerful idea they both seemed to be presenting was that, trying to wait and build up your skills before jumping into the open source community is a flawed approach, though one that is pretty much the standard approach used elsewhere. They tried to emphasize that its OK to just jump in and absorb whats going on around you, its OK to try and fail. By simply taking part in any small part of the community, you are helping build the community, and even if what your attempting to do fails, you will learn enough not to make the same mistakes the next time and you will grow more integrated into the community.
One thing that struck me about what Mike Beltzner said was that one of the most useful skills you will learn in the open source community is who you should listen to, and who you can safely ignore, and that you can probably safely ignore 80% of the those who are communicating in the community. This spurred a few conflicting thoughts in my head, while I would naturally completely agree with such a statement, that most talk is simply noise, it makes me wonder if that means in the open source community, if you are just entering the scene, does that mean your goal is to try and fight your way into the 20% margin of people worth listening to? Or is it OK to simply go ignored until you have done something worth listening to, though this sorta conflicts with the idea that you should just jump in and try....
One last thought I had came from David's speech about the festivals. By simply going to the festival, does that really make you part of the community? Or are you simply there to utilize the fruits of the community's efforts? What I am trying to differentiate is the use of the community vs participating in the community. A festival doesn't come together the day of, it requires much planning and preparation, and by simply going to the festival doesn't make you a part of it. How do you make the transition from festival goer to actually participating in it? While I believe there is value in going and seeing and understanding the activities, the transition into actually becoming a part of it hasn't been well illustrated here...
Tuesday, September 27, 2011
Open vs Closed Licenses
For this entry I have read the BSD license and the proprietary license for Skype. I will be illustrating 3 things about these licenses that stuck out to me below.
The first thing that stuck out to me was their vastly differing sizes. The BSD license seems to be written in a broad, vague, all encompassing manner using very simple and easy to understand concepts to dictate the purpose of the license. It would seem that it is written this way to invite people to read, understand and use the license to its fullest. In contrast, the Skype license is very long, repetitive and very bloated, repetitively using long strings of synonyms to concretely dictate very simple ideas that could be written much more concisely. It seems the purpose of this tactic is so that consumers will not actually read these and simply agree to them, thus allowing them to sneak in sketchy terms that the user might otherwise not agree to.
The second things that stuck out was not a difference between the licenses, but a similarity. Both licenses dictate that if the software somehow ends up causes any form of damages, that the copyright holders are not liable. With the BSD license, it pretty much flat out states that no matter what you can't go after the copyright holders for anything no matter what the software may end up damaging. The Skype license spends several paragraphs dictating what they are not liable for, but at no point flat out states that they are not at all liable for any damages as the BSD license does. Interestingly, the Skype license also spends a fair bit of time dictating what belongs to what company, presumably spreading around liabilities.
The final thing that stuck out specifically about the Skype license is that they pretty much state that you don't own anything and that they can change anything as they will without notice. If you purchase a phone number from them, in the eula they state that you do not own it, that they can change it at any time and that you cannot transfer ownership to another person if you wish. It also states that any content you put up can be taken down for any reason at any time and they are not required to put it back up or return it to you. They also reserve the right to cancel your account at any time if they believe you have in anyway broken any agreements you agreed to, which can be changed at anytime and by simply continuing to use the product you agree to the amended terms.
Those are what really stuck out to me about those licenses. One thing it makes me question is the viability of the BSD license in a business situation, because the use of it makes it impossible to hold the creators liable, making it hard to want to invest time/money into software could fail at any time and there would be no one liable for the possible damages or loss of data/time/money as a result of the failures....
The first thing that stuck out to me was their vastly differing sizes. The BSD license seems to be written in a broad, vague, all encompassing manner using very simple and easy to understand concepts to dictate the purpose of the license. It would seem that it is written this way to invite people to read, understand and use the license to its fullest. In contrast, the Skype license is very long, repetitive and very bloated, repetitively using long strings of synonyms to concretely dictate very simple ideas that could be written much more concisely. It seems the purpose of this tactic is so that consumers will not actually read these and simply agree to them, thus allowing them to sneak in sketchy terms that the user might otherwise not agree to.
The second things that stuck out was not a difference between the licenses, but a similarity. Both licenses dictate that if the software somehow ends up causes any form of damages, that the copyright holders are not liable. With the BSD license, it pretty much flat out states that no matter what you can't go after the copyright holders for anything no matter what the software may end up damaging. The Skype license spends several paragraphs dictating what they are not liable for, but at no point flat out states that they are not at all liable for any damages as the BSD license does. Interestingly, the Skype license also spends a fair bit of time dictating what belongs to what company, presumably spreading around liabilities.
The final thing that stuck out specifically about the Skype license is that they pretty much state that you don't own anything and that they can change anything as they will without notice. If you purchase a phone number from them, in the eula they state that you do not own it, that they can change it at any time and that you cannot transfer ownership to another person if you wish. It also states that any content you put up can be taken down for any reason at any time and they are not required to put it back up or return it to you. They also reserve the right to cancel your account at any time if they believe you have in anyway broken any agreements you agreed to, which can be changed at anytime and by simply continuing to use the product you agree to the amended terms.
Those are what really stuck out to me about those licenses. One thing it makes me question is the viability of the BSD license in a business situation, because the use of it makes it impossible to hold the creators liable, making it hard to want to invest time/money into software could fail at any time and there would be no one liable for the possible damages or loss of data/time/money as a result of the failures....
Thursday, September 22, 2011
Sickness, recovery, and so many open sores...
I'll start with the obligatory yet meaningless reason as to why this is my first blog in some time; I got pretty sick last week and I really wasn't able to accomplish much of anything. I am finally catching up on my work now and though this post will be quite outdated and possibly meaningless, I'll write it anyways, gotta keep the spirit alive right?
The readings put open source development is a slightly new light that I hadn't considered before. I have never been a huge supporter of open source development, not that I am particularly against it, but I am just not one to look at a proposed methodology and simply accept it as being a more correct or superior methodology without having given all other methods serious consideration. With that said, open source development does seem to have a very concrete and everlasting place in the software development world. Still I can't see it overtaking all aspect of software development, closed source development has just as concrete a future in the software world.
The cathedral and bazaar paper illustrated where I think open source development really thrives, where people have a common issue they need solved. With Eric's example of his fetchmail project, he made it seem that he was able to muster up such an large number of people to assist him because they wanted to see the product work, they wanted the problems that they had fixed and that they just wanted to feel like they were contributing something useful. Though I have started noticing more and more that open source seems to be more like an intern program, something you do simply to be able to put it on a resume or to start making contacts and gaining experience, be it unpaid. But perhaps my views on this are clouded, on the tail end of college and only seeing this trend in my peers desperately clamoring for employment.
There is one thing I find brilliant about the bazaar method, quite obviously its greatest strength, which is illustrated in Eric's version of Linus' Law; "that given enough eyeballs, all bugs are shallow". Any programmer knows that finding bugs and narrowing down their cause is likely to be your greatest source of wasted time when you are trying to develop something. Having your clients act as testers and developing rapid fixes for the bugs that arise is probably the best way to make the most out of your programmers time, allowing them to develop more things faster. But this does come with one risk, and that is of course taxing your clients patience, which is why the split distribution is such a good idea, having one stable and one unstable build, allowing the clients to revert to the stable versions if they simply want to work with the product without dealing with bugs.
That about raps up my thoughts on these readings. One thing I did find funny about the people in the video was that, you would think that open source figures like them would be open and (to a degree) submissive but in fact they came across as very territorial, especially towards each other.
As a last note, I filled in my wiki page with some basic information about myself, so if you want to know a bit more about me, check out http://zenit.senecac.on.ca/wiki/index.php/User:CloudScorpion.
The readings put open source development is a slightly new light that I hadn't considered before. I have never been a huge supporter of open source development, not that I am particularly against it, but I am just not one to look at a proposed methodology and simply accept it as being a more correct or superior methodology without having given all other methods serious consideration. With that said, open source development does seem to have a very concrete and everlasting place in the software development world. Still I can't see it overtaking all aspect of software development, closed source development has just as concrete a future in the software world.
The cathedral and bazaar paper illustrated where I think open source development really thrives, where people have a common issue they need solved. With Eric's example of his fetchmail project, he made it seem that he was able to muster up such an large number of people to assist him because they wanted to see the product work, they wanted the problems that they had fixed and that they just wanted to feel like they were contributing something useful. Though I have started noticing more and more that open source seems to be more like an intern program, something you do simply to be able to put it on a resume or to start making contacts and gaining experience, be it unpaid. But perhaps my views on this are clouded, on the tail end of college and only seeing this trend in my peers desperately clamoring for employment.
There is one thing I find brilliant about the bazaar method, quite obviously its greatest strength, which is illustrated in Eric's version of Linus' Law; "that given enough eyeballs, all bugs are shallow". Any programmer knows that finding bugs and narrowing down their cause is likely to be your greatest source of wasted time when you are trying to develop something. Having your clients act as testers and developing rapid fixes for the bugs that arise is probably the best way to make the most out of your programmers time, allowing them to develop more things faster. But this does come with one risk, and that is of course taxing your clients patience, which is why the split distribution is such a good idea, having one stable and one unstable build, allowing the clients to revert to the stable versions if they simply want to work with the product without dealing with bugs.
That about raps up my thoughts on these readings. One thing I did find funny about the people in the video was that, you would think that open source figures like them would be open and (to a degree) submissive but in fact they came across as very territorial, especially towards each other.
As a last note, I filled in my wiki page with some basic information about myself, so if you want to know a bit more about me, check out http://zenit.senecac.on.ca/wiki/index.php/User:CloudScorpion.
Tuesday, September 6, 2011
OSD600 Blog
I am not really gonna say anything in this blog post, simply putting it in to make sure it works.
Subscribe to:
Posts (Atom)