<div dir="ltr"><div>Hey, Sergey.<br></div><br>How is your work on emscripten port going?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-11 4:32 GMT+07:00 Sergey Kurdakov <span dir="ltr"><<a href="mailto:sergey.forum@gmail.com" target="_blank">sergey.forum@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi Robert,<br><br></div>after I wrote previous email I dug more into current emscripten way to convert gl calls.<br><br></div>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).<br></div><br>Now I will make another round to convert osg with new approach and see if it actually works for osg.<br></div><br></div>Thus disregard my first request.<br></div>Thanks for your time.<br><br></div>Regards<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">Sergey<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 6:25 PM, Sergey Kurdakov <span dir="ltr"><<a href="mailto:sergey.forum@gmail.com" target="_blank">sergey.forum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Robert,<br><br></div>you might notice, that I try to make a port of osg to emscripten<br><br></div>Overall osg 'for the web' works, but I found several issues with emscripten which require me to keep <br>quite a different copy of osg <br><br></div><div>The main issue are extensions.<br><br></div><div>The problem arises from how emscripten translates OpenGL to WebGL calls.<br><br></div><div>it takes<br><br></div><div>gl* functions in C code and directly substitutes them with webgl gl* functions.<br><br></div><div>Now it is clear what the problem is : that emscripten compiler does not understand extension functions which are set in the way <br><br>setGLExtensionFuncPtr(_gl*<br></div><div><br></div>let's take an example:<br><br>void Texture2DArray::Extensions::<wbr>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<br>{<br> if (_glTexSubImage3D)<br> {<br> _glTexSubImage3D( target, level, xoffset, yoffset, zoffset, width, height, depth, format, type, pixels);<br> }<br> else<br> {<br> OSG_WARN<<"Error: glTexSubImage3D not supported by OpenGL driver"<<std::endl;<br> }<br>}<br><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"> _glTexSubImage3D function won't be translated , <br><br></div><div class="gmail_extra">There are different ways to keep emscripten happy and use that glTexSubImage3D and I have forced it.<br>But the ways how i did so far - looks patchy and inconsistent ( lots of '#ifdef's where calls to extensions occur ) <br><br>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 ).<br><br>the solution which will satisfy emscripten with least invasive way seems to have<br><br>Extensions::_gl<br><br></div><div class="gmail_extra">functions everywhere and also<br><br>setGLExtensionFuncPtr(gl* //no _ before gl<br><br></div><div class="gmail_extra">approach to set extensions.<br><br></div><div class="gmail_extra">and for setGLExtensionFuncPtr - for emscripten there will be a special function to deal with what gl functions WebGL has and what not.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">so my question is - how feasible is to ask for _gl gl convention swap for extention _gl* functions and their Extensions::gl* wrappers?<br><br></div><div class="gmail_extra">Best regards<span class="m_7992334123061022731HOEnZb"><font color="#888888"><br></font></span></div><span class="m_7992334123061022731HOEnZb"><font color="#888888"><div class="gmail_extra">Sergey<br></div></font></span></div></div></div></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
<br></blockquote></div><br></div>