[3.0] MyGUI build working for Ogre-Next 3.0

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


User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

[3.0] MyGUI build working for Ogre-Next 3.0

Post by Crystal Hammer »

Hi.
This is a continuation of that MyGUI topic for Ogre 2.2.

I made a fork mygui-next with changes on branch ogre3, which I had to do to build it with latest Ogre-next 3.0 master.
Hope the readme there explains how to use.

I only tested with ogre-next build scripts on Debian 11 so far.

Last edited by Crystal Hammer on Mon Nov 13, 2023 2:51 am, edited 1 time in total.
User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

Okay this build is working fine, already in WIP StuntRally3.

22_18-27-24`s2.jpg
22_18-36-23`s4.jpg

But only does so in Release and ReleaseWithDebugInfo.
When I switch to Debug it is still crashing on this:

Code: Select all

Load ini file 'core_font.xml'
ResourceTrueTypeFont: Property 'SpaceWidth' in font 'hud.fps' is deprecated; remove it to use automatic calculation.
StuntRally3: ../../OgreMain/src/OgreHlmsManager.cpp:176: T* Ogre::HlmsManager::getBasicBlock(typename Ogre::vector<T>::type&, const T&) [with T = Ogre::HlmsBlendblock; Ogre::HlmsBasicBlock type = Ogre::BLOCK_BLEND; long unsigned int maxLimit = 4096; typename Ogre::vector<T>::type = std::vector<Ogre::HlmsBlendblock, std::allocator<Ogre::HlmsBlendblock> >]: Assertion `baseParams.mBlockType == type && "baseParams.mBlockType should always be BLOCK_MACRO or BLOCK_BLEND! " "You can ignore this assert,  but it usually indicates memory corruption" "(or you created the block without its default constructor)."' failed.
Aborted

It's the same what happened in my previous post.
I don't really know how to fix that yet.

Only thing I see different is the colors. Even on GUI they are less saturated. I suspect this is that sRGB thing now right? Pity, I can't really go through all colors and adjust to have them the same. Old StuntRally has still more saturated colorful GUI.

You do not have the required permissions to view the files attached to this post.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

But only does so in Release and ReleaseWithDebugInfo.
When I switch to Debug it is still crashing on this:

That bug can happen for various reasons:

  • ABI mismatch. We have a way to detect this in OgreNext 3.0. Ogre::Root constructor now accepts an AbiCookie argument, which can be nullptr to skip the ABI check. Make sure it's not null and you initialize Root like this:

    Code: Select all

    #include "OgreAbiUtils.h"
    
    const Ogre::AbiCookie abiCookie = Ogre::generateAbiCookie();
    mRoot = OGRE_NEW Ogre::Root( &abiCookie, pluginsPath, cfgPath,
                             mWriteAccessFolder + "Ogre.log", windowTitle );
  • Memory corruption. Run Valgrind. Once found, make a good habit to compile with ASAN enabled (set OGRE_ADDRESS_SANITIZER_ASAN to on) and in your program:

    Code: Select all

    if( MY_APP_ENABLED_ASAN )
    	if( APPLE )
    		set( CMAKE_XCODE_GENERATE_SCHEME ON )
    		set( CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER ON )
    		set( CMAKE_XCODE_SCHEME_ADDRESS_SANITIZER_USE_AFTER_RETURN ON )
    	elseif( UNIX )
    		set( CMAKE_C_FLAGS
    			"${CMAKE_C_FLAGS} -fno-omit-frame-pointer -fno-optimize-sibling-calls -fsanitize=address" )
    		set( CMAKE_CXX_FLAGS
    			"${CMAKE_CXX_FLAGS} -fno-omit-frame-pointer -fno-optimize-sibling-calls -fsanitize=address" )
    		set( CMAKE_LINKER_FLAGS "${CMAKE_LINKER_FLAGS} -fsanitize=address" )
    	elseif( MSVC )
    		set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS_DEBUG} /fsanitize=address" )
    		set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_DEBUG} /fsanitize=address" )
    	endif()
    endif()
  • At some point in your code, you did this:

    Code: Select all

    HlmsMacroblock macroblock;
    myDatablock->setMacroblock( &macroblock ); // WRONG!!! See documentation.
    myDatablock->setMacroblock( macroblock ); // Correct

Only thing I see different is the colors. Even on GUI they are less saturated. I suspect this is that sRGB thing now right? Pity, I can't really go through all colors and adjust to have them the same. Old StuntRally has still more saturated colorful GUI.

Yes.

Something like this won't work for you?

Code: Select all

Ogre::Hlms *hlms = hlmsManager->getHlms( Ogre::HLMS_UNLIT );

if( hlms )
{
    const Ogre::Hlms::HlmsDatablockMap &datablocks = hlms->getDatablockMap();

for( const auto &entryPair : datablocks )
{
    const Ogre::Hlms::DatablockEntry &entry = entryPair.second;

    if( entry.name.find( "some_pattern" ) != Ogre::String::npos ||
        entry.srcFile.find( "another_pattern" ) != Ogre::String::npos ||
        entry.srcResourceGroup == "Specific Resource Group" )
    {
        OGRE_ASSERT_HIGH( dynamic_cast<Ogre::HlmsUnlitDatablock *>( entry.datablock ) );
        Ogre::HlmsUnlitDatablock *unlitDatablock =
            static_cast<Ogre::HlmsUnlitDatablock *>( entry.datablock );

        const Ogre::ColourValue colour = unlitDatablock->getColour();
        unlitDatablock->setColour(
            Ogre::ColourValue( Ogre::PixelFormatGpuUtils::toSRGB( colour.r ),
                               Ogre::PixelFormatGpuUtils::toSRGB( colour.g ),
                               Ogre::PixelFormatGpuUtils::toSRGB( colour.b ), colour.a ) );
    }
}
}

root->getHlmsManager()->saveMaterials( Ogre::HLMS_UNLIT, "AutoConverted.material.json", 0,
                                       Ogre::BLANKSTRING );
User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

Thanks.
So for the cases:

  • ABI mismatch.
    It's ok. I have those lines, I'm just using OgreCommon/GraphicsSystem.cpp and it's there.

  • myDatablock->setMacroblock( &macroblock ); // WRONG!!!
    I checked this again and I don't see it (yet?).
    Here are basically all places found with all block stuff:

    1. this line sets renderable->setDatablock(texture->getDataBlock()); but it needs
      Ogre::Renderable::setDatablock(Ogre::HlmsDatablock*)
      I can't do renderable->setDatablock(*texture->getDataBlock()); here, won't build
      https://github.com/cryham/mygui-next/bl ... r.cpp#L478
    2. here is createUnlitDataBlock
      https://github.com/cryham/mygui-next/bl ... re.cpp#L42
      variables are so:

      Code: Select all

      		Ogre::HlmsUnlitDatablock* mDataBlock;
      	private:
      		static const OgreHlmsBlocks HLMS_BLOCKS;
      
      and ctor creating those blocks is here:
      https://github.com/cryham/mygui-next/bl ... ture.h#L39
      IDK, is this being static bad or not?
      I also tried with

      Code: Select all

      			return static_cast<Ogre::HlmsUnlitDatablock*>(hlms->createDatablock(Ogre::IdString( id ), id,
      				Ogre::HlmsMacroblock(), Ogre::HlmsBlendblock(), Ogre::HlmsParamVec() ));  // this
      				//mMacroBlock, mBlendBlock, mParamsVec));  // instead of this
      
      but no change.
  • Memory corruption. Run Valgrind.
    So I run my Gui demo (based on EmptyProject) now with valgrind and this is what I get at end:

    Code: Select all

    * Initialise: ToolTipManager
    ToolTipManager successfully initialized
    Load ini file 'core_font.xml'
    ResourceTrueTypeFont: Property 'SpaceWidth' in font 'hud.fps' is deprecated; remove it to use automatic calculation.
    WARNING: baseParams.mBlockType != type
    EmptyProject: ../../OgreMain/src/OgreHlmsManager.cpp:178: T* Ogre::HlmsManager::getBasicBlock(typename Ogre::vector<T>::type&, const T&) [with T = Ogre::HlmsBlendblock; Ogre::HlmsBasicBlock type = Ogre::BLOCK_BLEND; long unsigned int maxLimit = 4096; typename Ogre::vector<T>::type = std::vector<Ogre::HlmsBlendblock, std::allocator<Ogre::HlmsBlendblock> >]: Assertion `baseParams.mBlockType == type && "baseParams.mBlockType should always be BLOCK_MACRO or BLOCK_BLEND! " "You can ignore this assert,  but it usually indicates memory corruption" "(or you created the block without its default constructor)."' failed.
    ==192080== 
    ==192080== Process terminating with default action of signal 6 (SIGABRT)
    ==192080==    at 0x5BC2CE1: raise (raise.c:51)
    ==192080==    by 0x5BAC536: abort (abort.c:79)
    ==192080==    by 0x5BAC40E: __assert_fail_base.cold (assert.c:92)
    ==192080==    by 0x5BBB661: __assert_fail (assert.c:101)
    ==192080==    by 0x4B4A38C: Ogre::HlmsBlendblock* Ogre::HlmsManager::getBasicBlock<Ogre::HlmsBlendblock, (Ogre::HlmsBasicBlock)1, 4096ul>(Ogre::vector<Ogre::HlmsBlendblock>::type&, Ogre::HlmsBlendblock const&) (OgreHlmsManager.cpp:178)
    ==192080==    by 0x4B44DBA: Ogre::HlmsManager::getBlendblock(Ogre::HlmsBlendblock const&) (OgreHlmsManager.cpp:251)
    ==192080==    by 0x4AE2C4A: Ogre::Hlms::createDatablock(Ogre::IdString, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Ogre::HlmsMacroblock const&, Ogre::HlmsBlendblock const&, std::vector<std::pair<Ogre::IdString, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<Ogre::IdString, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (OgreHlms.cpp:1897)
    ==192080==    by 0x19F810: MyGUI::OgreHlmsBlocks::createUnlitDataBlock(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) const (MyGUI_Ogre2Texture.h:66)
    ==192080==    by 0x19E90E: MyGUI::Ogre2Texture::Ogre2Texture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (MyGUI_Ogre2Texture.cpp:42)
    ==192080==    by 0x19B1F2: MyGUI::Ogre2RenderManager::createTexture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (MyGUI_Ogre2RenderManager.cpp:330)
    ==192080==    by 0x57A7D49: void MyGUI::ResourceTrueTypeFont::initialiseFreeType<false, false>() (MyGUI_ResourceTrueTypeFont.cpp:770)
    ==192080==    by 0x57A2B91: MyGUI::ResourceTrueTypeFont::deserialization(MyGUI::xml::Element*, MyGUI::Version) (MyGUI_ResourceTrueTypeFont.cpp:376)
    ==192080== 
    ==192080== HEAP SUMMARY:
    ==192080==     in use at exit: 25,506,691 bytes in 40,310 blocks
    ==192080==   total heap usage: 180,826 allocs, 140,516 frees, 146,570,092 bytes allocated
    ==192080== 
    ==192080== LEAK SUMMARY:
    ==192080==    definitely lost: 2,120 bytes in 32 blocks
    ==192080==    indirectly lost: 6,360 bytes in 6 blocks
    ==192080==      possibly lost: 7,085,596 bytes in 9,320 blocks
    ==192080==    still reachable: 18,412,507 bytes in 30,946 blocks
    ==192080==                       of which reachable via heuristic:
    ==192080==                         newarray           : 2,044,288 bytes in 32 blocks
    ==192080==                         multipleinheritance: 20,632 bytes in 29 blocks
    ==192080==         suppressed: 108 bytes in 6 blocks
    ==192080== Rerun with --leak-check=full to see details of leaked memory
    ==192080== 
    ==192080== For lists of detected and suppressed errors, rerun with: -s
    ==192080== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
    Aborted
    

    So it is crashing in debug here, and I don't get it.
    I added setting types like so but this didn't change anything:

    Code: Select all

    	
    		OgreHlmsBlocks() 
    		{
    			mMacroBlock.mBlockType = Ogre::BLOCK_MACRO;
    
    	mBlendBlock.mBlockType = Ogre::BLOCK_BLEND;
    
    	mSamplerBlock.mBlockType = Ogre::BLOCK_SAMPLER;
    

    and valgrind also shows this somewhat earlier:

    Code: Select all

    Finished parsing scripts for resource group Popular
    Creating resources for group Popular
    All done
    * Initialise: RenderManager
    ==192080== Invalid write of size 8
    ==192080==    at 0x4C22C8A: Ogre::MovableObject::MovableObject(unsigned int, Ogre::ObjectMemoryManager*, Ogre::SceneManager*, unsigned char) (OgreMovableObject.cpp:75)
    ==192080==    by 0x198FCB: Ogre2GuiMoveable (MyGUI_Ogre2GuiMoveable.h:18)
    ==192080==    by 0x198FCB: MyGUI::Ogre2RenderManager::initialise(Ogre::Window*, Ogre::SceneManager*) (MyGUI_Ogre2RenderManager.cpp:109)
    ==192080==    by 0x164394: MyGUI::Ogre2Platform::initialise(Ogre::Window*, Ogre::SceneManager*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (MyGUI_Ogre2Platform.h:57)
    ==192080==    by 0x162A08: Demo::EmptyProjectGameState::createScene01() (EmptyProjectGameState.cpp:61)
    ==192080==    by 0x1666F0: Demo::BaseSystem::createScene01() (BaseSystem.cpp:15)
    ==192080==    by 0x17F667: Demo::MainEntryPoints::mainAppSingleThreaded(int, char const**) (MainLoopSingleThreaded.cpp:98)
    ==192080==    by 0x1621C7: mainApp(int, char const**) (EmptyProject.cpp:35)
    ==192080==    by 0x16210D: main (MainEntryPointHelper.h:40)
    ==192080==  Address 0x3d6c9270 is 0 bytes after a block of size 304 alloc'd
    ==192080==    at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
    ==192080==    by 0x198FAB: MyGUI::Ogre2RenderManager::initialise(Ogre::Window*, Ogre::SceneManager*) (MyGUI_Ogre2RenderManager.cpp:109)
    ==192080==    by 0x164394: MyGUI::Ogre2Platform::initialise(Ogre::Window*, Ogre::SceneManager*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (MyGUI_Ogre2Platform.h:57)
    ==192080==    by 0x162A08: Demo::EmptyProjectGameState::createScene01() (EmptyProjectGameState.cpp:61)
    ==192080==    by 0x1666F0: Demo::BaseSystem::createScene01() (BaseSystem.cpp:15)
    ==192080==    by 0x17F667: Demo::MainEntryPoints::mainAppSingleThreaded(int, char const**) (MainLoopSingleThreaded.cpp:98)
    ==192080==    by 0x1621C7: mainApp(int, char const**) (EmptyProject.cpp:35)
    ==192080==    by 0x16210D: main (MainEntryPointHelper.h:40)
    ==192080== 
    ==192080== Invalid write of size 8
    ==192080==    at 0x4D6F62B: Ogre::SceneNode::attachObject(Ogre::MovableObject*) (OgreSceneNode.cpp:130)
    ==192080==    by 0x199025: MyGUI::Ogre2RenderManager::initialise(Ogre::Window*, Ogre::SceneManager*) (MyGUI_Ogre2RenderManager.cpp:112)
    ==192080==    by 0x164394: MyGUI::Ogre2Platform::initialise(Ogre::Window*, Ogre::SceneManager*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (MyGUI_Ogre2Platform.h:57)
    ==192080==    by 0x162A08: Demo::EmptyProjectGameState::createScene01() (EmptyProjectGameState.cpp:61)
    ==192080==    by 0x1666F0: Demo::BaseSystem::createScene01() (BaseSystem.cpp:15)
    ==192080==    by 0x17F667: Demo::MainEntryPoints::mainAppSingleThreaded(int, char const**) (MainLoopSingleThreaded.cpp:98)
    ==192080==    by 0x1621C7: mainApp(int, char const**) (EmptyProject.cpp:35)
    ==192080==    by 0x16210D: main (MainEntryPointHelper.h:40)
    ==192080==  Address 0x3d6c9270 is 0 bytes after a block of size 304 alloc'd
    ==192080==    at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
    ==192080==    by 0x198FAB: MyGUI::Ogre2RenderManager::initialise(Ogre::Window*, Ogre::SceneManager*) (MyGUI_Ogre2RenderManager.cpp:109)
    ==192080==    by 0x164394: MyGUI::Ogre2Platform::initialise(Ogre::Window*, Ogre::SceneManager*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (MyGUI_Ogre2Platform.h:57)
    ==192080==    by 0x162A08: Demo::EmptyProjectGameState::createScene01() (EmptyProjectGameState.cpp:61)
    ==192080==    by 0x1666F0: Demo::BaseSystem::createScene01() (BaseSystem.cpp:15)
    ==192080==    by 0x17F667: Demo::MainEntryPoints::mainAppSingleThreaded(int, char const**) (MainLoopSingleThreaded.cpp:98)
    ==192080==    by 0x1621C7: mainApp(int, char const**) (EmptyProject.cpp:35)
    ==192080==    by 0x16210D: main (MainEntryPointHelper.h:40)
    ==192080== 
    RenderManager successfully initialized
    

    Can someone spot anything and help with this or tell what to do next?

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

and valgrind also shows this somewhat earlier:

THIS should be your focus. Valgrind is telling you that 8 bytes of memory are being corrupted right at startup. Once that happens, everything that follows could be a cascade of errors falling like a domino.

I don't understand why it says that it is being corrupted though, it makes little sense. I tried compiling MyGUI from scratch but it has no usable demos, only the library.

So I don't have a quick way to test it.

However THIS caught my eye:

Code: Select all

-- Ogre3    config: /home/matias/mygui-next/Ogre/ogre-next/build/Release/include
-- Ogre3   include: /home/matias/mygui-next/Ogre/ogre-next/OgreMain/include
-- Ogre3 libraries: /home/matias/mygui-next/Ogre/ogre-next/build/Release/lib/libOgreMain.so.3.0
-- Ogre3   lib dir: /home/matias/mygui-next/Ogre/ogre-next/build/Release/lib

It seems that CMake while building MyGUI picked up the Release version of Ogre, even though I'm building MyGUI with CMAKE_BUILD_TYPE=Debug

This can cause many types of problems, including the ones you are having.

This could be fixed by changing CMake/Packages/FindOGRE_next.cmake to this (this fix will not work on Windows + MSVC):

Code: Select all

# Set OGRE-next includes and library

message(STATUS "Ogre3:  Setting fixed paths, one up")

get_filename_component(DIR_ONE_ABOVE ../ ABSOLUTE)
message(STATUS ${DIR_ONE_ABOVE})

set(OGRE_NEXT ${DIR_ONE_ABOVE}/Ogre/ogre-next)
#set(OGRE_NEXT "../Ogre/ogre-next")

set(OGRE_CONFIG_INCLUDE_DIR ${OGRE_NEXT}/build/${CMAKE_BUILD_TYPE}/include)
set(OGRE_INCLUDE_DIR ${OGRE_NEXT}/OgreMain/include)
set(OGRE_LIBRARIES ${OGRE_NEXT}/build/${CMAKE_BUILD_TYPE}/lib/libOgreMain.so.3.0)
set(OGRE_LIB_DIR ${OGRE_NEXT}/build/${CMAKE_BUILD_TYPE}/lib)

message(STATUS "Ogre3    config: " ${OGRE_CONFIG_INCLUDE_DIR})
message(STATUS "Ogre3   include: " ${OGRE_INCLUDE_DIR})
#message(STATUS "Ogre3    source: " ${OGRE_SOURCE_DIR})
message(STATUS "Ogre3 libraries: " ${OGRE_LIBRARIES})
message(STATUS "Ogre3   lib dir: " ${OGRE_LIB_DIR})

SET(OGRE_FOUND TRUE)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

Crystal Hammer wrote: Wed Feb 15, 2023 10:48 pm

this line sets renderable->setDatablock(texture->getDataBlock()); but it needs
Ogre::Renderable::setDatablock(Ogre::HlmsDatablock)
I can't do renderable->setDatablock(
texture->getDataBlock()); here, won't build

I meant the BasicBlocks. i.e. HlmsMacroblock, HlmsBlendblock, HlmsSamplerblock.
HlmsDatablock is different.

Thus don't worry about the setDatablock() calls.

Cheers.

User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

Great thanks for finding out. I must have forgotten completely and initially thought it worked.

Added this CMAKE_BUILD_TYPE into git repo and I've built it.
Now I can't start. I'll post details later.
I'll try to add a Gui test app (to cmake and git) from EmptyProject that would allow testing.
I also updated Ogre-Next to latest.

But first things first, there is a crash in Ogre-Next:
you added PASS_WARM_UP to CompositorPassType but did not add it to CompositorPassTypeEnumNames e.g. "WARM_UP" :shock:

User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

So now I get this crash before start in Debug:

Code: Select all

Info: Freetype returned null for character 158 in font DebugFont
Info: Freetype returned null for character 159 in font DebugFont
Info: Freetype returned null for character 160 in font DebugFont
../../OgreMain/src/OgreRenderQueue.cpp(995): Assert Failure: 'mRenderingStarted == 0u && "Called RenderQueue::frameEnded mid-render. This may happen if VaoManager::_update got " "called after RenderQueue::renderPassPrepare but before RenderQueue::render returns. Please " "move that VaoManager::_update call outside, otherwise we cannot guarantee rendering will " "be glitch-free, as the BufferPacked buffers from Hlms may be bound at the wrong offset. " "For more info see https://github.com/OGRECave/ogre-next/issues/33 and " "https://forums.ogre3d.org/viewtopic.php?f=25&t=95092#p545907"' 
Trace/breakpoint trap

Callstack looks so:

Code: Select all

::trap_instruction() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/include/debugbreak/debugbreak.h:48)
debug_break (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/include/debugbreak/debugbreak.h:136)
Ogre::RenderQueue::frameEnded() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreRenderQueue.cpp:995)
Ogre::SceneManager::_frameEnded() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreSceneManager.cpp:1609)
Ogre::Root::_renderingFrameEnded() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreRoot.cpp:1620)
Ogre::VaoManager::_update() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/Vao/OgreVaoManager.cpp:680)
Ogre::GL3PlusVaoManager::_update() (/home/ch/_sr/og3/Ogre/ogre-next/RenderSystems/GL3Plus/src/Vao/OgreGL3PlusVaoManager.cpp:1485)
Ogre::RenderSystem::_update() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreRenderSystem.cpp:1306)
Ogre::CompositorManager2::_updateImplementation() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/Compositor/OgreCompositorManager2.cpp:806)
Ogre::RenderSystem::updateCompositorManager(Ogre::CompositorManager2*) (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreRenderSystem.cpp:1311)
Ogre::CompositorManager2::_update() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/Compositor/OgreCompositorManager2.cpp:712)
Ogre::Root::_updateAllRenderTargets() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreRoot.cpp:1568)
Ogre::Root::renderOneFrame() (/home/ch/_sr/og3/Ogre/ogre-next/OgreMain/src/OgreRoot.cpp:1102)
Demo::GraphicsSystem::update(float) (/home/ch/_sr/og3/1gui/src/OgreCommon/GraphicsSystem.cpp:426)
Demo::MainEntryPoints::mainAppSingleThreaded(int, char const**) (/home/ch/_sr/og3/1gui/src/OgreCommon/System/Desktop/MainLoopSingleThreaded.cpp:135)
mainApp(int, char const**) (/home/ch/_sr/og3/1gui/src/EmptyProject.cpp:35)
main (/home/ch/_sr/og3/1gui/include/OgreCommon/MainEntryPointHelper.h:40)
__libc_start_main (@__libc_start_main:62)
_start (@_start:14)

Argh :x . Why didn't this happen before and does now?
It writes hints for finding out:
viewtopic.php?f=25&t=95092#p545907
https://github.com/OGRECave/ogre-next/issues/33

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

Could you try a version before the warm_up pass? I'm worried I messed up something (that was pushed a few days ago)

But first things first, there is a crash in Ogre-Next:
you added PASS_WARM_UP to CompositorPassType but did not add it to CompositorPassTypeEnumNames e.g. "WARM_UP" :shock:

Fixed! Thanks!!!

Crystal Hammer wrote: Sun Feb 19, 2023 1:47 pm

So now I get this crash before start in Debug:

Argh :x . Why didn't this happen before and does now?
It writes hints for finding out:

Normally, it works like this:

  • When we are about to start rendering, we increase ++mRenderingStarted;

  • When we are done rendering, we decrease --mRenderingStarted;

  • By the time RenderQueue::frameEnded() gets called, mRenderingStarted must be 0, which means we are already done rendering. If it's not 0, then either we somehow forgot to inc/decrease mRenderingStarted; or more likely VaoManager::_update got called in the middle; which must not happen (i.e. if

But given the very recent changes it's possible that:

  • I screwed something up

  • You need to cleanup and rebuild everything, possibly an old version of libOgreNext got mixed up

When you hook a debugger, what is the value of mRenderingStarted ?

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

I took a quick look at MYGUI's source code, I think the problem is in MyGui's rendering.

Since OgreNext 2.3 one must call RenderQueue::renderPassPrepare before rendering, but this does not appear to be ever done in MyGUI. The same happens with executeRenderPassDescriptorDelayedActions

It's quite possible the fix would be in Ogre2RenderManager::render:

Code: Select all

void Ogre2RenderManager::render()
{
	Gui* gui = Gui::getInstancePtr();
	if (gui == nullptr)
		return;

mCountBatch = 0;

setManualRender(true);

mSceneManager->getRenderQueue()->clear();
mSceneManager->getRenderQueue()->renderPassPrepare(false, false);

//get mygui to itterate through renderables and call 'doRender'
//This will add renderbles to the Ogre render queue
onRenderToTarget(this, mUpdate);

mRenderSystem->executeRenderPassDescriptorDelayedActions();
mSceneManager->getRenderQueue()->render(mRenderSystem, RENDER_QUEUE_OVERLAY, RENDER_QUEUE_OVERLAY+1, false, false);

// сбрасываем флаг
mUpdate = false;
}

As to why it was working before: My guess is because in Debug mode you were not reaching that far due to a previous assert, and in Release mode assertions are disabled.

User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

All right, big thank you. It works now (with the above MyGui fix) in my Gui test app in Debug.
I only have this at quit:

Code: Select all

*-*-* OGRE Shutdown
Unregistering ResourceManager for type OldSkeleton
Unregistering ResourceManager for type Mesh2
Unregistering ResourceManager for type Mesh
Unregistering ResourceManager for type Material
EmptyProject: ../../OgreMain/src/OgreHlmsDatablock.cpp:198: virtual Ogre::HlmsDatablock::~HlmsDatablock(): Assertion `mLinkedRenderables.empty() && "This Datablock is still being used by some Renderables." " Change their Datablocks before destroying this."' failed.
Aborted
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

GREAT!

That last error is because an HlmsDatablock is being deleted but there is still a Renderable using it. Very common if you don't properly cleanup all your widgets (or they are destroyed in the wrong order).

You can look at HlmsDatablock::mLinkedRenderables to see which objects are still using it.

User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

So I didn't try that sRGB color fix, since I kind of found a way to change it in shader, by adding
diffuseCol.xyz = pow(diffuseCol.xyz, midf3_c(1.1f, 1.1f, 1.1f));
bottom of Hlms/Unlit/Any/800.PixelShader_piece_ps.any, before @insertpiece( custom_ps_preLights )

It isn't exactly as before but I guess it will do.
But now I got preview images back, also for terrain layer textures and brushes, and they have the same saturation from sRGB issue, looking bad:
Left is Gui, right inside red is the image from viewer, how it should look like.

26_18-15-42s2.jpg

Is there a quick way to fix it?
Without going through all pixels via CPU? I'm already using Image2 to load from given path, so I could do that, but it'd be slow.

You do not have the required permissions to view the files attached to this post.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

I assume you didn't use sRGB / gamma correction in Ogre 1.x?

You could set both gamma to off (see "sRGB Gamma Conversion" references in GraphicsSystem.cpp) and set TextureGpuManager::mIgnoreSRgbPreference to false (do it as early as possible) to completely turn off sRGB space; but beware this goes against PBR.

If you wish to not do that, then a texture that is currently PFG_RGBA8_UNORM_SRGB should be PFG_RGBA8_UNORM or viceversa. Check in RenderDoc to see their actual format.

As for the diffuse colours of the materials without textures, you can change the diffuse materials values with PixelFormatGpuUtils::toSRGB/fromSRGB.

User avatar
sercero
Bronze Sponsor
Bronze Sponsor
Posts: 487
Joined: Sun Jan 18, 2015 4:20 pm
Location: Buenos Aires, Argentina
x 170

Re: [3.0] MyGUI build working for Ogre 3.0

Post by sercero »

dark_sylinc wrote: Thu Feb 16, 2023 2:18 am

and valgrind also shows this somewhat earlier:

THIS should be your focus. Valgrind is telling you that 8 bytes of memory are being corrupted right at startup. Once that happens, everything that follows could be a cascade of errors falling like a domino.

I don't understand why it says that it is being corrupted though, it makes little sense. I tried compiling MyGUI from scratch but it has no usable demos, only the library.

So I don't have a quick way to test it.

I'm suprised to read that, since MyGUI has a lot of examples and tests: MYGUI_BUILD_DEMOS, MYGUI_BUILD_TEST_APP, MYGUI_BUILD_UNITTESTS

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

But they seemed to be targeting Ogre 1.x unless I missed something.

For starters, it asked for OIS

User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

sercero wrote: Thu Mar 02, 2023 5:54 pm
dark_sylinc wrote: Thu Feb 16, 2023 2:18 am

and valgrind also shows this somewhat earlier:

THIS should be your focus. Valgrind is telling you that 8 bytes of memory are being corrupted right at startup. Once that happens, everything that follows could be a cascade of errors falling like a domino.

I don't understand why it says that it is being corrupted though, it makes little sense. I tried compiling MyGUI from scratch but it has no usable demos, only the library.

So I don't have a quick way to test it.

I'm suprised to read that, since MyGUI has a lot of examples and tests: MYGUI_BUILD_DEMOS, MYGUI_BUILD_TEST_APP, MYGUI_BUILD_UNITTESTS

This is fixed already. It was just my bad CMake config. That error doesn't happen in Debug now.

But yeah, there is no app to test Gui in my mygui-next repo yet. Demos and examples aren't in CMake and they don't build. This just builds the 2 MyGui libs needed for other projects.

Lax
Gnoll
Posts: 665
Joined: Mon Aug 06, 2007 12:53 pm
Location: Saarland, Germany
x 64

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Lax »

Hi all,

I read your discussion etc. and I'm wondering, why MyGUI is ported again for Ogre next?

There was an older thread, in which it has been already ported.
I have the newest version working for newest Ogre next version. But one feature is not working: Own render scene in mygui imagebox. That has never been ported.

I also adapted the mygui engine a bit. I improved small things like:

  • Key focus
  • Mouse focus thresholds
  • Slider etc.

Feel free to use it:

See:
https://github.com/Laxx18/NOWA-Engine/t ... yGUIEngine

Best Regards
Lax

http://www.lukas-kalinowski.com/Homepage/?page_id=1631
Please support Second Earth Technic Base built of Lego bricks for Lego ideas: https://ideas.lego.com/projects/81b9bd1 ... b97b79be62

User avatar
sercero
Bronze Sponsor
Bronze Sponsor
Posts: 487
Joined: Sun Jan 18, 2015 4:20 pm
Location: Buenos Aires, Argentina
x 170

Re: [3.0] MyGUI build working for Ogre 3.0

Post by sercero »

Lax wrote: Thu Mar 02, 2023 9:47 pm

Hi all,

I read your discussion etc. and I'm wondering, why MyGUI is ported again for Ogre next?

There was an older thread, in which it has been already ported.
I have the newest version working for newest Ogre next version. But one feature is not working: Own render scene in mygui imagebox. That has never been ported.

I also adapted the mygui engine a bit. I improved small things like:

  • Key focus
  • Mouse focus thresholds
  • Slider etc.

Feel free to use it:

See:
https://github.com/Laxx18/NOWA-Engine/t ... yGUIEngine

Best Regards
Lax

Hey @lax, that is great but why not contributing those changes to the main MyGUI repo so everyone benefits?

I don't understand.

Is it because nowadays @altren is not so active anymore?

Thanks!

Lax
Gnoll
Posts: 665
Joined: Mon Aug 06, 2007 12:53 pm
Location: Saarland, Germany
x 64

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Lax »

Hi sercero,

If you can show me how that works I will of course :D
I made some small changes over years here and there in the sources.

Best Regards
Lax

http://www.lukas-kalinowski.com/Homepage/?page_id=1631
Please support Second Earth Technic Base built of Lego bricks for Lego ideas: https://ideas.lego.com/projects/81b9bd1 ... b97b79be62

User avatar
sercero
Bronze Sponsor
Bronze Sponsor
Posts: 487
Joined: Sun Jan 18, 2015 4:20 pm
Location: Buenos Aires, Argentina
x 170

Re: [3.0] MyGUI build working for Ogre 3.0

Post by sercero »

Lax wrote: Fri Mar 03, 2023 10:04 pm

Hi sercero,

If you can show me how that works I will of course :D
I made some small changes over years here and there in the sources.

Best Regards
Lax

Great!

Let me create a mini-guide on how to contribute to an upstream project and I'll share it here.

Lax
Gnoll
Posts: 665
Joined: Mon Aug 06, 2007 12:53 pm
Location: Saarland, Germany
x 64

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Lax »

Sounds great!

http://www.lukas-kalinowski.com/Homepage/?page_id=1631
Please support Second Earth Technic Base built of Lego bricks for Lego ideas: https://ideas.lego.com/projects/81b9bd1 ... b97b79be62

User avatar
Crystal Hammer
Orc
Posts: 402
Joined: Sat Jun 23, 2007 5:16 pm
x 114

Re: [3.0] MyGUI build working for Ogre 3.0

Post by Crystal Hammer »

dark_sylinc wrote: Sun Feb 26, 2023 8:04 pm

I assume you didn't use sRGB / gamma correction in Ogre 1.x?

You could set both gamma to off (see "sRGB Gamma Conversion" references in GraphicsSystem.cpp) and set TextureGpuManager::mIgnoreSRgbPreference to false (do it as early as possible) to completely turn off sRGB space; but beware this goes against PBR.

No I didn't use sRGB before. All StuntRally textures are jpg or png (if transparent) and from around 2012 basically.

So I tried doing this with sRGB off.
In OgreCommon/GraphicsSystem.cpp forced:
setConfigOption( "sRGB Gamma Conversion", "No" );
and bit later, before setupResources(); I added
mRoot->getRenderSystem()->getTextureGpuManager()->mIgnoreSRgbPreference = false;

05_20-06-05s.jpg

But man this version does look bad too. Possibly worse even, instead of everything somewhat unsaturated (with sRGB on), now everything is very dark and very saturated (with sRGB off). I tried increasing light like 2 to 3 times more, and it still doesn't get white. Even Gui got very dark. The only thing that looks good are the preview images, I see they're the same in an image viewer.

So I'll stick with sRGB on. At least I got it's brightness to okay levels.
And I'm thinking of fixing this with postprocessing maybe, saw this cool tutorial:
https://catlikecoding.com/unity/tutoria ... r-grading/
for future. Maybe with some simple gamma parameter first for all shaders.

You do not have the required permissions to view the files attached to this post.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5454
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1352

Re: [3.0] MyGUI build working for Ogre 3.0

Post by dark_sylinc »

Long term, yes, you should aim to use sRGB.

So I tried doing this with sRGB off.
In OgreCommon/GraphicsSystem.cpp forced:
setConfigOption( "sRGB Gamma Conversion", "No" );
and bit later, before setupResources(); I added
mRoot->getRenderSystem()->getTextureGpuManager()->mIgnoreSRgbPreference = false;

If you are going to turn off sRGB, remember to disable the change you described which you said did pow( col, 1.1 ) or so.

User avatar
sercero
Bronze Sponsor
Bronze Sponsor
Posts: 487
Joined: Sun Jan 18, 2015 4:20 pm
Location: Buenos Aires, Argentina
x 170

Re: [3.0] MyGUI build working for Ogre 3.0

Post by sercero »

Lax wrote: Fri Mar 03, 2023 10:04 pm

Hi sercero,

If you can show me how that works I will of course :D
I made some small changes over years here and there in the sources.

Best Regards
Lax

Here is the guide: https://gist.github.com/sercero/c892681 ... f765d990cd

This was done with the help of @paroj that helped me with the contributions to ogreaudiovideo and blender2ogre

Let me know if you have any questions.

I made a general guide, but your case is special.

It is possible that you will have to do things a little different.