Hi JS, I did an initial review last month but I wasn't happy about merging it directly without further investigation and thinking at my end. I can't remember the details, but the submissions is still in my submissions folder so I should get back to it.
Robert. On Tue, May 18, 2010 at 1:10 PM, Jean-Sébastien Guay <[email protected]> wrote: > Hi Robert, > > I realized I had sent this to osg-users, so perhaps that's why it was > forgotten... Sorry about that. Still, it was still on my mental stack so I > thought I'd follow up on it. > > It's a minor change, granted, but I'd like to mark it as resolved in my mind > (either by you merging some code or telling me you won't...) > > Thanks, > > J-S > > On 19/04/2010 10:13 AM, Jean-Sébastien Guay wrote: >> >> Hi Robert, >> >>> I don't believe removing newlines that exist in strings from >>> Ouput::wrapString() is appropriate. If a newlines are in a string it >>> really should be honored. >> >> That's not the problem. Please re-read my description. If I send a >> string like this (I'm using indentation to show the point more clearly >> later): >> >> ---- start here ---- >> Here is some text >> >> There was no text on the above line >> >> >> There were two newlines above >> ---- end here ---- >> >> Then it should end up in the .osg file as: >> >> ---- start here ---- >> "Here is some text" >> "" >> "There was no text on the above line" >> "" >> "" >> "There were two newlines above" >> ---- end here ---- >> >> Do we agree about that? >> >> So the scheme is to remove the newline and replace it with a closing >> double quote and newline. Still with me? >> >> Well, that's what happens both with and without my patch if the shaders >> were inline in the code - such as in the osgshaders example. You'll find >> attached .osg files output from adding osgDB::writeNodeFile() to the end >> of the osgshaders example, both before and after my change. You can diff >> them, they're identical. >> >> The problem happens when shaders are read from files and contain DOS >> line endings. The result when reading the shader from a file and then >> outputting a .osg file (where the shader is re-embedded) would look like >> this (reusing the example above): >> >> ---- start here ---- >> "Here is some text >> " >> " >> " >> "There was no text on the above line >> " >> " >> " >> " >> " >> "There were two newlines above >> " >> ---- end here ---- >> >> I modified the osgshaders_before.osg file to refer to a file instead of >> inline code (see osgshaders.osg and its associated microshader.vert >> vertex shader file, with DOS line endings). Then I modified >> osgviewer.cpp to do osgDB::writeNodeFile(...) before viewer.run(). The >> result is osgshaders_read_write.osg, and corresponds to the example >> above. You'll see the difference. >> >> One weird thing is that using osgconv does not reproduce this problem. >> Does osgconv use a different code path than osgDB::writeNodeFile() ? The >> offshoot is that to test, you'll need to add an osgDB::writeNodeFile() >> to osgviewer.cpp. >> >> Perhaps the solution is not the one I gave. Attached (Shader.cpp) is an >> alternate change that replaces all "\r\n" with "\n" in the shader source >> that is read (like dos2unix). This also works for me (see >> osgshaders_read_write_after.osg), and is a simpler change (in terms of >> number of files touched but not in terms of lines of code...). What do >> you think? Feel free to suggest another perhaps better solution still. >> >> Thanks, >> >> 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
