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]> 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] > 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
