Feedback wanted: Ogre 2.1 guide

[hyyou]

....
That's my thoughts exactly! I am trying to create a simple custom HLMS implementation and I just can't break through. HlmsUnlit is already way too complex to be a starting point. ....

I think a full HLMS tutorial is too much work for a single person.
It would be nice if we can create a team from users to create this wiki.
IMHO, we need a captain - the one that professional enough (than me) to create a blank wiki page and the outline.

[petrotheos]

Support Windows UWP SwapChainPanel. In Ogre 1 there was a reference to the SwapChainPanel in the render function and the render had to be called from the UI thread. Maybe you can avoid refering to it by holding the necessary variables.

The HANDLE CreateThread work on WinRT too.

[kklouzal]

Thank you, this was exactly what I needed to get started! Trying to build 2.1 on my own, however straightforward now that I've done it a few times, is not as simple as other projects who use CMake.

The guide is easy to follow and explains everything properly and thoroughly. I like how you added very specific clarifications in areas such as

Make sure to build both Debug and Release

Instead of assuming the user should realize this themselves, you take the time to cover every angle. That will definitely help reduce areas of confusion for newcomers and eliminate unnecessary questions.

Moving forward I would like to see a tutorial initializing the core of OGRE itself without the use of third party libraries such as SDL and without the use of the demo framework (however references to specific code blocks within the framework should be perfectly acceptable). Essentially walk-through of each step in the process that would prime the user to begin creating their own framework.

[ven]

My ogre 2.1 setup experience (linux) - best feedback
I saw the current topic just now.

[Scalu]

Awesome! These guides were very helpful with my Linux installation. I am an Ogre newb. ;)

Feedback:
- Setting up Ogre on Linux:
- - Requirements:
- - - TortoiseHG 4.5.2 available on their website. With the latest Ubuntu 17.10, using their instructions for Launchpad PPA, it seemed that this version of Ubuntu will not accept their source as this specific version is unsupported. Just to get working, I ran "sudo apt-get install tortoisehg", which got me version 4.3, which worked fine. It was much easier.
After that experience, I did the same with qtcreator.
- - Downloading Ogre
- - - Command line: mkdir Ogre should be ogre, and is not a necessary step as the hgclone command creates the folder. I ended up with an empty Ogre folder, and the repository in the ogre folder, so I just deleted Ogre.
- - Building Dependencies:
- - - change Ogre -> ogre
- - - remove the second "cd build" command.
- - - change instal -> install
- - Building Ogre
- - - change Ogre -> ogre

- Using Ogre in your App: I followed the directions in Speeding things up.
- - Speeding things up:
- - - Creating your application with 'EmptyProject' script:
- - - - This section needs to be clarified with more specific steps. It took me couple of minutes to figure out how to clear the "RelWithDebInfo was not found" issue given the instructions there.
- - - - While compiling, "#include <SDL.h>" is failing to find that header file. I need to dive into CMake and see why SDL2/include is being dropped from the include paths for the compiler. If anyone knows why, let me know. Otherwise I'll post/edit when I figure it out.

Thanks again for all the hard work you put into this guide. It's really helped me out.

Edit: I found the problem with the SDL2 mismatch. In OGRE.cmake, we have:
OGRE.cmake:
if( NOT IOS )
set( CMAKE_PREFIX_PATH "${OGRE_SOURCE}/Dependencies ${CMAKE_PREFIX_PATH}" )
find_package( SDL2 )
if( NOT SDL2_FOUND )
message( "Could not find SDL2. https://www.libsdl.org/" )
else()
message( STATUS "Found SDL2" )
include_directories( ${SDL2_INCLUDE_DIR} )
set( OGRE_DEPENDENCY_LIBS ${OGRE_DEPENDENCY_LIBS} ${SDL2_LIBRARY} )
endif()
endif()

I ran cmake for the empty project with --trace-output, and found the following:
/home/rduplin/OgreLJE/CMake/Dependencies/OGRE.cmake(227): find_package(SDL2 )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(3): set(prefix /usr )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(4): set(exec_prefix ${prefix} )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(5): set(libdir ${prefix}/lib/x86_64-linux-gnu )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(6): set(SDL2_PREFIX /usr )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(7): set(SDL2_EXEC_PREFIX /usr )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(8): set(SDL2_INCLUDE_DIRS ${prefix}/include/SDL2 )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(9): set(SDL2_LIBRARIES -lSDL2 )
/usr/lib/x86_64-linux-gnu/cmake/SDL2/sdl2-config.cmake(10): string(STRIP ${SDL2_LIBRARIES} SDL2_LIBRARIES )
/home/rduplin/OgreLJE/CMake/Dependencies/OGRE.cmake(228): if(NOT SDL2_FOUND )
/home/rduplin/OgreLJE/CMake/Dependencies/OGRE.cmake(230): else()
/home/rduplin/OgreLJE/CMake/Dependencies/OGRE.cmake(231): message(STATUS Found SDL2 )
-- Found SDL2
/home/rduplin/OgreLJE/CMake/Dependencies/OGRE.cmake(232): include_directories(${SDL2_INCLUDE_DIR} )
/home/rduplin/OgreLJE/CMake/Dependencies/OGRE.cmake(233): set(OGRE_DEPENDENCY_LIBS ${OGRE_DEPENDENCY_LIBS} ${SDL2_LIBRARY} )

I edited OGRE.cmake and change SDL2_INCLUDE_DIR to SDL2_INCLUDE_DIRS, and also SDL2_LIBRARY to SDL2_LIBRARIES. After that, I was able to build and run the empty project just fine.

[hyyou]

Today, I want to re-read the guide again but ...
both tutorial links (github) in the OP are broken.

[Zonder]

Today, I want to re-read the guide again but ...
both tutorial links (github) in the OP are broken.

These I think, can't remember what was on the page now

how to setup Ogre

how to start your own project that uses Ogre.

[Ybalrid]

Mh, it looks like somewhere along the way something in the Doxygen configuration changed.

The Doxgen for 2.1 has been rebuilt recently. And it seems theses file names where changed from CamelCase to _snake_case...

[Zonder]

Mh, it looks like somewhere along the way something in the Doxygen configuration changed.

The Doxgen for 2.1 has been rebuilt recently. And it seems theses file names where changed from CamelCase to _snake_case...

Yeah looks like it

[Ybalrid]

It's probably my fault then Sorry!

I built and pull requested the documentation by doing a make `OgreDocs` like you are suppsed to do. It was more than one year old and did not have changes mades to the Hlms, and ResourceManager and probably many other APIs documented. I got frustrated, so I sent the up to date site as a PR to the gh-pages branch

Now dark_sylinc has to update his post to put the good links... ^^"

[dark_sylinc]

It appears to be a problem with newer versions of doxygen. Mine is now generating _snake_case too.

This is extremely annoying. I can modify the original post, but I'm pretty sure I wrote lots of posts and emails with this link that are now broken.

Does anyone know how to force doxygen to the old behavior?

Edit: Found a fix!!! If I set CASE_SENSE_NAMES = YES, we get the old behavior (at least when built from Linux). The old doxygen probably had a bug where it was probably ignoring this setting.
Edit 2: False alarm It looks like the bug was that Markdown files were not affected by the setting, but everything else was. If I change the toggle, it also changes a lot of other files as well.

[Ybalrid]

It appears to be a problem with newer versions of doxygen. Mine is now generating _snake_case too.

This is extremely annoying. I can modify the original post, but I'm pretty sure I wrote lots of posts and emails with this link that are now broken.

Does anyone know how to force doxygen to the old behavior?

Edit: Found a fix!!! If I set CASE_SENSE_NAMES = YES, we get the old behavior (at least when built from Linux). The old doxygen probably had a bug where it was probably ignoring this setting.
Edit 2: False alarm It looks like the bug was that Markdown files were not affected by the setting, but everything else was. If I change the toggle, it also changes a lot of other files as well.

There's still the solution to create a symlink. Then GitHub Pages should display the file instead of 404ing

Edit: Well, I'm going to create a PR for that, hold on...
Edit 2: This is for Pavel or Matias, whoever can merge this : https://github.com/OGRECave/ogre/pull/824

[Ybalrid]

Sorry for the double post, but it looks like Pavel ins't going to accept that ^^"

https://github.com/OGRECave/ogre/pull/8 ... -407337507

[radgeRayden]

I'm following the windows guide and while not a deal breaker, it has a few mistakes that are easy to correct but could confuse a novice. How/where can I propose a patch? I'd be glad to do the necessary fixes right away (mostly fixing paths / screenshots).

[Ybalrid]

I'm following the windows guide and while not a deal breaker, it has a few mistakes that are easy to correct but could confuse a novice. How/where can I propose a patch? I'd be glad to do the necessary fixes right away (mostly fixing paths / screenshots).

Theses pages on the documentation are generated from Markdown files in the <source_code_repo>/Docs/src/SettingUpOgre. (e.g: https://bitbucket.org/sinbad/ogre/src/8 ... ew-default)

What you would want to do is:

• Create a fork of the project on the BitBucket website.
• Clone that fork on your disk as you would do from the "sinbad" owned repo.
• Edit the files with your changes.
• Build the docs with Doxygen to check your work.
• Once you're happy with the change, you can commit your changes with a commit text that explain what changed "Fixed documentation about XYZ" and push them to your cloned repository.
• Then, from the bitbucket interface, create a Pull Request, and make sure the diff is against the `v2-1` branch.
• You can probably directly "assign" Matías for review directly since he's the main maintainer for Ogre 2.1 ( )

And that's it, you proposed changes to the repo!

[Owl53]

Hi,

I'm currently building Ogre 2.1 for the first time today, and when cloning the ogre dependencies by following the guide's instructions, I got the same error as described by someone below. Upon having a look at the repo I was trying to clone, I realised that the additional 'Dependencies' needed to be removed, and once that was done the repo was cloned successfully. I'm just bringing it up because I wonder if it's worth changing it in the guide so that no one else has that confusion when following the instructions?

In Downloading Ogre (https://ogrecave.github.io/ogre/api/2.1 ... ndows.html), I believe the code (and the related image) is wrong :-

Code: Select all

hg clone https://bitbucket.org/cabalistic/ogredeps Dependencies
                                                    ^ "Dependencies" should be removed        

If I follow the tutorial precisely, I will get an error at tortoiseHg "repository not found".

Thanks

[Owl53]

Edit: never mind, I've realised my mistake.

[hyyou]

I wonder if it's worth changing it in the guide.

IMHO, there are a lot of TODO for dark_sylinc, so he simply doesn't have time for this.
I notice a file in "_setting_up_ogre_windows.md.i" in the repository.
Perhaps, some users may be able to modify it. I failed to open it properly - it is a binary file.

Today, I install Ogre once in a long time from https://www.ogre3d.org/download/sdk .
It took me some time to find this page again.
It would be nice if the download page has a link to the official install instruction (https://ogrecave.github.io/ogre/api/2.1 ... ndows.html).

[mostevil]

I'm working from the 2.3 for VS2019 x64 it's pretty good once I found it...
Before that I found and got confused by this on the wiki. That could do to point at the new document.

The automatic download scripts were great. But the build failed for shaderc. I downloaded again and spotted an error for it saying python was missing. Installing it fixed it.
I think python 3 needs adding to the requirements section?
Before that I also downloaded the Vulkan SDK as a quick google hints shaderc is for android Vulkan.

Images are for CMake2 and CMake 3 looks and behaves a little different, but not enough to cause probelms.
Configure didn't ask for a generator, it was already set from the download script. After pressing configure it complains quite a lot about:
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
For most of the folders, looks scary, but all seems to work.

The paths referenced in the guide are "OgreDepsRepo" and "OgreSDK", in the auto download it's "ogre-next" and "ogre-next-deps" (much nicer IMO).
The bit about changing the OGRE_DEPENDENCIES_DIR in Building Ogre (4) wasn't needed, it all nicely defaulted to the ogre-next-deps. So all worked well but didn't quite match the directions.

EmptyProject, so far I can only get the Release build to work.
I'm getting The code execution cannot proceed because OgreAtmosphere_d.dll was not found when trying to run the debug build.
I think it's just because it's the first of the Ogre dlls it's looking for as the file is there in the bin\debug folder. So presumably something isn't pointing at the bin\debug folder. Any tips as to where to look/what I might have done wrong?

Basically an Ogre newbie, I had an old version working for a skeleton of a project years and years ago but life got in the way.
I've not worked with C++ in a long while and don't know my way around CMake.

[dark_sylinc]

I'm working from the 2.3 for VS2019 x64 it's pretty good once I found it...
Before that I found and got confused by this on the wiki. That could do to point at the new document.

Ooff! That's old! I updated it to point to the manual. Thanks!

I downloaded again and spotted an error for it saying python was missing. Installing it fixed it.
I think python 3 needs adding to the requirements section?
Before that I also downloaded the Vulkan SDK as a quick google hints shaderc is for android Vulkan.

Ahh sorry about that! It's been reported. I don't know how to "automatically" fix that (i.e. avoid it when not needed) but I just added the dependency requirement on the manual's list. It will take a couple minutes for the manual to be updated.

EmptyProject, so far I can only get the Release build to work.
I'm getting The code execution cannot proceed because OgreAtmosphere_d.dll was not found when trying to run the debug build.
I think it's just because it's the first of the Ogre dlls it's looking for as the file is there in the bin\debug folder. So presumably something isn't pointing at the bin\debug folder. Any tips as to where to look/what I might have done wrong?

That seems to be a bug. I filed a ticket.
As a workaround you can search the DLL in OgreNext's build folder and copy it by hand.

Remember that as the manual points out you may need to configure the working directory:

If necessary, configure the working directory to be EmptyProject/bin/Release (on Visual Studio, Alt+F7 -> Debugging -> Working Directory)

(Or Debug folder if you're in debug configuration)

Thanks for the feedback!

[mostevil]

Remember that as the manual points out you may need to configure the working directory:

Thanks for the feedback!

I don't think it's related to that, they're both set and if I take it out for release I don't get an error, it just doesn't find the renderers.

Copying the OgreAtmosphere_d.dll into the working folder fixes it but I don't understand why release build doesn't need the same.
I moved OgreAtmosphere.dll from .\Dependencies\Ogre\build\bin\release and .\Dependencies\Ogre\build\sdk\bin\release and Release still worked, so unless it's in the path somewhere I'm not sure it's even using it. Procexp64 didn't list it for me.

Oh there's a /latest/! I noticed the .md was slightly different on git to the one I'd seen.
All of api/latest is showing as grey on black on my firefox but not in chrome, firefox settings appearence->dark / automatic doesn't like it. 2.3 doesn't.

api/2.3/ was the one I found, perhaps a link to /latest/ docs in the banner for the older api versions? Biggest problem seems to be finding the correct and current document. There doesn't seem an obvious way to move between versions in the api docs.

Thanks for everything!

[dark_sylinc]

I don't think it's related to that, they're both set and if I take it out for release I don't get an error, it just doesn't find the renderers.

Copying the OgreAtmosphere_d.dll into the working folder fixes it but I don't understand why release build doesn't need the same.
I moved OgreAtmosphere.dll from .\Dependencies\Ogre\build\bin\release and .\Dependencies\Ogre\build\sdk\bin\release and Release still worked, so unless it's in the path somewhere I'm not sure it's even using it. Procexp64 didn't list it for me.

Release will remove anything it finds is not used.
Debug will keep it.

That is most likely what is happening (either that, or the Release version is being built without the Atmosphere component for some bizarre reason, but I doubt it).

Oh there's a /latest/! I noticed the .md was slightly different on git to the one I'd seen.
All of api/latest is showing as grey on black on my firefox but not in chrome, firefox settings appearence->dark / automatic doesn't like it. 2.3 doesn't.

Can you reword that or post some pics? I'm afraid I don't understand

[mostevil]

Release will remove anything it finds is not used.
Debug will keep it.

Makes sense!

Can you reword that or post some pics? I'm afraid I don't understand

For the documentation, firefox browser dark or auto setting gave light text on dark background the default.
api/latest overrides the foreground colour to dark grey on the header and main page but it takes the browsers background colour.
It's really hard to read if set to dark/automatic.
api/2.3 overrides background so it shows normally as black text on white.

probably from these css changes.
I've looked at it to try to work out why but I'm really terrible at css/html. I hide from anything web front end in the day job.
Maybe those background-color: transparent; additions.
There's also a background-color: auto; which isn't a thing according to W3C CSS

[Crystal Hammer]

Yeah, I also have those color issues in documentation, I just forgot since I use my custom theme everywhere.
I say the rule is: if you set text color, then you have to set background color too (not transparent). If you set background color then you have to set text color too. In other words either both or none. Because if only one is set and other gets from system you'll get those issues for people who use dark themes. And I've seen such issues plenty of times. Seems developers don't check their stuff on dark themes.

[dark_sylinc]

The bug where EmptyProject does not copy Atmosphere DLL has been fixed. Thanks for the report!

I still need to look into the Firefox dark theme issue, but at least I can repro it. Thanks for the info!