2.0 feedback welcome?
-
- Kobold
- Posts: 26
- Joined: Sat Jun 08, 2013 3:12 pm
- x 2
2.0 feedback welcome?
Hey Guys,
today, I've discovered the Ogre 2.0 release discussion thread. So I wanted to ask whether you are already in a stage, where feedback is welcome.
I can understand, that 2.0 is currently heavy developed and any "Oh no, the deferred sample is not compilable" reports wouldn't be really helpful. I am thinking of feedback like "Using Linux Mint Debian 64 Bit and g++4.8, the default localizations 'en_GB.UTF-8' and 'en_GB.UTF8' caused exception with the message ..., my current workaround was to use the localization 'C'" or "The OpenGLRenderSystem emits a SIGSEGV when exiting with the line .... Reprocase: ..."
greetings, Robert
today, I've discovered the Ogre 2.0 release discussion thread. So I wanted to ask whether you are already in a stage, where feedback is welcome.
I can understand, that 2.0 is currently heavy developed and any "Oh no, the deferred sample is not compilable" reports wouldn't be really helpful. I am thinking of feedback like "Using Linux Mint Debian 64 Bit and g++4.8, the default localizations 'en_GB.UTF-8' and 'en_GB.UTF8' caused exception with the message ..., my current workaround was to use the localization 'C'" or "The OpenGLRenderSystem emits a SIGSEGV when exiting with the line .... Reprocase: ..."
greetings, Robert
- JJJohan
- Gnoblar
- Posts: 14
- Joined: Tue Nov 11, 2008 1:02 pm
- Location: Brisbane, Australia
- Contact:
Re: 2.0 feedback welcome?
I was looking on the bitbucket page earlier to see if I could post an issue (StaticGeometry is eating up in excess of 16GB+ which was previously using 200MB on 1.9) but it seems it's only open to developers at the moment. Not as lucky as you to have a workaround for it Robert .
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: 2.0 feedback welcome?
Do you mean the Jira site? It should be open to anyone that registers.JJJohan wrote:I was looking on the bitbucket page earlier to see if I could post an issue (StaticGeometry is eating up in excess of 16GB+ which was previously using 200MB on 1.9) but it seems it's only open to developers at the moment. Not as lucky as you to have a workaround for it Robert .
-
- Kobold
- Posts: 26
- Joined: Sat Jun 08, 2013 3:12 pm
- x 2
Re: 2.0 feedback welcome?
While browsing through the tickets there, I found out, there's already a ticket for my second issue: https://ogre3d.atlassian.net/browse/OGRE-371
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1280
- Contact:
Re: 2.0 feedback welcome?
Hi!
Yes, we're totally accepting feedback!!!
Thanks for the locale thing, I would swear the SampleBrowser set the locale. It's definitely broken.
Yes, we're totally accepting feedback!!!
Thanks for the locale thing, I would swear the SampleBrowser set the locale. It's definitely broken.
I forgot to close that ticket as it is fixed by now. It should've been fixed in b674c3582964. Are you using an earlier version?RandomCitizen wrote:I found out, there's already a ticket for my second issue: https://ogre3d.atlassian.net/browse/OGRE-371
I'm certainly interested in hearing about that. Sounds like a huge leak somewhere.JJJohan wrote:I was looking on the bitbucket page earlier to see if I could post an issue (StaticGeometry is eating up in excess of 16GB+ which was previously using 200MB on 1.9) but it seems it's only open to developers at the moment. Not as lucky as you to have a workaround for it Robert .
-
- Gnoblar
- Posts: 11
- Joined: Sat Mar 01, 2014 11:21 pm
Re: 2.0 feedback welcome?
Hi
Getting to grips with Ogre 2.0
A Note
Windows SDK 8.0 and 8.1 for directx, are not found due to the massive change in structure
I've made a mod to CMAKE, but I haven never done this before, I've posted it below, for Visual Studio 2013 on Windows 7 with the Windows 8, or 8.1 SDK
This is effectively the change
FindTBB cmake also needs
Maybe this has been changed already in the latest source
Also the changes require significant changes to support the DX9 renderer, there are pages that discuss the changes, but the DX9 renderer isn't important for me, these issues are largely caused by the changes to D3DX, the withdrawal of D3DErr, and possibly the move of parts to DirectXTK and DirectXTex. DirectXMath has also replaced the older Math library, I guess ideally the new locations and dependencies would be used if the Windows SDK 8.0 or 8.1 is found
Getting to grips with Ogre 2.0
A Note
Windows SDK 8.0 and 8.1 for directx, are not found due to the massive change in structure
I've made a mod to CMAKE, but I haven never done this before, I've posted it below, for Visual Studio 2013 on Windows 7 with the Windows 8, or 8.1 SDK
This is effectively the change
Code: Select all
# construct search paths
set(DirectX9_PREFIX_PATH
"${DXSDK_DIR}" "${ENV_DXSDK_DIR}"
"${DIRECTX_HOME}" "${ENV_DIRECTX_HOME}"
"${DIRECTX_ROOT}" "${ENV_DIRECTX_ROOT}"
"${DIRECTX_BASE}" "${ENV_DIRECTX_BASE}"
"C:/apps_x86/Microsoft DirectX SDK*"
"C:/Program Files (x86)/Microsoft DirectX SDK*"
"C:/apps/Microsoft DirectX SDK*"
"C:/Program Files/Microsoft DirectX SDK*"
"C:/Program Files (x86)/Windows Kits/8.0*"
"C:/Program Files (x86)/WIndows Kits/8.1*"
"$ENV{ProgramFiles}/Microsoft DirectX SDK*"
)
#if(OGRE_BUILD_PLATFORM_WINRT)
# Windows 8 SDK has custom layout
set(DirectX9_INC_SEARCH_PATH
"C:/Program Files (x86)/Windows Kits/8.0/Include/shared"
"C:/Program Files (x86)/Windows Kits/8.0/Include/um"
"C:/Program Files (x86)/Windows Kits/8.1/Include/shared"
"C:/Program Files (x86)/Windows Kits/8.1/Include/um"
)
set(DirectX9_LIB_SEARCH_PATH
"C:/Program Files (x86)/Windows Kits/8.0/Lib/win8/um"
"C:/Program Files (x86)/Windows Kits/8.1/Lib/winv6.3/um"
)
#endif()
Code: Select all
if (MSVC_VERSION EQUAL 1800)
set(COMPILER_PREFIX "vc12")
endif ()
Also the changes require significant changes to support the DX9 renderer, there are pages that discuss the changes, but the DX9 renderer isn't important for me, these issues are largely caused by the changes to D3DX, the withdrawal of D3DErr, and possibly the move of parts to DirectXTK and DirectXTex. DirectXMath has also replaced the older Math library, I guess ideally the new locations and dependencies would be used if the Windows SDK 8.0 or 8.1 is found
-
- Gnoblar
- Posts: 11
- Joined: Sat Mar 01, 2014 11:21 pm
Re: 2.0 feedback welcome?
Hi
The D3D11 Renderer using Windows SDK 8.1 seems to have problems with the shader code, prior builds using the 2010 DXSDK didn't have the problem.
I'm very new to Ogre so I don't know if this is a known problem or individual error during cmake, the problem was loading the sample browser after choosing the D3D11 SDK
The machine is Windows 7 x64, the Included SDK is compatible with Windows 7 x64 despite being named the 8.1 SDK (to DX 11.1 I think)
The D3D11 Renderer using Windows SDK 8.1 seems to have problems with the shader code, prior builds using the 2010 DXSDK didn't have the problem.
I'm very new to Ogre so I don't know if this is a known problem or individual error during cmake, the problem was loading the sample browser after choosing the D3D11 SDK
The machine is Windows 7 x64, the Included SDK is compatible with Windows 7 x64 despite being named the 8.1 SDK (to DX 11.1 I think)
Code: Select all
01:09:13: OGRE EXCEPTION(3:RenderingAPIException): Cannot assemble D3D11 high-level shader 74a775b1-0c54-1439-206f-5154f228eaee_FS Errors:
***PATH***\bin\debug\Shader@0x000000000AA4D5E0(64,2-73): error X3017: 'FFP_Construct_Sampler_Wrapper': cannot implicitly convert from 'const sampler2D' to 'TextureCube<float4>'
in D3D11HLSLProgram::loadFromSource at ***PATH***\sinbad-ogre-ce54f4c7fbfa\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp (line 502)
01:09:13: High-level program 74a775b1-0c54-1439-206f-5154f228eaee_FS encountered an error during loading and is thus not supported.
OGRE EXCEPTION(3:RenderingAPIException): Cannot assemble D3D11 high-level shader 74a775b1-0c54-1439-206f-5154f228eaee_FS Errors:
***PATH***\bin\debug\Shader@0x000000000AA4D5E0(64,2-73): error X3017: 'FFP_Construct_Sampler_Wrapper': cannot implicitly convert from 'const sampler2D' to 'TextureCube<float4>'
in D3D11HLSLProgram::loadFromSource at ***PATH***\sinbad-ogre-ce54f4c7fbfa\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp (line 502)
01:09:13: OGRE EXCEPTION(2:InvalidParametersException): Could not create gpu programs from render state in ProgramManager::acquireGpuPrograms at ***PATH***\sinbad-ogre-ce54f4c7fbfa\Components\RTShaderSystem\src\OgreShaderProgramManager.cpp (line 109)
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1280
- Contact:
Re: 2.0 feedback welcome?
Hi,
Using DX June2010 SDK I am unable to repro your bug.
I haven't tried the Win 8.1 SDK. I believe you've got to use the DX June2010 though. If you've got both of them installed, may be CMake is picking the wrong one.
This bug you're seeing is specific to RTSS (which I do not maintain), so Assaf or Lior will probably be able to help you. Does it reproduce on default branch?
Using DX June2010 SDK I am unable to repro your bug.
I haven't tried the Win 8.1 SDK. I believe you've got to use the DX June2010 though. If you've got both of them installed, may be CMake is picking the wrong one.
This bug you're seeing is specific to RTSS (which I do not maintain), so Assaf or Lior will probably be able to help you. Does it reproduce on default branch?
-
- Gnoblar
- Posts: 11
- Joined: Sat Mar 01, 2014 11:21 pm
Re: 2.0 feedback welcome?
DirectX is now included in the Windows 8.1 SDK, with the files located at the locations
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm
C:\Program Files (x86)\Windows Kits\8.1\Include\um
A number of changes have been made, the most significant being the removal of DxErr.lib, and the dispersal of D3DX, however these were not required by cmake, though I'm not sure this is a problem here (but then I am very very out of practice - 6 years, and just getting to grips with Ogre3D).
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\arm
C:\Program Files (x86)\Windows Kits\8.1\Include\um
A number of changes have been made, the most significant being the removal of DxErr.lib, and the dispersal of D3DX, however these were not required by cmake, though I'm not sure this is a problem here (but then I am very very out of practice - 6 years, and just getting to grips with Ogre3D).
-
- Gnoblar
- Posts: 11
- Joined: Sat Mar 01, 2014 11:21 pm
Re: 2.0 feedback welcome?
Some ideas and notes
(cmake)
1. The SSE2 switch does nothing on visual studio 2010,2012 and 2013 on x64 targets, intrinsics are the documented replacement
http://msdn.microsoft.com/en-us/library/hh977022.aspx
2. On Visual Studio There is a compiler switch that applies automatically vectorization which could be used as a replacement, my idea is to add two build configurations, one for debug, and one for release, as this switch is really intended for performance comparison for tuning of the use of vector calling conventions which are recommended and used in vs2013.
Finding the matching options in GCC and offering up a cmake option for this change on supported compiler targets, would be the first step to bring other aspects of Ogre right up to date without breaking other compilers regarding vectorization
http://blogs.msdn.com/b/vcblog/archive/ ... ntion.aspx
3. Offer a cmake variable which, when used with a suitable compiler sets the ball rolling for c++ x11 code, which is used directly in place of older code where there are significant performance/reliability gains, exactly the best way to do this to support all compilers I am not sure. I think C++ x11 is supposed to offer higher performance through the VS2013 compiler on windows x64, and many of its changes address significant performance or reliability issues, and this may apply to some other compilers and platforms.
Maybe a C++ x11 branch or something
4. the use of WinRT within cmake and the Windows 8 SDK is technically incorrect and confusing. The Windows 8 SDK is the same as all other windows SDKs (7.0..etc) WinRT refers to the arm specific version I believe, and not Windows store apps, or Windows 8 versions, and the definitions in the CMake search files should be cleared up, WinRT could be adapted to specifically link to the "arm" instruction set within the Windows SDK
5. Building Ogre 2.0 Directx11 against a 2010 SDK is probably something that shouldn't be the norm, CMake needs modifications to handle the relocation of DirectX files into the Windows 8 SDK so it can find them without problems, there may as listed be a small issue with DirectX in the sample browser, if this is the case my best guess is passing the wrong parameter in to a function or calling the wrong overload of the function, but I am not yet experienced enough to debug the shader system as it's quite advanced and impressive
I know some of these are looking forward, but for the next version of Ogre I though planning and acting now could drastically improve Ogre's competitiveness against commercial technology that I guess will be getting performance specific benefits in ASAP
(cmake)
1. The SSE2 switch does nothing on visual studio 2010,2012 and 2013 on x64 targets, intrinsics are the documented replacement
http://msdn.microsoft.com/en-us/library/hh977022.aspx
2. On Visual Studio There is a compiler switch that applies automatically vectorization which could be used as a replacement, my idea is to add two build configurations, one for debug, and one for release, as this switch is really intended for performance comparison for tuning of the use of vector calling conventions which are recommended and used in vs2013.
Finding the matching options in GCC and offering up a cmake option for this change on supported compiler targets, would be the first step to bring other aspects of Ogre right up to date without breaking other compilers regarding vectorization
http://blogs.msdn.com/b/vcblog/archive/ ... ntion.aspx
3. Offer a cmake variable which, when used with a suitable compiler sets the ball rolling for c++ x11 code, which is used directly in place of older code where there are significant performance/reliability gains, exactly the best way to do this to support all compilers I am not sure. I think C++ x11 is supposed to offer higher performance through the VS2013 compiler on windows x64, and many of its changes address significant performance or reliability issues, and this may apply to some other compilers and platforms.
Maybe a C++ x11 branch or something
4. the use of WinRT within cmake and the Windows 8 SDK is technically incorrect and confusing. The Windows 8 SDK is the same as all other windows SDKs (7.0..etc) WinRT refers to the arm specific version I believe, and not Windows store apps, or Windows 8 versions, and the definitions in the CMake search files should be cleared up, WinRT could be adapted to specifically link to the "arm" instruction set within the Windows SDK
5. Building Ogre 2.0 Directx11 against a 2010 SDK is probably something that shouldn't be the norm, CMake needs modifications to handle the relocation of DirectX files into the Windows 8 SDK so it can find them without problems, there may as listed be a small issue with DirectX in the sample browser, if this is the case my best guess is passing the wrong parameter in to a function or calling the wrong overload of the function, but I am not yet experienced enough to debug the shader system as it's quite advanced and impressive
I know some of these are looking forward, but for the next version of Ogre I though planning and acting now could drastically improve Ogre's competitiveness against commercial technology that I guess will be getting performance specific benefits in ASAP
- c6burns
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 138
Re: 2.0 feedback welcome?
I'm no team member, but imho c++11 should be an all or nothing endeavour, only undertaken at a point where the team is comfortable forcing that requirement on their users across all the platforms.maiakaat wrote:Maybe a C++ x11 branch or something
WinRT is the windows runtime, and it supports arm and x86 natively. Windows RT is the armv7 OS. WinRT != Windows RT ... confusing, I knowWinRT refers to the arm specific version I believe, and not Windows store apps, or Windows 8 versions
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: 2.0 feedback welcome?
I just started using 2.0 and VS2013 in my own framework. A couple of minor things threw me at first (probably because I haven't read up on what I should be doing):
- Cameras now must have a scene node. createCamera() adds the camera to the root scene node automatically.
- Lights now must have a scene node. createLight() doesn't add the light to a scene node and doing things like setDirection to a light crash without the light already being in a node.
- Cameras attached to root node are fine, they maintain their own transform info. Directional (and probably spot) lights attached to the root node will rotate the entire world (including skybox).
While discovering that I noticed that directional lights use unit z as their facing direction. The ogre standard for facing directions (scene nodes, cameras, etc) has been negative unit z.
Ogre::InstancingTheadedCullingMethod is missing an r.
Otherwise, got it running. Nothing more than a ninja floating in the sky, but it's a start.
- Cameras now must have a scene node. createCamera() adds the camera to the root scene node automatically.
- Lights now must have a scene node. createLight() doesn't add the light to a scene node and doing things like setDirection to a light crash without the light already being in a node.
- Cameras attached to root node are fine, they maintain their own transform info. Directional (and probably spot) lights attached to the root node will rotate the entire world (including skybox).
While discovering that I noticed that directional lights use unit z as their facing direction. The ogre standard for facing directions (scene nodes, cameras, etc) has been negative unit z.
Ogre::InstancingTheadedCullingMethod is missing an r.
Otherwise, got it running. Nothing more than a ninja floating in the sky, but it's a start.
- cybereality
- Hobgoblin
- Posts: 563
- Joined: Wed Jul 12, 2006 5:40 pm
- x 12
- Klaim
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
- Contact:
Re: 2.0 feedback welcome?
My understanding is that DirectX 9 will be dropped for OGRE 2.0, therefore DX10/11 will be the required minimal Direct X version.
-
- Gnoblar
- Posts: 11
- Joined: Sat Mar 01, 2014 11:21 pm
Re: 2.0 feedback welcome?
Hic6burns wrote: I'm no team member, but imho c++11 should be an all or nothing endeavour, only undertaken at a point where the team is comfortable forcing that requirement on their users across all the platforms.
My thoughts are that it could be an option in Cmake to use the newer code where it is provided as an advanced feature to get Ogre looking ahead, code would be written in standard C++ but chunks could be chosen by contributors and used in place if selected during the CMake process. That way, Ogre might not be playing catchup if the big commercial names roll out support with some significant performance advantages
My gut feeling after returning to code from a long time away (a few years) is that there are huge advantages to migrating, and Ogre is large enough that either code starts to get written now (well, in a few years, in the places where it will really make a difference) and only actually used in place where it exists by those who explicitly choose it in Cmake, with a full migration much more achievable at some point in the future, or if C++ 11 takes off at some point in the future Ogre could be facing a much steeper hurdle
MY issue is that CMake's terminology is excluding search paths on a windows 7 x64 machine for DirectX within the Windows Kits\8.x folders, using a _WINRT flag as part of the check, when we both sort-of agree then that if WinRT just means the windows runtime, it shouldn't be excluding some paths on a Windows 7 x64 machine with the Windows 8.x SDK installed, if that parameter is supposed to just mean the windows runtimeWinRT is the windows runtime, and it supports arm and x86 natively. Windows RT is the armv7 OS. WinRT != Windows RT ... confusing, I know
PS the exact variable if block commented out and modified is in an earlier post
The paths also have three subfolders for architecture which the current find scripts cannot seem to handle, it's something small that seems to be problematic if you want to use the latest DirectX. It'll be a while before I have any competence in CMake or Ogre I'm just surprised that Ogre is sitting with a 4 year old copy of DirectX SDK as the only directly compatible DirectX SDK, and the Windows 8.0 paths added are for some reason possibly fixed to using them for some other target platform or host than Windows 7 x64, it's why I assumed that it was being used explicitly for builds targeting WinRT or Windows 8
- c6burns
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 138
Re: 2.0 feedback welcome?
Personally, I don't share that feelingmaiakaat wrote:My gut feeling after returning to code from a long time away (a few years) is that there are huge advantages to migrating
-
- Kobold
- Posts: 26
- Joined: Sat Jun 08, 2013 3:12 pm
- x 2
Re: 2.0 feedback welcome?
Sorry for my late response. I am now a little confused now. I think, this is a seperate bug, as it only happens on my new PC, not on my old one. The old PC, where it doesn't happen is using Linux Mint 15 (ubuntu based). The new PC, where it's happening is using Linux Mint Debian Edition using the nvidia driver version 319.72-1.dark_sylinc wrote:I forgot to close that ticket as it is fixed by now. It should've been fixed in b674c3582964. Are you using an earlier version?RandomCitizen wrote:I found out, there's already a ticket for my second issue: https://ogre3d.atlassian.net/browse/OGRE-371
When Linux Mint 17 comes out, I will recheck whether this is reproducable on my new PC before and after installing the ubuntu based Linux Mint version.
greetings, Robert
-
- Kobold
- Posts: 26
- Joined: Sat Jun 08, 2013 3:12 pm
- x 2
Re: 2.0 feedback welcome?
Now I have built Ogre 2.0 (exactly the same version) once using Linux Mint Debian Edition and once using Linux Mint 17 (based on Ubuntu 14.4)
First I've tried using the Ogre 2.0 version on the Linux Mint Debian Edition (using the commit 215d21fe):
It looks like you guys would have to add a debian machine to the test machines if you want to support Linux Debian. For me this (and the fact, the on Linux Mint Debian Spottify wan't running^^) were the reasons I've kicked out Linux Mint Debian from my computer and installed a Ubuntu based Linx Mint system.
Edit: As The SteamMachine will be based on debian, supporting debian might be important.
First I've tried using the Ogre 2.0 version on the Linux Mint Debian Edition (using the commit 215d21fe):
- I had to comment out the `add_subdirectory(VolumeTex)` line from the samples CMake file to get it compilable
- To prevent the application from crashing, I had to replace `std::locale StringConverter::msLocale = std::locale(msDefaultStringLocale.c_str());` with `std::locale StringConverter::msLocale = std::locale("C");` in OgreStringConverter.cpp
- The samples itselves hadn't loaded their textures. All textures were replaced by yellow/black dummytexture stripes
- When exiting the sample application, a segmentatin fault occured
It looks like you guys would have to add a debian machine to the test machines if you want to support Linux Debian. For me this (and the fact, the on Linux Mint Debian Spottify wan't running^^) were the reasons I've kicked out Linux Mint Debian from my computer and installed a Ubuntu based Linx Mint system.
Edit: As The SteamMachine will be based on debian, supporting debian might be important.