2.0 feedback welcome?

RandomCitizen · Post by **RandomCitizen** » Mon Apr 21, 2014 7:11 pm

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

JJJohan · Post by **JJJohan** » Tue Apr 22, 2014 4:12 am

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

.

Post by **Kojack** » Tue Apr 22, 2014 7:12 am

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 .

Do you mean the Jira site? It should be open to anyone that registers.

RandomCitizen · Post by **RandomCitizen** » Tue Apr 22, 2014 7:15 am

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

Post by **dark_sylinc** » Wed Apr 23, 2014 12:58 am

Hi!

Yes, we're totally accepting feedback!!!

Thanks for the locale thing, I would swear the SampleBrowser set the locale. It's definitely broken.

RandomCitizen wrote:I found out, there's already a ticket for my second issue: https://ogre3d.atlassian.net/browse/OGRE-371

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?

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 .

I'm certainly interested in hearing about that. Sounds like a huge leak somewhere.

maiakaat · Post by **maiakaat** » Thu May 08, 2014 3:33 pm

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

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()

FindTBB cmake also needs

Code: Select all

    if (MSVC_VERSION EQUAL 1800)
      set(COMPILER_PREFIX "vc12")
    endif ()

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

maiakaat · Post by **maiakaat** » Sun May 11, 2014 1:34 am

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)

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)

Post by **dark_sylinc** » Sun May 11, 2014 4:43 am

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?

maiakaat · Post by **maiakaat** » Mon May 12, 2014 4:47 pm

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).

maiakaat · Post by **maiakaat** » Fri May 23, 2014 3:51 pm

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

c6burns · Post by **c6burns** » Fri May 23, 2014 4:19 pm

maiakaat wrote:Maybe a C++ x11 branch or something

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.

WinRT refers to the arm specific version I believe, and not Windows store apps, or Windows 8 versions

WinRT is the windows runtime, and it supports arm and x86 natively. Windows RT is the armv7 OS. WinRT != Windows RT ... confusing, I know

Post by **Kojack** » Sun May 25, 2014 3:54 pm

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.

cybereality · Post by **cybereality** » Sun May 25, 2014 8:55 pm

Is DirectX11 going to work on 2.0?

Klaim · Post by **Klaim** » Sun May 25, 2014 11:07 pm

My understanding is that DirectX 9 will be dropped for OGRE 2.0, therefore DX10/11 will be the required minimal Direct X version.

maiakaat · Post by **maiakaat** » Mon May 26, 2014 12:16 pm

c6burns 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.

Hi

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

WinRT is the windows runtime, and it supports arm and x86 natively. Windows RT is the armv7 OS. WinRT != Windows RT ... confusing, I know

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 runtime

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 · Post by **c6burns** » Mon May 26, 2014 1:21 pm

maiakaat wrote:My gut feeling after returning to code from a long time away (a few years) is that there are huge advantages to migrating

Personally, I don't share that feeling

RandomCitizen · Post by **RandomCitizen** » Wed May 28, 2014 9:03 am

dark_sylinc wrote:
RandomCitizen wrote:I found out, there's already a ticket for my second issue: https://ogre3d.atlassian.net/browse/OGRE-371
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?

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.

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

RandomCitizen · Post by **RandomCitizen** » Mon Jun 09, 2014 9:54 pm

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):

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

Using the Ubuntu based version, everything just worked out of the box: Run Cmake compile and start the sample browser. Run one or two samples. No modifications necesary. Everything looked fine. No segmentation faults.

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.

Ogre Forums

2.0 feedback welcome?

2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?

Re: 2.0 feedback welcome?