2.0 feedback welcome?

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
RandomCitizen
Kobold
Posts: 26
Joined: Sat Jun 08, 2013 3:12 pm
x 2

2.0 feedback welcome?

Post by RandomCitizen »

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 :)
User avatar
JJJohan
Gnoblar
Posts: 14
Joined: Tue Nov 11, 2008 1:02 pm
Location: Brisbane, Australia
Contact:

Re: 2.0 feedback welcome?

Post by JJJohan »

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 :).
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: 2.0 feedback welcome?

Post by Kojack »

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
Kobold
Posts: 26
Joined: Sat Jun 08, 2013 3:12 pm
x 2

Re: 2.0 feedback welcome?

Post by RandomCitizen »

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
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: 2.0 feedback welcome?

Post by dark_sylinc »

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
Gnoblar
Posts: 11
Joined: Sat Mar 01, 2014 11:21 pm

Re: 2.0 feedback welcome?

Post by maiakaat »

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
Gnoblar
Posts: 11
Joined: Sat Mar 01, 2014 11:21 pm

Re: 2.0 feedback welcome?

Post by maiakaat »

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)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: 2.0 feedback welcome?

Post by dark_sylinc »

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
Gnoblar
Posts: 11
Joined: Sat Mar 01, 2014 11:21 pm

Re: 2.0 feedback welcome?

Post by maiakaat »

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
Gnoblar
Posts: 11
Joined: Sat Mar 01, 2014 11:21 pm

Re: 2.0 feedback welcome?

Post by maiakaat »

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
User avatar
c6burns
Beholder
Posts: 1512
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines
x 138

Re: 2.0 feedback welcome?

Post by c6burns »

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 :(
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: 2.0 feedback welcome?

Post by Kojack »

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.
User avatar
cybereality
Hobgoblin
Posts: 563
Joined: Wed Jul 12, 2006 5:40 pm
x 12

Re: 2.0 feedback welcome?

Post by cybereality »

Is DirectX11 going to work on 2.0?
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: 2.0 feedback welcome?

Post by Klaim »

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
Gnoblar
Posts: 11
Joined: Sat Mar 01, 2014 11:21 pm

Re: 2.0 feedback welcome?

Post by maiakaat »

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
User avatar
c6burns
Beholder
Posts: 1512
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines
x 138

Re: 2.0 feedback welcome?

Post by c6burns »

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 :D
RandomCitizen
Kobold
Posts: 26
Joined: Sat Jun 08, 2013 3:12 pm
x 2

Re: 2.0 feedback welcome?

Post by RandomCitizen »

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
Kobold
Posts: 26
Joined: Sat Jun 08, 2013 3:12 pm
x 2

Re: 2.0 feedback welcome?

Post by RandomCitizen »

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.
Post Reply