(not) building OpenMW + OSG on Windows.

Support for running, installing or compiling OpenMW

Before you submit a bug report for the first time, please read: Bug reporting guidelines
Locked
dteviot
Posts: 144
Joined: 17 Dec 2014, 20:29

(not) building OpenMW + OSG on Windows.

Post by dteviot »

Steps
  • Download OSG 3.2.1 source from http://trac.openscenegraph.org/download ... -3.2.1.zip
  • Donwload OSG dependencies from http://download.osgvisual.org/3rdParty_ ... V9_full.7z
  • Unzip OpenSceneGraph-3.2.1.zip. Copy the unzipped files to OpenSceneGraph-3.2.1/OpenScenegraph. i.e. CMakeLists.txt is in OpenSceneGraph-3.2.1/OpenScenegraph.
  • Unzip 3rdParty_VS2013_v120_x86_x64_V9_full.7z. Copy the contents of the x86 folder (I'm doing 32 bit builds) to OpenSceneGraph-3.2.1/OpenScenegraph/3rdParty
  • Throw away the boost files from OpenSceneGraph-3.2.1/OpenScenegraph/3rdParty (it's 1.55, and I've got 1.57 installed.)
  • Run cmake against OpenSceneGraph-3.2.1/OpenScenegraph, with settings suggested by scrawl.
  • Get the following errors/warnings which I ignore. (I'm concerned about the QT warnings, osgQT is not created as a project to build.)
    Spoiler: Show
  • Build the OSG project in MSVC. Some minor warnings, nothing to worry about.
  • Now run CMAKE against OpenMW. Get the following errors. (I suspect I need to configure an environmental variable to say where OSG is, but I'm not sure.)
    Spoiler: Show
Top
User avatar
Ace (SWE)
Posts: 887
Joined: 15 Aug 2011, 14:56

Re: (not) building OpenMW + OSG on Windows.

Post by Ace (SWE) »

I'd recommend setting CMAKE_INSTALL_PATH for your OpenSceneGraph build and then building the INSTALL project, that will give you an OSG SDK folder that you can specify through the OSG_SDK CMake variable.

For OSG Qt, you might have to patch the Qt paths. As when you build Qt, the install paths for it are hardcoded into qmake. I know that my own Qt binaries came with a binary patcher for that.
Top
dteviot
Posts: 144
Joined: 17 Dec 2014, 20:29

Re: (not) building OpenMW + OSG on Windows.

Post by dteviot »

@Ace, thanks for the help.
Rebuilding QT and adding the QT to the PATH environmental variable fixed the issue with building osgQT.
And I manually added the QT libraries to the OpenMW cmake variables.
(Did you perhaps mean "CMAKE_INSTALL_PREFIX", not "CMAKE_INSTALL_PATH")
It now builds.

And it starts to run on Windows.
However, it crashes when:
  • I click on the "Load Game" option at the start.
  • Immediately when I exit the ship when I start a new game.
Error is:
MyGUI EXCEPTION: texture pointer is not valie, texture name ''
in MyGUI at \MyGUIEngine\scr\MyGUI_RenderItem.cpp (line 83)
Some points to note:
  • "Options" from the start menu works.
  • The dialog to give your name at the start works.
  • I did rebuild MyGUI using Scrawl's changed cmake settings, and dropped the new DLL into the debug directory.
  • The various splash sceens you get at the start do appear.
Stack trace is:
Spoiler: Show
Top
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: (not) building OpenMW + OSG on Windows.

Post by scrawl »

Looks like you are the first to test MyGUI in debug mode. Try this:

Code: Select all

diff --git a/components/myguiplatform/myguirendermanager.cpp b/components/myguiplatform/myguirendermanager.cpp
index 773c58a..3ba5783 100644
--- a/components/myguiplatform/myguirendermanager.cpp
+++ b/components/myguiplatform/myguirendermanager.cpp
@@ -521,12 +521,8 @@ void RenderManager::destroyAllResources()
 
 bool RenderManager::checkTexture(MyGUI::ITexture* _texture)
 {
-    for (MapTexture::const_iterator item = mTextures.begin(); item != mTextures.end(); ++item)
-    {
-        if (item->second == _texture)
-            return true;
-    }
-    return false;
+    // We support external textures that aren't registered via this manager, so can't implement this method sensibly.
+    return true;
 }
 
 }
Top
dteviot
Posts: 144
Joined: 17 Dec 2014, 20:29

Re: (not) building OpenMW + OSG on Windows.

Post by dteviot »

Thanks Scrawl.

I have good news and bad news.

The good news, "Load" screen now appears, and I'm able to load some save games.

The bad news:
When start game, leaving boat fails in new place.
When click on the "Hatch to Seyda Neen", the "Loading Area" dialog appears with a progress bar that starts, then there's an invalid pointer error.
I get the same failure when I try to load a save game which has "Seyda Neen" as the cell.
Note, I have no problem loading the Balmora City cell, nor "Belmora, South Wall CornerClub".

Details:
Unhandled exception at 0x534FB3B1 (osg100-osgd.dll) in openmw.exe: 0xC0000005: Access violation writing location 0xABABABAB.
stack trace:
Spoiler: Show
Walking up the stack trace, at lowest level the problem seems to start at
> osg100-osgd.dll!osg::BufferObject::getOrCreateGLBufferObject(unsigned int contextID) Line 590 C++

Code: Select all

        GLBufferObject* getOrCreateGLBufferObject(unsigned int contextID) const
        {
            if (!_glBufferObjects[contextID]) _glBufferObjects[contextID] = GLBufferObject::createGLBufferObject(contextID, this);
            return _glBufferObjects[contextID].get();
        }
At this point, _glBufferObjects is an empty array. (contextID is 0)
Top
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: (not) building OpenMW + OSG on Windows.

Post by scrawl »

Do you have the stack trace for all threads?
Top
dteviot
Posts: 144
Joined: 17 Dec 2014, 20:29

Re: (not) building OpenMW + OSG on Windows.

Post by dteviot »

scrawl wrote:Do you have the stack trace for all threads?
Regretably, no.
I assume you're suspecting a race condition?
If so, you could be right. Problem is now not showing itself.
But I swear, I was able to reproduce multiple times.
Next time I catch it, I should be able to get you a full set of stack traces.
Top
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: (not) building OpenMW + OSG on Windows.

Post by scrawl »

At this point, _glBufferObjects is an empty array. (contextID is 0)
That isn't a problem. The operator[] automatically resizes the array to the required size on access.
I assume you're suspecting a race condition?
Yes. The same problem was reported here, but we haven't had any luck reproducing it.
Top
dteviot
Posts: 144
Joined: 17 Dec 2014, 20:29

Re: (not) building OpenMW + OSG on Windows.

Post by dteviot »

scrawl wrote:
At this point, _glBufferObjects is an empty array. (contextID is 0)
That isn't a problem. The operator[] automatically resizes the array to the required size on access.
I think you're mistaken. (But I'd be happy to be proven wrong.)
http://www.cplusplus.com/reference/vector/vector/
(see the operator[]) entry.)
Portable programs should never call this function with an argument n that is out of range, since this causes undefined behavior.
When _glBufferObjects is empty, doing this (even with a contextID = 0)

Code: Select all

if (!_glBufferObjects[contextID])
is going to try reading memory with an undefined value.
Top
Chris
Posts: 1626
Joined: 04 Sep 2011, 08:33

Re: (not) building OpenMW + OSG on Windows.

Post by Chris »

dteviot wrote:I think you're mistaken. (But I'd be happy to be proven wrong.)
http://www.cplusplus.com/reference/vector/vector/
(see the operator[]) entry.)
_glBufferObjects is a GLBufferObjects, aka osg::buffered_object<osg::ref_ptr<GLBufferObject>>. An osg::buffered_object automatically resizes with operator[].
Top
Locked

Return to “Support”