Hi everybody, I've kept pretty quiet so far. Not because I don't care, but because I wanted to wait until everybody said their piece, and because I was busy preparing more than words as a response. So here are my $.04 (this has gotten a little longer than usual)...
I agree with many of the things that have been said. OpenSG is (IMHO) technically superior to all other systems out there, but some of this superiority has been bought with technical complexity. Which is not a problem for the people that developed it, but it is a problem for getting more people involved. I've seen it coming, but I haven't limited it as much as I should have, partially because I was happy that the people that did the work actually did the work and I didn't want to scare them away. But as a consequence the OpenSG code is not that easy to extend. We tried to hide most of the complexity from the users, and were partially successful in that. The biggest gripes and confusions that I've heard the necessity of begin/endEdit, the use of special pointers and the fact that you can't just derive from OpenSG classes. Fixing two out of three for OpenSG 2 is not too bad, I think. ;) We've also been struggling, since the beginning, with better build support for Windows. MSVS is not an environment that is very friendly for people to use it from the outside, to put it very politely, and we (or at least I) usually tried to avoid dealing with it (VS is bad for my heart). But there is an increasing number of people that live and breathe VS, and we are having a hard time reaching them. Especially creating a new project that uses OpenSG in VS is a major issue. Other things that are/were suboptimal: Finding Oliver's Tutorial. It is a very good first step. If you can find it. Also, it is not included in the dists, which is just stupid. The main reason is that creating the dist scripts is quite a lot of boring work, and I never got around to it. What are other things that you think make it hard for people to get into and stay in OpenSG? I'd be very interested. OSG has done a better job at this, no doubt about it. The system looks much simpler, even though a closer look reveals that it is not really. Some of that is bought by (IMHO) noticeable shortcomings, but those only reveal themselves later, when the buy-in already happened. Their SO/DLL-oriented structure lends itself better to extensions, even though they only use it for loaders right now, AFAICS. Their website looks much nicer, thanks to a large number of screenshots. Graphics people are suckers for pictures. ;) I don't agree with Allen that the sky is falling, though (sorry Allen, couldn't resist ;). I don't doubt that their community is bigger than ours, but I do doubt that it is as significant a difference as they make it to be. Robert loves to use the number of posts as his main metric, and that's IMHO pretty weak. Looking at how long the threads drag on over there, getting a high number of posts is easy. Counting the number of threads would be more useful, but threads tend to wonder in topics, and they're much harder to count. It would also be interesting to see how many of the subscribers are silent and how many actually post and contribute, but again, that is much harder to measure. They have a nice contributor list, but it doesn't say anywhere what kinds of contributions they did. A single bug message could count as a contribution, and we got a lot of those, too (messages, not necessarily bugs ;). I'm also not that awed by the SIGGRAPH presentations. Most of the things that are planned for OSG 1.2 we have already in OpenSG (except Terrain, and OpenAL is not public). Their future plans are exactly like ours: OpenGL ES and OpenGL 3 (and we have the first one nearly done). Haptics are interesting, but just a wrapper around OpenHaptics and I don't see how they deal with the update rate differences between visual and haptics. Collada is good, but not that big a deal, IMHO, as it doesn't deal with shaders yet, just geometry. Diverse has very little to do with OSG. So IMHO a lot of it boils down to marketing. Which is important, but not a panacea. I'm not as worried as Allen is, but I agree that on an exponential curve being a little behind makes a big difference. So to answer your question: my goal for OpenSG is to be the best scenegraph I can help make it. Having said that: it's not my day job to do that. Being a professor gives me quite a bit of flexibility in how I spend my time, but not being tenured puts some pretty serious pressure on how to spend it. So right now I'm spending more than I should but not enough to pull it all out of the swamp. As such, it is hard to define a roadmap, as it is not clear how much time to expect from who to get things done (myself included). We all do this as our paying commitments allow. I know there are things that I want, and we've made some good progress on those, but defining '2.0 will have this and that and the other thing' is something I struggle with. I'd be happy to get input, though (please mention how much time you'd be willing to invest ;). Being able to work full-time on OpenSG would be nice, but I don't see a way to do that. Robert and Don were very brave to take this plunge, I'm just not that brave. I do agree that we have been notoriously bad about marketing what we have. Honestly most of it is because many things are not fully done yet, and we've been doing them for so long that they don't seem to be special any more. The website was designed a long time ago and doesn't really fit today's expectations any more. And I cannot believe how many people don't get the two-level menu system... ;) Now to what we can do (and are doing) to remedy some of this. Website: Allen and I have been working on getting a better website system up and running. Check out http://opensg.vrsource.org . It uses Trac (trac.edgewall.org), which is a nice integration of Wiki, SVN, Bugtracker and more, like a roadmap system based on tickets. I like it, because it is pretty tightly integrated and easy to use. The whole website is a Wiki now, and I would love to see people adding bits and pieces to it, especially to the FAW, HDI, Gallery and Community parts. The Gallery is a bit clunky still, I'll have to look for a better way of doing that (might be my first Trac plugin... ;). I would also like to get some feedback on the general structure. I looked at a lot of Open Source projects and took the pieces that I think matter to us. Note that currently the Trac svn is a little out of date, we'll move the SF svn over there soon unless there are serious reasons not to. Build System: again, Allen and I (more Allen on this one) have been working on getting an SCons-based build system up and running, that cleans up a lot of the magic compiler options we used to need, and that automatically finds installed libs etc. We still need to finish it and try the minimal installation needed to make it work with VS, but I think we have a good chance to make it work. What would be perfect if somebody had some experience in setting up a VS Wizard for new projects, which would make it very simple to help people use OpenSG projects. If possible it should be for VS2003 and VS2005, as both of those are still heavily used. A quick google found some info about it, but they seem to be very different from each other. One thing I do know I want for 2 is using precompiled headers. Especially with using STL, some boost and our own template magic, header preprocessing is a big chunk of compile time. Currently the bison/flex files are just included in the svn, which alleviates the need for having flex/bison, unless you change the .yy or .ll files. Given that the installation comes through python too, there shouldn't be a need for cygwin any more. There is still quite a bit of work to make the build system complete, but IMHO SCons gives us a better environment in general for making it work quickly. Related to the build system is the library structure, which is the main reason why we have to be pretty careful about including optional things, as right now we have very few libs that depend on a lot of things. So if one of them is missing, the lib won't load and the system won't work. 2 will move to a more fine-grained system, which will also help with link times. There are still a bunch of questions with that, I've posted another mail on the core list about that. Complex code: one of the main goals for 2 (there is that roadmap thing again ;) was to simplify the code, both for users and for extenders/developers. Part of that is getting rid of begin/endEdit (that's done), and also simplifying a lot of the internal code (getting rid of special pointers and a lot of the templates is some of that). I don't see a way to make it as simple as trivial C++ lib, especially to keep clustering working we do need capabilities from our data structures that raw C++ doesn't give us (so fcdEdit resp. fcdProcess will stay. We should probably move it over to python though, to get rid of needing perl in the system. Sorry, Gerrit). There are probably still things that are considered too complicated, and I'd be interested in hearing about them. Examples/Demos: That's IMHO one of our biggest weakneses. We don't have cool demos, and the dists have very few real examples. We have the SceneViewer, but it's pretty useless without QT (and it's written against QT3 anyway). It would be good to have something that can beused as a framework of sorts for demos, which makes it easy for people to add a new code snippet that demonstrates a cool feature, and that people can use to base their own programs on (not unlike Performer's perfly). It would need to use a free GUI toolkit that is portable (Fox? wxWidgets?). We would also need some demo data (maybe we can pinch some from OSG? ;), and a little bit of animation to make it look interesting. Documentation: There are many widely varying opinions on this, me thinks. Everybody wants more documentation, but I'm unsure what people really need. Well, except the 'here's how to do what you want to do' document. ;) Personally I think a well-designed system shouldn't need a lot of documentation, the names of functions and parameters should stand for themselves, but maybe that's just me. I agree that we need more examples, and I would love to get contributions on this one. I think we need to shift the tests and tutorials down a bit, and turn them into unit tests and examples. The unit tests should be very simple and really just test a very specific feature for correct operation, without interaction or anything. The examples should be better than tests in the sense that they demonstrate a feature and show how it's used, but without the lengthy explanations of the tutorials, which take a lot of time to write. It would be nice if we could make the examples short enough to fit them into the documentation, to be ready for cut-n-paste. Maybe by using a common skeleton, similar to the tutorials and moving all the actual work into a single function that is doable. I've heard the cry for a parameter-by-parameter documentation a number of times, and I have a hard time subscribing to it. I think most of our methods are self-explanatory just by the parameter names. If you could give me examples where you couldn't get to understand what the function/method does without documentation I'd be interested. What I think would make more sense, and I have spent some time on it, is a conceptual level documentation that explains the concepts and the goals, and actually most of the parameters in the form of the related pages in the doxygen docs. Most of those should be linked from the class reference page and be easily accessible. Are those useful and used? If not, why not? What's missing? I'm not a big fan of documentation that explains me that the parameter 'child' of the method 'addChild' is the child that is added. We also have a ton of auto-generated code, and having docs that say 'setBla() sets the bla value' is not very helpful. I don't want to read that, and I certainly don't want to write it. I'm not a big fan of having the docs inside the headers, as many of our headers are already pretty long, and adding a slew of docs won't help with that. Do you have good examples for this kind of documentation? I would also be interested in good examples for documentation in general (finding bad ones is easy ;), so if you have a system that is exceptionally well documented, please send me a link. I took a quick look at CGAL, and yes, that's impressive, but it lends itself much more to this kind of documentation as every piece is very self-contained. In a scenegraph most of the stuff is involved in setting up the structures and then you say render and expect a correct image. Gerrit mentioned the documentation build times: those are a serious problem. Doxygen takes longer than compiling the whole system (twice) plus examples. For developing I turn off everything except the piece I'm working on, and that's bearable, but not a good solution. I've tried profiling doxygen a few times, and I couldn't come up with a quick fix that significantly improved performance. Putting the .dox-equivalents into the Wiki would be an option. I don't know if we need to get them back at all. The only real loss would be the printed documentation, and maybe offline browsing of documentation (not sure how much of a problem that is these days). I could live with it, especially on Trac I think it's easy to link from doxygen to Trac pages (I need to verify that). Animation/Higher-Level Systems/Manipulators: As said in a previous mail, I absolutely see the need, and I would like to add hooks to make it easy to use, but I don't have the bandwidth to lead the design/development. I don't have strong ownership feelings about any of the stuff mentioned above (there is some stuff that I haven't mentioned that I do ;). So if anybody thinks that he or she can put some effort into any of them, that would be very much appreciated. Comments (hopefully lots ;)? Dirk ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
