I spent a little time on the weekend taking a deeper look at the Unreal Development Kit (www.udk.com), and I continue to be shocked that they are giving out all this great technology to you and me to play with. And it really blew me away when I saw their Materials editor. There's a tutorial here, http://udn.epicgames.com/Three/MaterialsTutorial.html.
Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you're ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.
This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I've been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.
To see it in two places now, I'd love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out...
Tuesday, November 10, 2009
Saturday, November 07, 2009
Openness Shades of Grey
Motorola's newest phones are hitting the streets and promise Android goodness thanks to the latest Android release 2.0. Now if you think of Android as an open souce platform, you may have run over to the Android Open Source Project and tried to download the 2.0 source to see how they made it.
Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.
The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.
Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.
The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.
I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.
It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.
Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.
The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.
Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.
The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.
I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.
It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.
Friday, November 06, 2009
Unreal Development Kit
Wow. Unreal Development Kit. Free. Or at least free for free content. I've always wondered how developers create content for the big game engines, id and Unreal. And now I know and I have it installed on my laptop. For free. Can you tell I'm beside myself here. Check it out: http://www.udk.com.
At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).
Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.
And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.
That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...
At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).
Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.
And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.
That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...
Thursday, October 22, 2009
It's Crunch Time
I haven't blogged in a while so while I have my head above water, here's a few notes on what's happening lately.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
Thursday, October 08, 2009
A Good Leader is a Good Architect
I've been whining (yeah, that's pretty much the word) a lot recently about the state of contributions to the CDT and about the struggles I face even internally to get more time to spend on open source. I've been pretty frustrated and depressed about that and it's showing in my writing.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
Monday, October 05, 2009
Android Notes and Ideas for Eclipse
Here's a few notes on things I've been doing with Android. I'm under no delusion that I can actually create an app for Android. My wife wouldn't be too happy if I spend the time it would need. But I am finding that this is a great exercise getting into the mind of a mobile developer and is giving me ideas on how to improve the CDT and the Eclipse platform.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
Sunday, October 04, 2009
No where's that open source hat?
One of the points from my EclipseCon talk on building communities was "Wear two hats." Essentially, to successfully attract new contributions, you have to show that you are working in the best interest of the project as a whole. Of course, you also need to make sure the project is meeting the commercial needs of the vendor you work for or else that might not last long.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
Subscribe to:
Posts (Atom)
