Hey, Sergey. How is your work on emscripten port going?
2015-04-11 4:32 GMT+07:00 Sergey Kurdakov <[email protected]>: > Hi Robert, > > after I wrote previous email I dug more into current emscripten way to > convert gl calls. > > It looks like it is now possible to build working code with current osg > naming scheme for extensions ( unfortunately emscripten documentation on > these issues is scarce, so I missed this possibility it in my previous > porting attempts). > > Now I will make another round to convert osg with new approach and see if > it actually works for osg. > > Thus disregard my first request. > Thanks for your time. > > Regards > Sergey > > On Fri, Apr 10, 2015 at 6:25 PM, Sergey Kurdakov <[email protected]> > wrote: > >> Hi Robert, >> >> you might notice, that I try to make a port of osg to emscripten >> >> Overall osg 'for the web' works, but I found several issues with >> emscripten which require me to keep >> quite a different copy of osg >> >> The main issue are extensions. >> >> The problem arises from how emscripten translates OpenGL to WebGL calls. >> >> it takes >> >> gl* functions in C code and directly substitutes them with webgl gl* >> functions. >> >> Now it is clear what the problem is : that emscripten compiler does not >> understand extension functions which are set in the way >> >> setGLExtensionFuncPtr(_gl* >> >> let's take an example: >> >> void Texture2DArray::Extensions::glTexSubImage3D( GLenum target, GLint >> level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei >> height, GLsizei depth, GLenum format, GLenum type, const GLvoid *pixels) >> const >> { >> if (_glTexSubImage3D) >> { >> _glTexSubImage3D( target, level, xoffset, yoffset, zoffset, >> width, height, depth, format, type, pixels); >> } >> else >> { >> OSG_WARN<<"Error: glTexSubImage3D not supported by OpenGL >> driver"<<std::endl; >> } >> } >> >> _glTexSubImage3D function won't be translated , >> >> There are different ways to keep emscripten happy and use that >> glTexSubImage3D and I have forced it. >> But the ways how i did so far - looks patchy and inconsistent ( lots of >> '#ifdef's where calls to extensions occur ) >> >> And I would like to have an osg port which is minimally different from >> stock osg ( just ifdef ed threading functions - there are no threads in >> browser and there will not be any similar threading functions to one used >> in osg for foreseeable future ). >> >> the solution which will satisfy emscripten with least invasive way >> seems to have >> >> Extensions::_gl >> >> functions everywhere and also >> >> setGLExtensionFuncPtr(gl* //no _ before gl >> >> approach to set extensions. >> >> and for setGLExtensionFuncPtr - for emscripten there will be a special >> function to deal with what gl functions WebGL has and what not. >> >> of cause I understand - such a change might break quite a bit of user >> code in case I develop a patch for osg which follows such convention >> >> I have several other ways to deal - to write a special emscripten module >> which will be clever enough to use both gl and _gl functions during >> translation phase, but then - it is hardly possible that it will be >> accepted to emscripten as it will be needed only for my port and any user >> will need to hack emscripten to compile osg for web. >> >> so my question is - how feasible is to ask for _gl gl convention swap for >> extention _gl* functions and their Extensions::gl* wrappers? >> >> Best regards >> Sergey >> > > > _______________________________________________ > 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
