Re: [osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016
Is there anyone who can help with a prebuilt version of OSG for a GNU C++ 64 bit Windows Compiler, particularly the TDM one? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75576#75576 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to change camera's yaw and pitch, and move front, back and sideways according to that?
Hi Rodrigo, The Camera::setViewMatrixLookAt function is equivalent to the gluLookAt. You can find more documentation on the inner workings here (https://stackoverflow.com/questions/21830340/understanding-glmlookat). If you don't set a camera manipulator prior to viewer.run() and move the camera the results will be lost due to viewer.run() setting up its own manipulator and overriding your initial setup. You have a few options: assign the camera manipulator -> update the manipulator -> call home(1) to force an update. Don't call viewer.run() and implement the loop yourself (this will prevent a manipulator from getting set and allowing you to freely manually manipulate the camera). Implement your own manipulator and set it before you call viewer.run(). If you have a specific question regarding one of the manipulators, please ask. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75575#75575 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to change camera's yaw and pitch, and move front, back and sideways according to that?
Dear Trajce, do you have any idea how incomplete is your answer? There's no point in knowing the function if I don't know how to set its parameters correctly. What everybody learning OSG need is "a simple source code showing how it's done", and this means a few lines of code, not less than a single line. Please. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75574#75574 ___ 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
You could obfuscate and minify your shader: https://github.com/laurentlb/Shader_Minifier Or hire a demoscene person to mangle it. ;) On Thu, Jan 31, 2019 at 11:43 AM Werner Modenbach wrote: > Hi Michael and all other people responding to my request, > > first of all thank you very much! > > @Michael: What you suggest is something like asking Zuckerberg to > publish his algorithms. > And belief me, Chinese don't care at all about patents > or other rules we usually accept here. > > I'm really surprised that there is no real solution for my problem. > Since OpenGL 4 all developers are advised to create their own shaders. > And once you get familiar > with that you quickly discover the potential of it. A good portion of > your know how gets transferred to shaders. > This should be a common problem in the commercial field. And no solution > from NVIDIA etc. ? > > @Robert: Thanks for pointing me to SPIR-V. I'll have a look at it. > Anyway better than pure source code. > Unfortunately not natively supported by OSG. > > Hiding shader source code inside an executable is not that problem > because all our executables are encrypted. > And memory spy during runtime is detected already. > The problem here is the driver api. > > @Damian: Do you have any links for detecting OpenGL/GPU debuggers? > > Many, many thanks to everybody. > > - Werner - > > Am 31.01.2019 um 10:29 schrieb michael kapelko: > > Hi. > > > > You may have a look at the problem from a different angle. If someone > > is stealing from you that means they need it. If you cannot stop it > > (or it costs much more than simply let them have it), then you should > > lead it. Instead of hiding your great shaders you can publish them > > yourself (don't forget to add some notes about your company in the > > comments)! This would be the marketing way of handling the problem. > > > > On Thu, 31 Jan 2019 at 12:17, Damian Dixon > wrote: > >> 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
Re: [osg-users] [3rdparty] How to change camera's yaw and pitch, and move front, back and sideways according to that?
Hi, viewer.getCamera()->setViewMatrixAsLookAt On Thu, Jan 31, 2019 at 10:01 AM Rodrigo Dias wrote: > I want to change the camera direction with the mouse, and position with > the keyboard. I've found an example on how to change the position, but > still couldn't find anything explaining how to change the direction (and > not sure if the position will change correctly when the direction changes). > All I find is "take a look at the manipulator source code, it will give > inspiration" etc. But I just don't get how can I implement that from the > source code I saw. > > Considering this is such a trivial task, why is it virtually impossible to > find a simple source code showing how it's done? > > Thanks, > Rodrigo > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=75567#75567 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- trajce nikolov nick ___ 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 Michael and all other people responding to my request, first of all thank you very much! @Michael: What you suggest is something like asking Zuckerberg to publish his algorithms. And belief me, Chinese don't care at all about patents or other rules we usually accept here. I'm really surprised that there is no real solution for my problem. Since OpenGL 4 all developers are advised to create their own shaders. And once you get familiar with that you quickly discover the potential of it. A good portion of your know how gets transferred to shaders. This should be a common problem in the commercial field. And no solution from NVIDIA etc. ? @Robert: Thanks for pointing me to SPIR-V. I'll have a look at it. Anyway better than pure source code. Unfortunately not natively supported by OSG. Hiding shader source code inside an executable is not that problem because all our executables are encrypted. And memory spy during runtime is detected already. The problem here is the driver api. @Damian: Do you have any links for detecting OpenGL/GPU debuggers? Many, many thanks to everybody. - Werner - Am 31.01.2019 um 10:29 schrieb michael kapelko: > Hi. > > You may have a look at the problem from a different angle. If someone > is stealing from you that means they need it. If you cannot stop it > (or it costs much more than simply let them have it), then you should > lead it. Instead of hiding your great shaders you can publish them > yourself (don't forget to add some notes about your company in the > comments)! This would be the marketing way of handling the problem. > > On Thu, 31 Jan 2019 at 12:17, Damian Dixon wrote: >> 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 > ___ >
Re: [osg-users] Question about security of shader developments
Hi. You may have a look at the problem from a different angle. If someone is stealing from you that means they need it. If you cannot stop it (or it costs much more than simply let them have it), then you should lead it. Instead of hiding your great shaders you can publish them yourself (don't forget to add some notes about your company in the comments)! This would be the marketing way of handling the problem. On Thu, 31 Jan 2019 at 12:17, Damian Dixon wrote: > > 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 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
