Hi Mike. a little update to previous reply
somehow I overlooked that hogbox has in fact plugin, which can serve as inspiration for you own https://code.google.com/p/hogbox/source/browse/trunk/src/#src%2FhogboxXmlPlugins%2FhogboxPlugin Regards Sergey On Thu, Jun 26, 2014 at 1:53 AM, Sergey Kurdakov <sergey.fo...@gmail.com> wrote: > Hi Mike, > > yes, the question confuses when one starts to work with pure shader > environments. > > the approach is to have a custom format and custom materials which are not > so far implemented in core of osg. > > I found one osg compatible approach for materials see > https://code.google.com/p/hogbox/ > > while the code has nice materials class > > https://code.google.com/p/hogbox/source/browse/trunk/src/hogbox/HogBoxMaterial.cpp > > the code provided lacks loader, > > another example format for shader-only based osg is internal format for > http://osgjs.org/ > > there is though one catch - it is possible to save to this format from > osg, but load only in osgjs, but it might shed light on how to proceed with > own custom format > > https://github.com/cedricpinson/osg/tree/master/src/osgPlugins/osgjs > > also there is a split plugin which is needed if there is hardware > limitation on vertex count > > https://github.com/cedricpinson/osg/tree/master/src/osgPlugins/split > > Regards > Sergey > > On Thu, Jun 26, 2014 at 12:24 AM, Mike Metcalf <metcalfnos...@mac.com> > wrote: > >> We are putting together an mapping application targeted for the imx6 >> hardware. The drivers support GLES 2.0, with no fallback/support for >> previous versions. >> >> We have models and other resources in osgb files, and load them at >> run-time, attaching them to our scene graph as necessary. On our dev >> platforms (win7 and linux on x86) things render without issue, but when >> cross-compiled and deployed to our imx6 hardware, these osgb resources did >> not show. >> >> We traced it to bad shaders, and found on these forums that the reason is >> that ShaderGen.cpp was generating (fallback?) shaders which are not >> compatible with GLES 2.0. >> >> My first naive step was to modify the vertex and fragment shaders in >> ShaderGen to enable them to compile in our GLES GPU. We had to remove >> references to the fixed-function pipeline, and that included references to >> gl_Color (et al), which was how each vertex got it's starting material >> color. So... we could see our geometry on-screen, but the material colors >> as stored in the osgb file were unavailable. >> >> I then dug around GLSL 2.0 enough to tentatively conclude that the new >> method of supplying those vertex colors to the shader code is to declare >> vertex attributes in the vertex shader and then bind an array of attributes. >> >> But, and this is my question, how do we use the generalized approach of >> reading in osg::nodes from osgb files, attach them to the scenegraph and >> still bind attributes to them? >> >> It seems that we would either need to create a unique osg::program per >> osg::node we load and then somehow glean the vertex color information from >> the osg::node, load it into an array and bind that array to the shader >> program. >> >> Can anyone shed any light on this? I thing I'm missing something fairly >> fundamental. >> >> Many thanks in advance! >> >> Mike >> >> ------------------ >> Read this topic online here: >> http://forum.openscenegraph.org/viewtopic.php?p=59905#59905 >> >> >> >> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
