[osg-users] a question on extension functions convention

[michael kapelko]

Hey, Sergey.

How is your work on emscripten port going?

2015-04-11 4:32 GMT+07:00 Sergey Kurdakov <sergey.forum at gmail.com>:

> 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 <sergey.forum at gmail.com>
> 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
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20161105/47f07c90/attachment-0001.htm>