Ogre v14.6 v3

[slapin]

Updates to make work in Ogre 14.5+ (master branch).
Created in association with Kimi Code v2.7.

[slapin]

Everything works so far. Some GUIs look bad, tons of layout bugs, some robustness problems (like sometimes failing to start single player game because tcp port is busy, which is strange). It is at very least usable. Feel free to send feedback via github.

[slapin]

This PR depends on tomluchowski/cegui#1

[slapin]

tcp port issue is fixed for me now, too

[slapin]

I don't understand much about game itself but it seems that game play is working.

[Upabjojr]

Thanks for taking this on — getting the tree onto a current Ogre is a big job and the bulk of the port looks right. I read the diff on its own terms (against its own merge base, not against the tip of shaders-improvement) and left inline notes below.

I've pushed the fixes for everything in the "should fix" list to a branch so you can take them or ignore them as you like: Upabjojr:ogre-v14.6-v3-review-fixes, three commits on top of ff63881.

Caveat on my end: I only have Ogre 1.12 here and this needs 14.6 plus tomluchowski/cegui#1, so I could not build or run any of it. Everything below is from reading; treat the runtime claims as "needs checking" rather than "observed".

---

Should fix

1. ODSocketServer::mActualPort is never initialised. The new member isn't in the constructor's init list, and it's only assigned inside createServer(). ODServer::getNetworkPort() now calls getActualPort() unconditionally, so any call before the server starts reads an indeterminate value and can return a garbage port. One-word fix.

2. renderQueueStarted() dereferences a pointer that starts null. mCameraManager.getActiveCamera() is initialised to nullptr and stays that way until createCamera() runs, but the new condition calls ->getName() on it before the queueGroupId test can short-circuit anything useful.

3. ReflMetal.material is deleted but still referenced. models/Roundshield.mesh, models/Sabre.mesh and models/Wyvern.mesh all name the ReflMetal material, so they'll fall back to the default material. shaders/ReflMetal.vert, shaders/ReflMetal.frag and materials/textures/EnvmapMetal.png are also left orphaned. Either keep the script or retarget those three meshes and delete the rest — right now it's half-removed.

4. Seven materials got their braces reflowed. See the inline note on T2HammerGood.material; the same shape appears in T2ShieldEvil, T2ShieldGood, T2SwordGood, T3HammerGood, T3ShieldEvil and T3ShieldGood. It's brace-balanced so Ogre will parse it, but the nesting no longer reads as what it is.

5. Leftover debug instrumentation. dumpWindowTree() writes a line per widget to std::cerr on every settings-window open, and MenuModeMain::activate() logs the root geometry every time you enter the main menu.

6. Two competing C++ standard mechanisms. set(CMAKE_CXX_STANDARD 14) was added at the top, but line 213 still prepends -std=c++11 from the OD_CXX11_FLAGS probe into CMAKE_CXX_FLAGS. The standard flag currently wins by position, which is not something to rely on. CMAKE_CXX_STANDARD_REQUIRED also isn't set, so an old compiler silently degrades rather than failing.

---

Worth discussing (I have not changed these)

7. The ephemeral-port fallback changes multiplayer semantics. Falling back to port 0 when the configured port is busy turns a loud failure into a silent one. It fixes single-player, but a LAN host whose port is taken now binds somewhere random while remote clients still dial the advertised port and just fail to connect. Would it be better to scope the fallback to the single-player/local case, and keep the hard error when hosting?

8. x11_mouse_hide flipped from "false" to "true". Unrelated to the Ogre upgrade and unmentioned in the description. If it's needed because CEGUI now draws the cursor itself, a comment saying so would help; if it's a leftover experiment, it should probably come out.

9. The SettingsWindow scaling helpers. Two structural issues: centerAndScaleWindow() rewrites the area into pure pixel offsets, so the window stops tracking display resizes entirely; and the whole thing runs once in the constructor, so after you change resolution from that very window the scale is stale until restart. Recomputing on a display-size-changed event would fix both.

10. Vendoring SGXLib_NormalMap.glsl and RTSLib_Colour.glsl from Ogre. These are Ogre's own RTShaderLib files, and resources.cfg lists both @RTSHADER_DIR@ and the in-tree materials/RTShaderLib — so which copy wins depends on resource group ordering, and the local copy will drift from whatever Ogre is installed. They also use the OgreUnifiedShader.h macros (f32vec2, mtxFromCols, vec3_splat), which have to match the installed Ogre. If the intent was to work around the resource path not being found, the resources.cfg.in change already covers that and these could go.

11. 194 re-serialised .mesh files. The diff is a two-byte header rewrite each — [MeshSerializer_v1.8] → [MeshSerializer_v1.100], no geometry change. Ogre 14 still loads v1.8 meshes (with a deprecation warning), so this looks optional, and it's what makes the PR 297 files instead of ~100. Could it be split into its own commit or PR? It would make the actual port reviewable, and it's a one-way step for anyone still on an older Ogre.

---

Nits

• #include <fstream> in ODPacket.cpp and ConfigManager.cpp duplicates one already present a few lines down.
• The new includes across the renderscene/ and creaturemood/ files sit above each file's own header, which defeats the self-containedness check that ordering exists for.
• Five statements next to the new buildTangentVectorsIfNeeded() calls in RenderManager.cpp ended up in column 0.
• buildTangentVectorsIfNeeded() takes Ogre::MeshPtr by value, copying a shared pointer per call.
• *oldMaterial.get() — *oldMaterial does the same thing.
• Three #if OGRE_VERSION < 0x10A00 / #else blocks in RenderManager.cpp now have identical branches. MovableTextOverlay.cpp correctly deletes the whole thing; these should match.
• resources.cfg.in ends up with [Graphics] twice and @OGRE_MEDIA_DIR@/Main listed under two groups.
• Both new .glsl files are missing a trailing newline.
• Gui.cpp hardcodes "LiberationSans-10" as the default font and will throw UnknownObjectException if that font ever goes away — a check or a named constant would be kinder.
• SettingsWindow.cpp:251: if (tabControl) never fires, since CEGUI's getChild() throws rather than returning null.

[Upabjojr]

mActualPort isn't in the constructor's init list — ODSocketServer::ODSocketServer(): mThread(nullptr), mIsConnected(false) {} — and it's only assigned inside createServer().

So any read before the server starts is indeterminate. That matters because ODServer::getNetworkPort() now calls getActualPort() unconditionally:

int32_t actualPort = getActualPort();
if(actualPort != 0)
    return actualPort;

which means it can return a garbage port instead of falling through to ConfigManager::getNetworkPort(). Adding mActualPort(0), to the init list fixes it.

[Upabjojr]

getActiveCamera() can be null here. CameraManager initialises mActiveCamera(nullptr) and only assigns it in setActiveCamera(), so between this listener being registered and the camera being created, ->getName() dereferences null.

const Ogre::Camera* activeCamera = mCameraManager.getActiveCamera();
if(queueGroupId == RenderManager::OD_RENDER_QUEUE_ID_GUI &&
   activeCamera != nullptr && cameraName == activeCamera->getName())

Separately — renaming the parameter from invocation to cameraName is a real semantic claim about what Ogre passes here, and it silently decides whether CEGUI ever gets drawn. Worth a comment naming the Ogre version this depends on, since the signature itself doesn't say.

[Upabjojr]

The braces got reflowed here. As written:

pass lighting
{
    texture_unit
    {
        texture T2HammerGoodNormal.png
        rtshader_system
        {
            normal_map }   <- closes rtshader_system
        }                  <- closes texture_unit
    }                      <- closes pass lighting

It's balanced, so Ogre will parse it, but the closing brace for pass lighting now looks like it belongs to texture_unit. Compare Anvil.material in this same PR, which came out correctly.

Also worth spelling the space out as normal_map tangent_space — the pre-conversion line was lighting_stage normal_map T2HammerGoodNormal.png with no space argument, so tangent space was the implicit default, and every other converted material in this PR states its space explicitly.

Same shape in T2ShieldEvil, T2ShieldGood, T2SwordGood, T3HammerGood, T3ShieldEvil, T3ShieldGood.

[Upabjojr]

This looks like instrumentation from chasing the layout bugs rather than something to ship — it walks the entire widget tree and writes a line per widget straight to std::cerr (not through LogManager) every time the settings window is opened.

[Upabjojr]

Two things about this helper, beyond it being a workaround:

It rewrites the area as pure pixel offsets (UDim(0.0f, newLeft) etc.), discarding the scale components. After this runs the window no longer tracks display resizes at all — it's pinned to whatever the resolution was at construction time.

And the whole scaling block runs once, in the constructor. Since this is the window you change resolution from, applying a new resolution leaves the settings window scaled for the old one until restart.

Hooking this to a display-size-changed event and recomputing would address both.

[Upabjojr]

Vendoring Ogre's own RTShaderLib into the tree is worth a second look.

resources.cfg.in now lists both @RTSHADER_DIR@ (Ogre's copy) and the in-tree materials/RTShaderLib, so which of the two Ogre picks depends on resource group ordering — and this copy will drift from whatever Ogre version is actually installed. It also depends on the OgreUnifiedShader.h macros (f32vec2, f32vec3, mtxFromCols, mul, vec3_splat), which have to match that installed version.

If the reason these were added is that the RTShaderLib path wasn't being found, the resources.cfg.in change in this same PR already fixes that, and these two files could be dropped.

(Missing trailing newline on both, incidentally.)

[slapin]

It was a quick way to make Ogre RTSS work. I did not think too much about it. Needs to be tested separately. As it is internal shader library I guess that is correct thing to do.

[Upabjojr]

[Graphics] is now declared twice, with [OgreInternal] in between, and @OGRE_MEDIA_DIR@/Main is listed under both groups. Ogre's config parser will merge the two [Graphics] blocks so it works, but it reads as an accident.

The six hardcoded @CMAKE_INSTALL_PREFIX@/share/OGRE/Media/RTShaderLib* lines above are also redundant now that @RTSHADER_DIR@ is expanded — RTSHADER_DIR is set to ${OGRE_MEDIA_DIR}/RTShaderLib in CMakeLists.txt:530, pointing at the same place but resolved properly instead of guessed from the install prefix.

[slapin]

Fixed that with followup commit as latest Ogre update showed the problem.

[Upabjojr]

Good consolidation — this was four copies of the same block. Three small things:

Take the mesh by const Ogre::MeshPtr& rather than by value; each call currently copies a shared pointer (atomic refcount) for no reason.

A null check would help: getByName() returns a null MeshPtr when the mesh isn't in the group, and several call sites pass its result straight in without checking, so a missing mesh crashes here instead of logging.

And the five statements immediately following the new calls (lines 607, 996, 1127, 1335, 1442) lost their indentation and sit in column 0.

[slapin]

Please provide suggested change.

[Upabjojr]

Both branches of this #if are now identical:

#if defined(OGRE_VERSION) && OGRE_VERSION < 0x10A00
    if (requestedMaterial)
#else
    if (requestedMaterial)
#endif

Since MaterialPtr::isNull() is gone in the versions this PR targets, the conditional has no purpose left — it should go the way MovableTextOverlay.cpp handled the same situation in this PR, which deletes the #if outright. Same pattern at lines 2341 and 2448.

[Upabjojr]

#include <fstream> is already there three lines further down, so this one is a duplicate and can just be dropped. (ConfigManager.cpp has the same thing.)

More generally, the new includes across renderscene/ and creaturemood/ are placed above each file's own header. Putting the file's own header first is what proves it's self-contained; an include above it hides a missing include in the header.

[Upabjojr]

Opened the fix branch as a PR against this branch so it stacks cleanly rather than duplicating your work: slapin#1 (Upabjojr:ogre-v14.6-v3-review-fixes → ogre-v14.6-v3).

It covers the six "should fix" items from the review above and nothing else — the five discussion points are left untouched for you to decide on. Not compile-verified, as noted.

Happy to retarget it at tomluchowski:shaders-improvement instead if @tomluchowski would rather take it that way.

[Upabjojr]

Went back and checked my review against the Ogre source rather than leaving it at "looks like" — cloned OGRECave/ogre master (2ebfcfd, 2026-07-29; note there is no v14.6.0 tag yet, latest release tag is v14.5.2). Results, including one correction to my own PR:

Confirmed — renderQueueStarted is right. OgreRenderQueueListener.h:80 declares renderQueueStarted(uint8 queueGroupId, const String& cameraName, bool&) and OgreSceneManager.cpp:1311 calls fireRenderQueueStarted(qId, mCameraInProgress->getName()). Your rename matches upstream exactly. The null-guard is still worth taking, but the semantics were correct.

Confirmed — the mesh re-serialisation is optional. OgreMeshSerializer.cpp registers [MeshSerializer_v1.8] before the if(!mSupportLegacyFormats) return; early-out, so v1.8 is supported unconditionally, not as a legacy opt-in. Reinforces splitting those 194 files out.

Upgraded — the two vendored .glsl files are unreachable, not just a drift risk. Ogre master ships both at Media/RTShaderLib/SGXLib_NormalMap.glsl and Media/RTShaderLib/RTSLib_Colour.glsl, so they are already on the path via @RTSHADER_DIR@. Meanwhile materials/RTShaderLib/GLSL/ appears in no resources.cfg group and has no install rule, so the copies this PR adds are never loaded by anything. They can just be deleted.

Correction to my own fix PR. I had moved @RTSHADER_DIR@ into [Graphics]. Ogre's own CMake/Templates/resources.cfg.in puts both Main and RTShaderLib under [OgreInternal], which keeps the RTSS shader library in the same group as the Main headers it includes. Fixed in cc02d00.

While confirming that, I also verified the path expansion holds: OGREConfig.cmake.in:26 does set_and_check(OGRE_MEDIA_DIR "@PACKAGE_OGRE_MEDIA_PATH@"), and CMakeLists.txt:527 uses find_package(OGRE REQUIRED CONFIG), so @OGRE_MEDIA_DIR@ and @RTSHADER_DIR@ both resolve. The share/OGRE/Media/RTShaderLib/{GLSL,HLSL,HLSL_Cg,materials} paths I dropped do not exist in Ogre 14 at all — RTShaderLib is flat now.

New, and not something I fixed: Panels_Diffuse.png looks like it is missing at runtime. RTShaderSystem.material references it on lines 19 and 58, and RTSS/PerPixel_SinglePass is the base for Bed.material and Cannonball.material. But that texture lives in Ogre's Samples/Media/materials/textures/, which is only installed under OGRE_INSTALL_SAMPLES — it is not in a stock Ogre install (I checked my 1.12 packages: nothing). This PR vendors Panels_Normal_Tangent.png into materials/textures/, which fixes the same problem for NormalMapping_MultiPass, but leaves Panels_Diffuse.png dangling.

I have not added it — pulling a binary out of Ogre's sample media into this tree is your call, and the sample media licensing is not obviously the same as Ogre core's MIT. Flagging it because it looks like half of a fix you already started.

Still not compile-verified — no Ogre 14 packages exist for this distro, so a real build means building Ogre 14 and the CEGUI fork from source. Everything above is read from upstream source with file and line references so you can check it quickly.

[Upabjojr]

Built it. Ogre 14.6.0 (OGRECave/ogre master 2ebfcfd) and the CEGUI fork (tomluchowski/cegui#1, c2e8306) from source, then both this PR head and my fix branch against them, and ran the game. Two of my review findings were wrong and I have reverted them.

The port builds and runs

ff63881 compiles clean against Ogre 14.6 + the CEGUI fork and reaches the main menu. Confirmed working. Two build notes, neither caused by this PR:

• -Werror stops the build on GCC 13 via three pre-existing warnings, in files this PR does not touch. -DOD_TREAT_WARNINGS_AS_ERRORS=OFF gets past it. One is a genuine latent bug: Tile.h:262, inline bool setEverVisible(bool s) never returns — reading its result is undefined behaviour.
• Ogre's bundled Bullet component exports a non-existent include dir and breaks CEGUI's configure; -DOGRE_BUILD_COMPONENT_BULLET=OFF avoids it.

Correction 1 — you were right to delete ReflMetal.material

I asked you to restore it. That was wrong, and restoring it makes things actively worse.

ReflMetal.vert/.frag do not compile against Ogre 14 at all. They include FFPLib_Texturing.glsl, which calls the ENABLE_LINEAR_COLOUR macro that only RTSLib_Colour.glsl defines — which is presumably exactly why you vendored that file. But adding the include only exposes the next layer: FFP_Transform has a different signature now, and SGX_Light_Point_DiffuseSpecular no longer exists. These shaders need a real port, not a patch.

Meanwhile the cost of deleting it is nil: Roundshield.material and Wyvern.material exist in their own right, and Ogre logs nothing about the missing material — it just falls back silently. Restoring it traded that silent fallback for two hard shader compile errors. Reverted in a435624.

What actually remains is only the orphans: shaders/ReflMetal.vert, shaders/ReflMetal.frag, materials/textures/EnvmapMetal.png, and the now-unreachable vendored RTSLib_Colour.glsl. Worth deleting, but that is tidying, not a bug.

Correction 2 — the duplicated resources.cfg entries were load-bearing

I called the repeated [Graphics] / @OGRE_MEDIA_DIR@/Main an accident and folded it away. It is not an accident.

Your hand-written shaders live in the Graphics group and #include <OgreUnifiedShader.h> plus the RTShaderLib sources. Ogre resolves those includes within the same resource group, so Media/Main genuinely must appear under [Graphics] as well as [OgreInternal]. Removing it cost five shader programs:

Program 'myReflMetalVertexShader' is not supported: Cannot locate resource OgreUnifiedShader.h in resource group Graphics.
Program 'myDirtInstancedTileVertexShader' ... same
Program 'myFogVertexShader' / 'myCloudVertexShader2'  ... same

And the symmetric trap, which I walked straight into while fixing that: RTShaderLib must appear only under [Graphics]. Listing it in both groups makes RTSSamplers.material parse twice, and Ogre throws InvalidParametersException: Sampler 'Ogre/ShadowSampler' already exists during startup — the game dies before the menu. I have documented both constraints in the file so nobody tidies them away again.

The part that does still stand: the six @CMAKE_INSTALL_PREFIX@/share/OGRE/Media/RTShaderLib* paths are dead. They point into our install prefix rather than Ogre's, and the GLSL/HLSL/HLSL_Cg/materials subdirectories no longer exist now that RTShaderLib is flat.

Confirmed — the seven T2*/T3* materials are a real bug, not cosmetic

I under-called this one. I said it was brace-balanced so Ogre would parse it. It does not:

Error: ScriptCompiler - invalid parameters in T2HammerGood.material(18): missing property value

...and the same for T2ShieldEvil, T2ShieldGood, T2SwordGood, T3HammerGood, T3ShieldEvil, T3ShieldGood. Bare normal_map with no space argument is rejected; it needs normal_map tangent_space. These seven normal maps are silently not being applied on your branch today.

Net result

Diffing the Ogre log of my branch against this PR head, after the corrections:

• Regressions introduced: none.
• Errors fixed: 7 — all seven T2*/T3* material failures above.

Startup error count goes 27 → 20. The remaining 20 are pre-existing and outside this PR's scope — mostly normalise_normals no longer being a recognised token, hitting MysteryBox, TrollRock, Boulder, SmallSpider, KnightStatue, KnightCoffin, Spiketrap, Skull_Monster, AdventurerBed and others. Those materials are still unported.

Everything in the earlier reviews other than the two corrections above stands — in particular the uninitialised mActualPort and the null getActiveCamera() dereference, which are real regardless of what the log says.

[Upabjojr]

Chased down the missing sliders in OPTIONS -> AUDIO / GAMEPLAY. Reproduced it, found the cause, and fixed it — pushed as 5fef244 on the review-fixes branch.

Cause

Both sliders carry this in gui/WindowSettings.layout:

<Property name="AutoRenderingSurface" value="True" />

That asks CEGUI to render the widget subtree into its own RenderingSurface. The Ogre renderer in the CEGUI fork never composites those nested surfaces, so the slider draws nothing at all.

Worth correcting one detail in the report: it is not just the thumb that goes missing — the entire slider does, track included. It only looks like the thumb because the Music: 100% / Ambient Light: +184% label above it is a separate widget and keeps rendering fine.

The widget is not broken in any other sense. Dumping the tree at runtime shows it alive, visible and correctly positioned the whole time:

CEGUI window: MusicSlider type: OD/HorizontalSlider visible: yes
  pos: [690,461] size: [443,20] area: {{0,48},{0,100.5},{0,490.5},{0,120}}
  CEGUI window: __auto_thumb__ type: OD/HorizontalSliderThumb visible: yes
    pos: [1122,461] size: [11,20] area: {{0.975169,0},{0,0},{0.975169,11},{0,20}}

Thumb at 0.975 of the track, which is right for 100% volume. Layout is fine; it simply never reaches the screen. That is also why it "gets lost in transition" with no error anywhere — CEGUI logs nothing, because as far as it is concerned everything worked.

Fix

Drop the property. False is the CEGUI default, so the two lines just go away. Confirmed by screenshotting both tabs with it on and off, against Ogre 14.6.0 + the CEGUI fork built from source: with it on, label only; with it off, track and thumb both render, thumb at the far right on Audio (100%) and mid-track on Gameplay (184/250). And yes — the thumb really is a tiny X-ish bitmap, so that part of the description was spot on.

Two things worth flagging

This is not your bug. AutoRenderingSurface predates the port — the PR never touches WindowSettings.layout. It happened to work with the CEGUI and Ogre the game used before, and the port surfaced it. So it is a pre-existing latent issue, not a regression you introduced.

The underlying CEGUI bug is still there. Removing the property fixes OpenDungeons because nothing else in gui/ sets it — I grepped, these two sliders were the only users, which is exactly why only AUDIO and GAMEPLAY are affected. But nested auto rendering surfaces remain broken in the fork's Ogre renderer, and anything that turns the property on later will hit the same silent nothing. Might be worth a note on tomluchowski/cegui#1, since Disabled the scissors test and implemented draw() functions in that PR are both in the same area.

[slapin]

I rebased the patches to the latest shaders-improvement branch. Will look into remaining things later.

[slapin]

@Upabjojr Thanks a lot for review and PR! Could you please check which things still stand and I will add TODO-style summary to track things. There are still some UI problems I observe on YES/NO dialogues where buttons are displayed above text, but I am not very good with CEGUI layouts (not good at all I would say). I have very little time these days, but would like to see this going somewhere.

[tomluchowski]

You guys really showed your heart for this project , lots of respect then ....
and yeah the game CEGUI windows are quite disorganised I would say....
( at least for 14.5, I will try now 14.6 -- that is current master of Ogre...)

[tomluchowski]

Hmm 14.5.2 works as it works , but with the newest version of ogre, from master branch gives : "An exception has occurred: InvalidParametersException: The shared parameter set 'OgreFroxels' already exists! in GpuProgramManager::createSharedParameters at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreGpuProgramManager.cpp " Froxels ? are they cousins of Pixels and Vortexes ?

[tomluchowski]

After puling the newest commits. it works even on master branch. But CEGUI window problems remains...

[tomluchowski]

[tomluchowski]

Hmm and it turns out the Wyvern needs the material ReflMetal badly ... :D

[slapin]

@Upabjojr @tomluchowski If anybody has time, please close threads which are considered done and summarize what is left to do in form of task list, i.e.

• item 1
• item 2

which would help to continue working on this without being overwhelmed.
The github helps a bit by marking the thread Outdated, just need to check that the change was applied in the PR.

[slapin]

Added RefMetal back but not in a nice way.

[tomluchowski]

Still the mechanism for ambient is this : when creature is being marked by mouse cursor or hand , a loop enters all materials

void RenderManager::rrIncreaseAmbient(Creature* creature)
{
    std::string entityName  = creature->getOgreNamePrefix() +  creature->getName();
    if(!mSceneManager->hasEntity(entityName))
    {
        OD_LOG_ERR("There is no entity=" + entityName);
        return ;
    }

    Ogre::Entity* ent = mSceneManager->getEntity(entityName);
    
    for (unsigned int i = 0; i < ent->getNumSubEntities(); ++i)
    {
        Ogre::SubEntity *tempSubEntity = ent->getSubEntity(i);
        std::string materialName =  tempSubEntity->getMaterialName();
        if(materialName.find("##_Brighter") != std::string::npos)
            continue;
        
        std::stringstream ss("");
        ss << tempSubEntity->getMaterialName();
        ss << "##_Brighter";
        OD_LOG_INF("searching for: " +  ss.str() );
        Ogre::MaterialPtr  myBrighter = Ogre::MaterialManager::getSingletonPtr()->getByName(ss.str(),"Graphics");
        if (!myBrighter)
        {
            OD_LOG_INF("couldn't find: " +  ss.str() );

            //myBrighter = Ogre::MaterialManager::getSingletonPtr()->create("myBrighter","Graphics");               
            myBrighter= Ogre::MaterialManager::getSingletonPtr()->getByName(materialName, "Graphics")->clone(ss.str(),"Graphics");
            OD_LOG_INF("cloning......");
            OD_LOG_INF(myBrighter->getName());
            OD_LOG_INF("the number of techniques  is " + Helper::toString(myBrighter->getNumTechniques()));
            OD_LOG_INF("the number of passes is " + Helper::toString(myBrighter->getTechnique(myBrighter->getNumTechniques() - 1)->getNumPasses()));
            for(int ii =0 ; ii < myBrighter->getTechnique(myBrighter->getNumTechniques() - 1)->getNumPasses(); ++ii)
            {
                myBrighter->getTechnique(myBrighter->getNumTechniques() - 1)->getPass(ii)->getFragmentProgramParameters()->setNamedConstant("ambient",Ogre::ColourValue(8.0,8.0,8.0));
                // cv = cv * 8.0;
                // myBrighter->getTechnique(myBrighter->getNumTechniques() - 1)->getPass(ii)->setAmbient(cv);
            }


        }
          
        tempSubEntity->setMaterial(myBrighter);
    } 
    

}

So reflMetal.material should have at least " param_named ambient float3 1.0 1.0 1.0 " line somewhere .... without that when you mark your Wyvern with cursor an exception is thrown:

Thread 1 "opendungeons-pl" hit Catchpoint 1 (exception thrown), 0x00007ffff64c9e71 in __cxa_throw () from /lib64/libstdc++.so.6
(gdb) bt
#0  0x00007ffff64c9e71 in __cxa_throw () from /lib64/libstdc++.so.6
#1  0x00007ffff70e072f in Ogre::ExceptionFactory::_throwException (code=code@entry=Ogre::Exception::ERR_INVALIDPARAMS, number=number@entry=2, 
    desc="Parameter called ambient does not exist. ", src="GpuProgramParameters::_findNamedConstantDefinition", 
    file=file@entry=0x7ffff739d948 "/home/tom/Downloads/ogre-14.6/OgreMain/src/OgreGpuProgramParams.cpp", line=line@entry=1347)
    at /home/tom/Downloads/ogre-14.6/OgreMain/include/OgreException.h:263
#2  0x00007ffff70e09c3 in Ogre::ExceptionFactory::throwException (code=code@entry=Ogre::Exception::ERR_INVALIDPARAMS, desc="Parameter called ambient does not exist. ", 
    src="GpuProgramParameters::_findNamedConstantDefinition", file=file@entry=0x7ffff739d948 "/home/tom/Downloads/ogre-14.6/OgreMain/src/OgreGpuProgramParams.cpp", line=line@entry=1347)
    at /home/tom/Downloads/ogre-14.6/OgreMain/include/OgreException.h:280
#3  0x00007ffff70e9da2 in Ogre::GpuProgramParameters::_findNamedConstantDefinition (this=this@entry=0x3254c0d0, name="ambient", throwExceptionIfNotFound=true)
    at /usr/include/c++/16/bits/basic_string.h:232
#4  0x00007ffff71a7f50 in Ogre::GpuProgramParameters::setNamedConstant (this=this@entry=0x3254c0d0, name="ambient", colour=...)
    at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreGpuProgramParams.cpp:2270
#5  0x0000000000676480 in RenderManager::rrIncreaseAmbient (this=<optimized out>, creature=creature@entry=0x13203310)
    at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/render/RenderManager.cpp:2217
#6  0x00000000004e014f in Creature::maxAmbient (this=this@entry=0x13203310) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/entities/Creature.cpp:3431
#7  0x00000000005d8651 in GameMode::mouseMoved (this=<optimized out>, arg=...) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/modes/GameMode.cpp:429
#8  0x00007ffff7d51d3d in OIS::LinuxMouse::capture() () from /lib64/libOIS.so.1.6.0
#9  0x0000000000619a44 in ModeManager::update (this=0x45c1190, evt=...) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/modes/ModeManager.cpp:162
#10 0x0000000000668194 in ODFrameListener::frameRenderingQueued (this=0x7fffffffb1b0, evt=...) at /usr/include/c++/16/bits/unique_ptr.h:192
#11 0x00007ffff72b0a55 in Ogre::Root::_fireFrameRenderingQueued (this=this@entry=0x7fffffffb3c0, evt=...) at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreRoot.cpp:655
#12 0x00007ffff72b7787 in Ogre::Root::_fireFrameRenderingQueued (this=this@entry=0x7fffffffb3c0) at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreRoot.cpp:705
#13 0x00007ffff72b77ae in Ogre::Root::_updateAllRenderTargets (this=this@entry=0x7fffffffb3c0) at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreRoot.cpp:1156
#14 0x00007ffff72b7860 in Ogre::Root::renderOneFrame (this=0x7fffffffb3c0) at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreRoot.cpp:789
#15 Ogre::Root::renderOneFrame (this=this@entry=0x7fffffffb3c0) at /home/tom/Downloads/ogre-14.6/OgreMain/src/OgreRoot.cpp:784
#16 0x00000000007481ed in ODApplication::startClient (this=<optimized out>) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/ODApplication.cpp:323
#17 0x000000000074905d in ODApplication::startGame (this=this@entry=0x7fffffffce60, options=...)
    at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/ODApplication.cpp:86
#18 0x000000000048d4ec in main (argc=<optimized out>, argv=<optimized out>) at /home/tom/Opendungeons_github/OpenDungeonstomluchowski/OpenDungeonsPlus/source/main.cpp:92

I will try my luck in the shaders alchemy then ...

EDIT : adding 'param_named ambient float3 1.0 1.0 1.0' does not change this material shader config ( ReflMaterial.material)

[tomluchowski]

Please try to mark the Wywern , - the Legacy Test Level -- down from the main base ( they leave somewhere there -- flying creatures in the shinning armors ... ;)

[slapin]

Fixed highlighting for creatures using ReflMaterial (Wyvern).

[slapin]

Well, for some reason I don't see much armor on the Wyvern either, but at least no crash. Need to debug this more...

[Upabjojr]

@tomluchowski F4 skill tree — reproduced and fixed: slapin#5. The window wasn't broken by the research code; it's a casualty of the titlebar fix. The layout sizes the window 610x392 and arranges the three skill columns for a client area that big — which is what the old skin's broken ClientWithTitleWithFrame (empty area = whole window) used to hand it. With the client area corrected to sit inside the frame and below the titlebar, the same window only offers 538x329, so the third column loses its right half and the fourth skill row is cut mid-icon — exactly your screenshot, which I reproduced at 1920x1200. The fix measures what the content actually needs (610x380 client; the frame is 36px a side plus a 27px titlebar) and sizes the window 690x450, which still fits the 800x600 design minimum. Verified in-game: all three columns show every skill with their progress bars, and the Auto Fill / Unselect All / Cancel / Apply bar sits clear below. Before/after screenshots are on the PR.

@slapin thanks for confirming — nothing in the log means the ReflMetal GLSL compiles and links clean on your driver, so the armor is being drawn invisible rather than rejected, which narrows it usefully. When you get a chance (no rush on the pre-port check), here's a two-minute bisection that would tell us exactly which half to chase — replace the last line of shaders/ReflMetal.frag:

    color = vec4(mix(lighting, reflection, 0.5), 1.0);

with

    color = vec4(1.0, 0.0, 0.0, 1.0);

• Red armor appears → the geometry and material binding are fine and the fragment math produces black/NaN on your driver (my prime suspect would then be the sphere-map divide R.xy / m when m approaches 0 — trivially guarded once confirmed).
• Still nothing → the submesh itself isn't being drawn on your setup (binding/culling/skinning path), and shader tweaks won't help — we'd look at the material assignment instead.

Together with the pre-port answer (did the armor ever show on that laptop before 14.x?) that should pin it down without me needing NVIDIA hardware.

[slapin]

Merged slapin#5
Rebased the PR.

[slapin]

Will look into ReflMaterial as I have time later.