Re: [osg-users] [build] Building OSG 3.6.4 in Win64 TDM GNU.
Until you mentioned the TDM compiler suite I had not heard of it. A lot of developers/companies will only engage on something like this on a Time and Materials basis with clear goals. The costs for engaging a bespoke port of OSG and all dependencies will not be cheap. Day rates will probably be on the order of £350 to £800 depending on if you are able to engage a developer directly or a small software house. I would suggest that you need to define clearly the following: • What Plugins you need for OSG • What Windows OS variants you need this to work on • If you need debug/release libraries • If you need 64bit and/or 32bit support • What GPU(s) you are targeting • Fixed pipeline OpenGL or modern OpenGL or both • Do you need osgQt • How you intend to perform acceptance test. I would also suggest answering some of the questions already raised such as the one from Robert ‘Could you explain what your project goals and constraints are’. I would also suggest asking yourself the question; would it be cheaper to port your application to Visual Studio? Sent from Mail for Windows 10 From: Zachary1234 Sent: 09 September 2019 10:43 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [build] Building OSG 3.6.4 in Win64 TDM GNU. Back to the main thread, Dear kornerr, is there somewhere else other than AlphaPixel that could help with a TDM/GNU Win64 build, given that AlphaPixel can't help me? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76649#76649 ___ 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
Re: [osg-users] Question about security of shader developments
Hi, I don't know what the OSG solution to this would be. You could obfuscate the shader code. Though to be honest this would only slow someone down not stop them from obtaining the shader source. In addition to obfusication put the shader source into the DLL/exe and potentially hide the strings by a simple rotation or masking of the data. You could add additional logic to detect OpenGL/GPU debuggers and/or check the OpenGL shared library is loaded from sensible locations. The other options would be to look at the following in OpenGL. I've not used either of them so they may not work particularly well. - https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt (OpenGL 4.6) - https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glShaderBinary.xhtml (OpenGL 4.1) You may find that the SPIRV extension is not widely supported yet on all GPUs and drivers (mesa support is not yet there) that your customers are using. SPIRV modules are an intermediate compiled representation of the shaders so someone with a lot of time could reverse engineer. The shader binary I believe may be limited to the GPU/driver that it was compiled for. Also OSG would need to be modified to use SPIRV or shader binaries. Most of this is a trade off between cost of implementation, additional test and support costs and lost revenue. Regards Damian On Wed, 30 Jan 2019 at 17:50, Werner Modenbach wrote: > Dear Robert, dear community, > > I use OSG since many years now with great success. But being honest I > usually just use the osg api and direct gl calls are very rare in our code. > That's the reason why I ask people with more gl experience here. > I'm working in a commercial environment. Unfortunately we have very bad > experience about the security of our developments > especially with a famous Asian country. Cracking and copying is the > normal case there. > During the years we have established a quite secure environment for our > executables by encrypting the them and by detecting > debugging and sniffing tools running in parallel. > There is mainly one really weak part, the shaders we develop. > We spent years now in very complex and highly optimized shaders and I > have sleepless nights knowing that the shader code is > transferred to the driver as plain source code. > My question: Is there any way solving this problem? Is there any driver > api for that? I searched all over OSG but didn't find anything. > Is this feature missing in general or is it just not in the OSG api? > If all the questions are answered NO can anybody provide a contact to > NVIDIA for discussing this problem? > > Many thanks in advance for any hints and help. > > - Werner - > > > ___ > 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
[osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE
Hi, I have a build of OSG 3.6.2 for GLCORE for Mesa 18.0.5, Intel HD Graphics 620. I am seeing a lot of warnings/errors around the use of PointSprite. The warnings/errors are (once per PointSprite): Warning: detected OpenGL error 'invalid enumerant' at after RenderBin::draw(..) Mesa: User error: GL_INVALID_ENUM in glEnable(GL_POINT_SPRITE) The Intel Mesa i965 driver is fairly strict with regards to Core Profile and does not provide a compatibility profile. I'm using osgEarth so I have to build for Core Profile for osgEarth to work. I've looked at trying to add additional logic to stop OSG from calling glEnable/glDIsable for GL_POINT_SPRITE but I can't see a sensible place to disable calling to glEnable/glDisable. Core Profile says that GL_POINT_SPRITE is always on so I believe that all that needs to be done is to not call glEnable/glDisable for GL_POINT_SPRITE. Regards Damian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
