Hi J-S, You seem keen on working on things all by yourself, are you sure I can't > help, at least on documentation?
Haha yes of course you can help with the documentation. I only jumped in the first two since I'd already started them. I haven't really given the documentation much thought yet, but if you can identify some good cases to document go for it. It might also be a good idea to cast your eye over the new scripting stuff I just committed, you may think of a better way of doing it. Regards, Kim. On 14 October 2010 03:07, Jean-Sébastien Guay < [email protected]> wrote: > Hi Kim, > > You seem keen on working on things all by yourself, are you sure I can't > help, at least on documentation? In that past two days I went from thinking > I was going to take over the project entire (at least for the next release > or two) to you coming back and doing everything yourself! It's kind of a > dramatic change of direction for me, and I would have thought you would > welcome the help and delegate a bit of the 3 item list I made in my previous > message :-) > > That said, it's good to see activity on the project :-) > > J-S > > > > On 10/13/2010 5:04 PM, Kim Bale wrote: > >> Hi J-S, >> >> I think the python route would be the best actually, most developers >> will already have a python installation, and I would expect they >> would only need to run the script if they change shaders, otherwise >> the C++ files would stay the same. I was thinking of doing something >> like that myself. Up to you if you'd rather tackle it. >> >> >> I've just implemented this and will commit tomorrow once I've gone >> through it to make sure I haven't missed anything. >> >> 1. Give the VBO technique more testing with a focus on eliminating >> artifacts. If the technique is a step forward in performance but it >> has some significant artifacts then it will be less likely to be >> used in production applications - the performance gains will likely >> be overlooked. >> >> >> I concur, I'll merge it in over the weekend and see what can be done. >> >> 2. Clean up the shader code duplication with an automatic generation >> scheme. Again python would be my choice. >> >> >> 3. Expand on the usage documentation on the wiki, and perhaps >> include some documentation in the release tarball/zip as well. >> >> >> Well 2 is done and 3 shouldn't take too long, I'll chip away at it in >> the evenings. >> >> On a separate subject, we promised to have a look at Quintijn >> Hendrickx's osgRiver code to see if it would make sense for >> inclusion into osgOcean. >> >> >> Absolutely, I feel rather bad about this actually. It's a fairly >> substantial chunk of code and requires a fair amount of thought design >> wise. I kind of think it might be possible for to exist as >> a separate library, but with so many shared shader effects it seems >> silly to duplicate the code. Will definitely address this after this >> release. >> >> >> K. >> >> >> >> On 13 October 2010 01:21, Jean-Sébastien Guay >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Kim, >> >> Great to know everything is all right. I understand one can get >> burnt out on a particular project after a while, you didn't go into >> specifics and I totally understand that it may be a delicate subject >> but I'm glad to see you back at it once again! :-) >> >> >> So to your changes. The change to the way the shaders are >> integrated is >> a good approach in fact, the shader integration has troubled me >> for a >> while. My goal with inlining the shader code was to keep the >> library as >> compact as possible. However, it soon became a maintenance >> nightmare - >> people were submitting shader fixes and only editing either the >> inline >> code or the external files and keeping track of which version was >> correct was becoming very difficult. >> >> >> I agree 100%. >> >> >> I've already done some work to address this. So what I will do is >> augment your approach with a pre build script which will read the >> external shader files and generate headers which contain the >> shader code >> that are then included in the build. This should go some way to >> preventing any discrepancies between inline shaders and external >> shaders. I have already written batch scripts to do this in >> windows, and >> I think I made some progress in writing a similar bash script >> for linux >> too but I'm not sure whether I finished it. I'll have to have a dig >> around. Thinking about this, more recently I've starting using >> python as >> my scripting language of choice - I'd be keen to use python to >> do this >> but I'm not sure how people would feel about the additional build >> dependencies.. do you have any thoughts on this? Simply put it >> would >> make my life a bit easier since I'm windows based and testing bash >> scripts is a bit of a pain. >> >> >> I think the python route would be the best actually, most developers >> will already have a python installation, and I would expect they >> would only need to run the script if they change shaders, otherwise >> the C++ files would stay the same. I was thinking of doing something >> like that myself. Up to you if you'd rather tackle it. >> >> Instead of headers I would suggest one or more .cpp file(s) that >> would define say const char* osgOcean_water_surface_fragment_source >> = "..."; and then the FFTOceanSurface.cpp file would refer to that >> symbol and it would be resolved at link time. A header suggests it >> would be part of some public interface, which is not the case here. >> >> >> The ocean update callback is also a good approach, although I'll >> have to >> make sure to document it on the wiki otherwise it'll be missed. >> >> >> Good point, I was actually also thinking of doing a documentation >> pass because I think we're missing a kind of high-level document >> that explains a few use cases and what should work (in particular it >> would be nice to explain how to use osgOcean with osgShadow). Once >> again I can do this in the near future, before we do the next release. >> >> >> Since my last update I have fixed the VBO ocean technique so >> I'll commit >> that. I was rather disappointed by the performance gain though I >> noted a >> 10% drop on the draw traversal and a 80% drop in the update but no >> significant change in the frame rate. It also has the side effect >> of >> creating strange normals on the low resolution tiles. I'm rather >> dubious >> as to whether I've implemented the VBO update correctly so it >> would be >> good to see if improvements could be made there. >> >> >> I'll have a look when you get to committing the changes. The drops >> are good (I assume you mean drop in timings, not drop in performance >> :-) ), and I'm sure they will be more significant for real apps (in >> particular the 80% drop in update time is very welcome as the ocean >> will be more usable in debug builds now). >> >> >> I'll make a push to get these committed over the weekend, and >> will of >> course give your recent commits a thorough testing. Given the >> amount of >> fixes that have come in since 1.0.1 I think osgocean is due for >> another >> release so I'll make these changes asap and focus on getting >> another >> release out. >> >> >> Great to see we're on the same page. I think before we make a >> release the following milestones should be met: >> >> 1. Give the VBO technique more testing with a focus on eliminating >> artifacts. If the technique is a step forward in performance but it >> has some significant artifacts then it will be less likely to be >> used in production applications - the performance gains will likely >> be overlooked. >> >> 2. Clean up the shader code duplication with an automatic generation >> scheme. Again python would be my choice. >> >> 3. Expand on the usage documentation on the wiki, and perhaps >> include some documentation in the release tarball/zip as well. >> >> On a separate subject, we promised to have a look at Quintijn >> Hendrickx's osgRiver code to see if it would make sense for >> inclusion into osgOcean. I suggest we tackle this after the release, >> but it might be nice to have a look at that separately and then have >> a few back-and-forths to discuss what we thought. I just don't want >> to forget about it. I think I'll log an issue in the issue tracker >> for that. >> >> Thanks for getting back in touch, and for helping me push this >> forward once again, >> >> >> J-S >> -- >> ______________________________________________________ >> Jean-Sebastien Guay [email protected] >> <mailto:[email protected]> >> >> http://www.cm-labs.com/ >> http://whitestar02.webhop.org/ >> _______________________________________________ >> osg-users mailing list >> [email protected] >> <mailto:[email protected]> >> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
