Front Page › Forums › Installing and compiling › glew error when starting H3DViewer (compiled trunk version)
- This topic has 12 replies, 2 voices, and was last updated 6 years, 11 months ago by Markus.
-
AuthorPosts
-
April 19, 2017 at 12:36 pm #737448emilpalmParticipant
Hi,
I’ve tried to compile H3D on my own to have access to the newer version as well as the 2.3 release.
The compile process with Cmake (v3.8) and Visual Studio(2015, yes I have the vs2015 External checked out and replaced existing External folder) runs fine without errors but when I start the H3DViewer from bin64/ folder the following message is shown (glew_error.png) In the Cmake settings these are set related to glew (glew_cmake.png) any idea why this occurs?
I also wanted to compile with support for PhysX3, I’ve downloaded and compiled PhysX3.4 from NVIDIA GitHub repo. But when I set the external Physx3/ installation folder in Cmake the libs cannot be found (The include dir is found correctly but nothing else). See physx_cmake.png.
If I set the libs manually they are reset again when running the generation (which runs the configure again).
Is it so that since 3.4 was recently released that it is not yet supported and I should instead use PhysX 3.3.4? And by this is not found by Cmake?
Thank you for taking your time to answer my questions! 🙂
April 19, 2017 at 12:36 pm #727890emilpalmParticipantApril 20, 2017 at 5:48 am #737449MarkusKeymasterRegarding the glew error. It seems like the wrong glew dll might be loaded.
Please start using visual studio and check if you can see where it tries to load glew dll from. It should be in your External/bin64 directory. If you PATH environment variable is setup to point to External/bin32 then that would explain the problem.
The easiest way to test, is to copy from External/bin64 to the directory where you have the H3DViewer version that you start. Note that if you use visual studio then you do not use H3DViewer.exe that is in H3D/bin64 but rather the one that is somewhere in your build hierarchy.The easiest/fastest way to handle the PhysX3 cmake issue is to set them all manually.
If you want to do some more debugging you can debug H3DPhysics/build/modules/FindPhysX3.cmake and see if the names of libraries that it tries to match is very different from the names of your installation or if it is just that the location it tries to search in is wrong. (Check the find_library statements in the find module).April 20, 2017 at 7:19 am #737452emilpalmParticipantNow when you say it, my environment variables points to the 2.3 installation and that’s what causing that problem. Thank you!
Regarding the PhysX3.4 cmake issue,
The cmake file does not search the correct path when using vc14 to compile. In PhysX3.4 the “lowest” supplied solution files are for vc11 (not vc10, as the cmake file searches for).
If I add the following lines the libs and debug libs are found correctly:
[code]
${PhysX3_INSTALL_DIR}/../PxShared/lib/vc14win${lib}
${PhysX3_INSTALL_DIR}/Lib/vc14win${lib}
[/code]
The PxShared folder contains the PxTask libs.However the following libs:
[code]
PhysX3_PhysXProfileSDK
PhysX3_PhysXVisualDebuggerSDK
[/code]
are not found, and there are not libs named this in the release, making the PHYSX3_FOUND variable to be set to false and will not be included in the build. The two libs seems to have been removed from 3.3 -> 3.4 version of PhysX.April 20, 2017 at 7:28 am #737453MarkusKeymasterThen you will have to modify the cmake file a bit more. Just remove the creation of those cache variables. Either by removing those libs in a list, or just make sure they are not require for physx3 to be considered found.
April 20, 2017 at 10:49 am #737455emilpalmParticipantI did modify those away and CMake worked fine, though in the compilation of H3DPhysics the compliation crashes with a lot of errors (mostly C2039/C3861) which seems to be caused by H3D callbacks trying to access functions that no longer exists in the PhysX engine, am I right?
Btw, for anyone else that also tries to comile H3D together with PhysX3.4, the CMake file needs also to include the PxShared include dir to find its header files. I made it with an additional variable that was appended into PhysX3_INCLUDE_DIR at the end of the file.
April 20, 2017 at 11:27 am #737457MarkusKeymasterYou were using release 2.3 right?
Could be that the version of PhysX that existed when that was implemented always had these. Trunk might have #ifdefs” to handle these cases.
April 20, 2017 at 11:42 am #737459emilpalmParticipantIn this matter the latest trunk version, at least from yesterday or maybe the day before, to have a fresh version to test problems that occurs if they are already solved in the latest version of H3D before posting in this forum to get the answer that it is already solved 🙂
the #ifdefs does not seem to be existing in trunk.
If not the environment variables(set to old 2.3 version, $H3D_ROOT, $H3D_EXTERNAL and bin folders in $PATH) break things in the compilation, which I don’t believe…?
April 20, 2017 at 12:44 pm #737461MarkusKeymasterH3D_EXTERNAL_ROOT might affect where it finds externals that are in the External directory (i.e not physx).
Ok, then I need to find some time to setup tests for compiling against that version of physX3.April 20, 2017 at 1:14 pm #737462emilpalmParticipantI reset the environment variables to point to trunk version, same problem when compiling, did not affect the outcome 🙂
April 21, 2017 at 8:06 am #737464MarkusKeymasterCrappit. I have to test then.
I probably won’t have time until next week though. It would help if you could point out the link to the physx3 version you use.
April 21, 2017 at 9:04 am #737465emilpalmParticipantWell, it is not in a rush, but it would be nice 🙂
I use the PhysX3.4 release from their GitHub page.
Sign up at this page to gain access: https://developer.nvidia.com/physx-source-github
Sign up for game development and then you should have access via the GitHub account u link in ~20 min, was a while ago I did this so there might be a few extra steps, but straight forward.I have used the vc14win64 solution files to compile the physx libs, added the documented changed above to findphysx3 cmake file (both adding search paths to libs and include dir).
April 25, 2017 at 11:11 am #737466MarkusKeymasterI got the report from a co-worker that previous versions of physx works fine… up until 3.3.4 I think it was.
-
AuthorPosts
- You must be logged in to reply to this topic.