ogrecave / ogre Goto Github PK

[reporter="nodrev", created="Sat, 24 Nov 2012 20:05:53 +0100"]

Original reporter: Nodrev

It's impossible using the existing API to set a textureUnitState's with a texture that is defined in a resource group that is not in the global pool (for example, if the resource group was created using "Ogre::ResourceGroupManager::getSingleton().createResourceGroup("notInGlobalPool", false);".
Adding an optional group parameter to "setTextureName" functions seem not too hard to do, and, in my opinion, did not break existing API.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=408

[reporter="Mingun", created="Wed, 8 May 2013 15:58:17 +0200"]

[reporter="spacegaier", created="Sat, 24 Nov 2012 19:54:16 +0100"]

Original reporter: rride

In a current version there is no possibility to set stencil ops, masks, values etc in material files, this feature is enabled only in compositor files, but stencil can be used not only in post-processing and stencil shadow-related effects.

Sometimes this feature be VERY useful, because it would help to avoid setting stencil values through RenderQueueListener class.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=370

[reporter="spacegaier", created="Sat, 24 Nov 2012 19:59:59 +0100"]

Original reporter: cyrfer

When trying to learn how to use OGRE's support for full screen windows, I had to debug waaay through the code to find that it was possible to pass the *monitor index**. I think this is an important option that should be documented. The documentation already has a great start, an extra table entry for all the options would be nice.

OGRE already looks for a miscParam to specify the monitor index (at least on Windows), so it should be trivial to add documentation for this feature. I debugged the OpenGL RenderSystem to find this information.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=395

[reporter="pstumpf", created="Fri, 8 Feb 2013 11:35:53 +0100"]

SampleBrowser crashes on startup on OpenBSD; gdb backtrace with debug symbols, crashes somewhere in PCZSceneManager due to a NULL dereference :

#0 0x0000118ad5126b95 in Ogre::PCZSceneNode::getHomeZone (this=0x0)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/PlugIns/PCZSceneManager/src/OgrePCZSceneNode.cpp:135
#1 0x0000118ad5112903 in Ogre::PCZSceneManager::_findVisibleObjects (
this=0x118ab2c3c000, cam=0x118ab4504800, visibleBounds=0x118abb49b828,
onlyShadowCasters=false)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/PlugIns/PCZSceneManager/src/OgrePCZSceneManager.cpp:1229
#2 0x0000118ac1639c64 in Ogre::SceneManager::_renderScene (
this=0x118ab2c3c000, camera=0x118ab4504800, vp=0x118abb49be00,
includeOverlays=true)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreSceneManager.cpp:1479
#3 0x0000118ad5114b1a in Ogre::PCZSceneManager::_renderScene (
this=0x118ab2c3c000, cam=0x118ab4504800, vp=0x118abb49be00,
includeOverlays=true)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/PlugIns/PCZSceneManager/src/OgrePCZSceneManager.cpp:488
#4 0x0000118ac126303f in Ogre::Camera::_renderScene (this=0x118ab4504800,
vp=0x118abb49be00, includeOverlays=true)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreCamera.cpp:427
#5 0x0000118ac179cf70 in Ogre::Viewport::update (this=0x118abb49be00)
--Type to continue, or q to quit--
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreViewport.cpp:224
#6 0x0000118ac15b1b94 in Ogre::RenderTarget::_updateViewport (
this=0x118abb4a0a00, viewport=0x118abb49be00, updateStatistics=true)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreRenderTarget.cpp:200
#7 0x0000118ac15b1c81 in Ogre::RenderTarget::_updateAutoUpdatedViewports (
this=0x118abb4a0a00, updateStatistics=true)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreRenderTarget.cpp:178
#8 0x0000118ac15af2ea in Ogre::RenderTarget::updateImpl (this=0x118abb4a0a00)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreRenderTarget.cpp:155
#9 0x0000118ac15aff38 in Ogre::RenderTarget::update (this=0x118abb4a0a00,
swap=true)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreRenderTarget.cpp:613
#10 0x00001188b051f05f in OgreBites::SdkTrayManager::windowUpdate (
this=0x118ab7581400) at SdkTrays.h:2816
#11 0x00001188b0532d99 in OgreBites::SdkTrayManager::resourceGroupScriptingStarted (this=0x118ab7581400, groupName=@0x118ab7c82810, scriptCount=93)
at SdkTrays.h:2824
#12 0x0000118ac15c5778 in Ogre::ResourceGroupManager::fireResourceGroupScripting--Type to continue, or q to quit--
Started (this=0x118ab98b1f00, groupName=@0x118ab7c82810, scriptCount=93)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreResourceGroupManager.cpp:1369
#13 0x0000118ac15d08a5 in Ogre::ResourceGroupManager::parseResourceGroupScripts
(this=0x118ab98b1f00, grp=0x118ab7c82800)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreResourceGroupManager.cpp:1053
#14 0x0000118ac15d13cc in Ogre::ResourceGroupManager::initialiseResourceGroup (
this=0x118ab98b1f00, name=@0x7f7ffffdbde0)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/OgreMain/src/OgreResourceGroupManager.cpp:120
#15 0x00001188b054d1c2 in OgreBites::SampleBrowser::loadResources (
this=0x7f7ffffdc010) at SampleBrowser.h:1127
#16 0x00001188b05516f8 in OgreBites::SampleBrowser::setup (this=0x7f7ffffdc010)
at SampleBrowser.h:1044
#17 0x00001188b0552460 in OgreBites::SampleContext::initApp (
this=0x7f7ffffdc010, initialSample=0x0) at SampleContext.h:273
#18 0x00001188b05541a9 in OgreBites::SampleContext::go (this=0x7f7ffffdc010,
initialSample=0x0) at SampleContext.h:325
#19 0x00001188b051c882 in main (argc=1, argv=0x7f7ffffdc250)
at /usr/ports/pobj/ogre_src_v1-8-1/ogre_src_v1-8-1/Samples/Browser/src/SampleBrowser.cpp:81

I can provide more info on demand.

[reporter="spacegaier", created="Sat, 24 Nov 2012 20:07:52 +0100"]

Original reporter: FuzzyBoots

Partially documented in forum topic http://www.ogre3d.org/forums/viewtopic.php?f=2&t=59825 [^]

When the OgreXMLConverter is reading in an XML Skeleton file, it assumes that the Bone IDs will go from 0 to N-1, storing them internally in an array indexed by the same. If, for example, the bone IDs are 1 to N, there will be a segmentation fault due to it trying to access a nonexistent record at index 0. Currently, the DTD spec marks the ID as required, but does not list the format needed (i.e. values should be from 0 to N-1).

My suggestion would be for the XML Converter to either support reading in arbitrary IDs that do not have to go from 0 to N-1, or to provide an error message if this sequence is not followed.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=421

[reporter="nodrev", created="Sat, 24 Nov 2012 20:30:59 +0100"]

Original reporter: narwhals

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=62139 [^]

PageProvider::unloadProceduralPage and PageProvider::unprepareProceduralPage are never called. To reproduce this, set up a paging scenario such as a paged terrain, then create a custom class that extends PageProvider and overrides the four functions with something simple such as a printf. You will notice that the load and prepare functions are called, but the unload and unprepare functions are not called at all. If you move in and out of range of the pages, you will notice them being loaded and unloaded multiple times, however only the load and prepare functions will be called.

This is quite a problem, as extending these events is the only safe way to determine when to unload resources when the page unloads. For example, I attempted to use this class to load and unload a collision mesh into a physics system whenever a terrain page is loaded or unloaded.

This bug is also present in 1.7

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=485

[reporter="knox31085", created="Sat, 25 May 2013 10:47:04 +0200"]

D3D11HLSLProgramm uses this function:

void D3D11HLSLProgram::createLowLevelImpl(void)

{

// Create a low-level program, give it the same name as us
mAssemblerProgram =GpuProgramPtr(dynamic_cast<GpuProgram*>(this));
}

HighLevelGPUProgramm uses this:
size_t HighLevelGpuProgram::calculateSize(void) const

{

size_t memSize = 0;
memSize += sizeof(bool);
if(!mAssemblerProgram.isNull())
memSize += mAssemblerProgram->calculateSize();

memSize += GpuProgram::calculateSize();

return memSize;
}

Together they are an infinite recursion...

Can somebody fix this and check it in?

Thanks

[reporter="nodrev", created="Mon, 25 Feb 2013 18:34:38 +0100"]

When compiled using TBB, Ogre's assume the initialization of the library. But in my case (and I think it's the case for anyone who uses Ogre & TBB), TBB is already initialized by the main application that olds Ogre. So there's a crash when Ogre tries to initialize TBB a second time.
This patch adds an entry to cmake, 'tbb_ext', to tell ogre to not initializing tbb.
There's a problem with this patch if TBB was not initialized with the default number of threads (the THREAD_CONCURRENCY define do not match), but to support this case more modifications to WorkQueue should be done (and maybe also add a "number of working threads" to Ogre's Root constructor to replace the THREAD_CONCURRENCY define).
Note that SampleBrowser had been modified to simulate external TBB initialization.

[reporter="lilin", created="Mon, 22 Apr 2013 15:21:47 +0200"]

When Using LARGEADDRESSAWARE linker flag (http://msdn.microsoft.com/fr-fr/library/wz223b1z(v=vs.80).aspx), and app exeeds 2Go of virtual memory, D3DXCompileShader fails to get constant table.

As described in MSDN D3DXCompileShader manual (http://msdn.microsoft.com/en-us/library/windows/desktop/bb172731(v=vs.85).aspx), We should use D3DXGetShaderConstantTableEx to get constant table.

example:
hr = D3DXGetShaderConstantTableEx((DWORD*)mMicroCode->GetBufferPointer(), D3DXCONSTTABLE_LARGEADDRESSAWARE, &pConstTable);

We should use this only in 32bit build, and with LARGEADDRESSAWARE linker flag.

[reporter="spacegaier", created="Sat, 24 Nov 2012 20:21:17 +0100"]

Original reporter: Jabberwocky

Crash, and one-line fix fully explained in this thread:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=35417&p=432714#p432714 [^]

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=457

[reporter="ldsw2112", created="Tue, 29 Jan 2013 12:13:18 +0100"]

The issue is described here : http://www.ogre3d.org/forums/viewtopic.php?f=5&t=52480&p=481752#p481752

Creating a texture TU_RENDERTARGET with no FSAA (==0) works fine, but if we use OpenGL with a FSAA value different from 0, the texture is frozen, the first update of the texture define the content of the texture.

Something prevent from using FSAA on texture2D with OpelGL. It's really annoying and make us to have ugly hack to prevent FSAA when we use Opel GL render system.

[reporter="spacegaier", created="Sun, 25 Nov 2012 00:48:24 +0100"]

Original reporter: fuzzybinary

In LinearSkinning::addIndexedPositionWeight there's the following code:

   //multiply position with world matrix and put into temporary param
   curFuncInvocation = OGRE_NEW FunctionInvocation(FFP_FUNC_TRANSFORM, FFP_VS_TRANSFORM, funcCounter++);
   curFuncInvocation->pushOperand(mParamInWorldMatrices, Operand::OPS_IN);
   curFuncInvocation->pushOperand(mParamInIndices, Operand::OPS_IN, indexMask, 1);
   curFuncInvocation->pushOperand(mParamInPosition, Operand::OPS_IN);
   curFuncInvocation->pushOperand(mParamTempFloat4, Operand::OPS_OUT, outputMask);
   vsMain->addAtomInstance(curFuncInvocation);

I think this is trying to do this operation of linear skinning

FFP_Transform(world_matrix_array[BlendInticies.x], position, TempFloat4);

But it doesn't seem to be reading the index correctly (it's looking for an FFP_Transform with 4 parameters instead). This is apparently also true in addIndexedNormalRelatedWeight.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=515

[reporter="spacegaier", created="Sun, 25 Nov 2012 00:51:58 +0100"]

Original reporter: jycorbel

Reading bounds (MeshSerializerImpl::readBoundsInfo) from mesh file causes bounds to be readjust with padding factor (MeshManager::getBoundsPaddingFactor()) although padding has also been saved into the .mesh file.

The problem with this implementation being that we can have a continous growth factor on mesh bounds by having a padding factor not null (default is 0.01%) and just opening/exporting the mesh (each time bounds grows by 0.01).

Consequences of that is if a mesh is saved in a Ogre instance with a padding factor of 0.2% and open in a Ogre app having a padding factor of 0.1%, the real padding apply is 0.32% !

It seems the best way to fix this issue is to call _setBounds with second parameters to false :

// use padding from file, do .
AxisAlignedBox box(min, max);
pMesh->_setBounds(box, false /pad/);

But this solution is questionable (see Consequences as good use case).
The other way to fix this behaviour is to add padding when loading mesh but remove padding when serialize it to file :
This require to keep padding factor set on bounds or a bool set by _setBounds 'pad' param. => This implies MeshManager::getBoundsPaddingFactor() is constant during all time from ogre engine initialization to shutting down.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=535

[reporter="spacegaier", created="Sat, 24 Nov 2012 20:08:54 +0100"]

Original reporter: Sauce

The void* argument in Ogre::Window::getCustomAttribute() should be replaced with an Ogre::Any return value to promote type-safety.

Whilst not entirely trivial to implement (each platform uses a different implementation), the changes shouldn't affect plugin writers in any significant way as custom render systems aren't common.

End users will only have to add 1 or 2 lines of code to handle the changes to the interface, to handle casting to the appropriate type.

Current usage:
size_t hWnd = 0;
m_pWindow->getCustomAttribute("WINDOW", &hWnd);

Proposed usage:
size_t hWnd = Ogre::any_cast(m_pWindow->GetCustomAttribute("WINDOW"));

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=422

[reporter="vekoon", created="Sun, 27 Jan 2013 22:10:47 +0100"]

The mAttributes member variable is private at the moment.

Either exposing it or adding a getter for it under the protected methods would allow subclasses to iterate through the values, instead of forcefully accessing them by name.

[reporter="thesheeep", created="Mon, 10 Dec 2012 09:33:59 +0100"]

I only noticed this with the Bump Mapping sample, other shadow samples work correctly. Also, this only happens with OpenGL.

[reporter="Ogre.Transporter", created="Fri, 14 Jun 2013 22:12:38 +0200"]

It would be nice to hide the headers of threading dependencies. Have a look what happend after including Ogre.h:

Ogre.h -> OgrePrerequisites.h -> OgrePlatform.h -> OgreConfig.h -> OgreBuildSettings.h
Code: Select all#define OGRE_THREAD_SUPPORT 2

#define OGRE_THREAD_PROVIDER 1

Ogre.h -> OgrePrerequisites.h -> Threading/OgreThreadDefines.h -> Threading/OgreThreadDefinesBoost.h
Ogre.h -> OgrePrerequisites.h -> OgreStdHeaders.h -> Threading/OgreThreadHeaders.h -> Threading/OgreThreadHeadersBoost.h -> BOOST

That means you have to add boost to all Ogre projects. Even if you use Ogre as shared libraries, you also have to add boost. It would be helpful to include the threading libraries only in cpp code or headers which only used for building Ogre to avoid including any external library using the SDK. Using windows is also adding more issues because of boost auto linking, which is enabled by default.

Thread: http://www.ogre3d.org/forums/viewtopic.php?f=3&t=78190

Edit: It looks like that TBB has the same problem (https://bitbucket.org/transporter/ogre-procedural/issues/147/boost-and-tbb-headers-and-libraries-not)

[reporter="robert82h", created="Mon, 1 Jul 2013 11:18:41 +0200"]

When deleting Ogre::Root on Android, an uncaught exception thrown from Ogre::EGLContext::_destroyInternalResources() via Ogre::EGLContext::~EGLContext() crashes the application.

I/OGRE    ( 4790): DefaultWorkQueue('Root') shutting down on thread 5ca3ead8.
I/OGRE    ( 4790): DefaultWorkQueue('Root')::WorkerFunc - thread 5c419fa0 stopped.
I/OGRE    ( 4790): DefaultWorkQueue('Root')::WorkerFunc - thread 5c3d53f0 stopped.
I/OGRE    ( 4790): DefaultWorkQueue('Root')::WorkerFunc - thread 40164510 stopped.
D/dalvikvm( 4790): threadid=13: thread exiting, not yet detached (count=0)
I/OGRE    ( 4790): DefaultWorkQueue('Root')::WorkerFunc - thread 5c413f90 stopped.
D/dalvikvm( 4790): threadid=14: thread exiting, not yet detached (count=0)
I/OGRE    ( 4790): *-*-* OGRE Shutdown
I/OGRE    ( 4790): Unregistering ResourceManager for type Compositor
I/OGRE    ( 4790): Unregistering ResourceManager for type Skeleton
I/OGRE    ( 4790): Unregistering ResourceManager for type Mesh
I/OGRE    ( 4790): Unregistering ResourceManager for type HighLevelGpuProgram
I/OGRE    ( 4790): Unregistering ResourceManager for type GpuProgram
I/OGRE    ( 4790): Unregistering ResourceManager for type Texture
E/libEGL  ( 4790): eglDestroyContext:587 error 3006 (EGL_BAD_CONTEXT)
I/OGRE    ( 4790): EGL error 0x3006 in virtual void Ogre::EGLContext::_destroyInternalResources() at line 87
E/OGRE    ( 4790): OGRE EXCEPTION(7:InternalErrorException): EGL error 0x3006 in virtual void Ogre::EGLContext::_destroyInternalResources() at line 87
E/OGRE    ( 4790):  in virtual void Ogre::EGLContext::_destroyInternalResources() at /home/robert/work.new/3rdparty/ogre/RenderSystems/GLES2/src/EGL/OgreEGLContext.cpp (line 87)
F/libc    ( 4790): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 4803 (GLThread)
I/DEBUG   (21927): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Throwing exceptions in destructors is a bad idea as 1) you cannot really do anything useful in reaction to the exception (the object is gone when you get to catch the exception) and 2) with global objects or shared pointers you cannot catch the exception anyway.

I propose the following patch which fixes this issue for me.

[reporter="xavyiy", created="Fri, 22 Feb 2013 16:56:51 +0100"]

This is a big problem since in the Ogre3d DX9 RS you need to destroy the dummy render window before switching to fullscreen any other existent render window (otherwise you get a swap chain expection). (More info: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=58142#p392888 )

The problem seems to be here since Ogre 1.8, I'm sure it worked in 1.7...

I've attached a .cpp which shows the problem, comment the line #136, mRoot->destroyRenderTarget(mWindow), in order to see how it should look!

Hope it's going to be an easy bug to catch!

[reporter="eventhorizon", created="Mon, 28 Jan 2013 22:29:14 +0100"]

I'm currently working with OGRE's font rendering system (finishing an app port, from the Crystal Space engine over to OGRE/Bullet), and am noticing that all italic font glyphs are being clipped on the right and leak into the previous glyph on the left. I've been debugging OgreFont.cpp and checking it against a dumped glyph map image, and getGlyphTexCoords() is returning texture coordinates that are off (U1 starts near the end of the previous glyph, and U2 stops before the end of the current glyph). I'm attaching an image of the same font rendered in both

OGRE

and CS

so you can see the problem. In the OGRE image, you can see the right edge of the 'B' glyph leaking into the image, while the right edge of the 'C' glyph is cut off. So far it seems to happen in all italic fonts - don't know about others.

The new getCharacterSpacer feature doesn't solve this issue when adjusting, and only affects the leaked glyph on the left side (no change with the right-side clipping). This happens in all platforms, but the pics were taken using OGRE 1.8.1 on Linux x64 (Debian Squeeze). This seems to happen on all italic fonts, but I can attach the testing one if you need.

[reporter="nodrev", created="Wed, 3 Apr 2013 15:46:22 +0200"]

New auto param, named ACT_SURFACE_ALPHA_REJECTION_VALUE (surface_alpha_rejection_value in programs scripts), that bind the alpha rejection value stored in the material pass.
It does not give alpha rejection value as in Ogre::Pass::getAlphaRejectionValue(), but convert it instead to a [0.0; 1.0] floating point value (255.0f / Ogre::Pass::getAlphaRejectionValue()).
Very usefull to handle alpha rejection in shadows, compositor shaders, or deferred rendering.

[reporter="spacegaier", created="Sat, 24 Nov 2012 20:05:03 +0100"]

Original reporter: spacegaier

I have not really checked it in detail, but the page was last modified in February 2009, so it is definetly outdated. One needs to go through the changelogs and add the most important bits.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=407

[reporter="bstone", created="Sat, 8 Dec 2012 17:48:49 +0100"]

Original author: bstone

Lookls like ps_1_1 shaders compiled from Cg expect the "float" uniforms to be in the .w component of the float4 that is actually passed to the shader. Ogre puts the values in the .x component which is what ps_2_0 seems to be expecting. I don't know if that's documented anywhere as specific to ps_1_1 but a quick workaround would be to set the "float" value to both .x and .w components of the float4 that is sent to the shader as representing the "float" uniform. That will make the GPU parameter initialization code work with both ps_1_1 and ps_2_0 as expected.

Related forum thread: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=72807&p=470960#p470930

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=569

[reporter="spacegaier", created="Sat, 24 Nov 2012 19:56:06 +0100"]

Original reporter: rride

Sometimes it may be advantageous not to store lot's of images on disk but to pack everything into one big image(8k x 8k) and load only a small part of it. For example, this feature can be useful for storing land textures.

So it would be nice to have Ogre::Image::load( const Ogre::String& file, const Ogre::TRect& rect ) method.

NOTE: See notes in Mantis Ticket!

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=371

[reporter="xavyiy", created="Thu, 21 Feb 2013 00:05:34 +0100"]
http://ogre3d.org/forums/viewtopic.php?f=22&t=76291

[reporter="spacegaier", created="Sun, 25 Nov 2012 00:45:24 +0100"]

Original reporter: fedyakin

1) Non-shadow casting children of a shadow casting entity will be queued for rendering during the shadow pass.
2) Shadow casting children of a non shadow casting entity will not cast shadows.

See forum thread http://www.ogre3d.org/forums/viewtopic.php?f=2&t=69233 for a detailed explanation.

The reason this happens is that Entity::_updateRenderQueue always adds all of its visible children to the render queue. However, when this is called from RenderQueue::processVisibleObject with onlyShadowCasters=true, the entity has no way of knowing it shouldn't add non-shadow casters children.

[reporter="areay", created="Sat, 6 Apr 2013 12:42:44 +0200"]

When using two monitors in Linux an Ogre3D application window that is in full-screen mode, at a resolution lower than native, causes the unused monitor to black out and require re-enabling through the Linux control panel. When the application is windowed or full-screen AND at the monitor's native resolution then there is no problem.

Discussion here:
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=76967

[reporter="JordanWeber", created="Wed, 27 Mar 2013 00:46:36 +0100"]

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=59531&p=485920#p485920

When loading a mesh through mesh serializer, the LOD strategies are ordered incorrectly, and gets stuck on the highest level when rendering (never switching to lower details).

[reporter="netzlab", created="Sun, 21 Jul 2013 16:44:09 +0200"]

I need an unregister method for the CumstomCompositionPass-Map. At the moment there are only register and get, but no unregister. That issue crashs my Application. The Fix is very simple:

void CompositorManager::unregisterCustomCompositionPass(const String& name)
{
CustomCompositionPassMap::iterator it = mCustomCompositionPasses.find(name);
if (it == mCustomCompositionPasses.end())

{
    OGRE_EXCEPT(Exception::ERR_ITEM_NOT_FOUND,
        "Custom composition pass '" + name + "' not registered.",
        "CompositorManager::unregisterCustomCompositionPass");
}

mCustomCompositionPasses.erase(it);
}

[reporter="spacegaier", created="Sat, 24 Nov 2012 19:59:13 +0100"]

Original reporter: al2950

There a several threaded tasks that I need to make sure are completed before the next frame is rendered. So would it be a good idea to add this idea to the default work queue? Please see discussion in Papercuts forum.

http://www.ogre3d.org/forums/viewtopic.php?f=22&t=62409

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=386

[reporter="Oogst", created="Mon, 29 Jul 2013 22:43:15 +0200"]

New Ogre users are bound to get their information from tutorials and from the Manual, since the API is way too big and complex to start with. The Manual would be the sensible place to start, but it only contains script languages and the concepts behind Ogre, and hardly any information on how to actually program any of those things.

To solve this, I think articles in the Manual should link to Tutorials (for example from the Wiki) and Samples that show how to actually use what you just read about.

This was discussed in this topic on the forum already: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=78545

[reporter="dermont", created="Sat, 6 Apr 2013 13:00:31 +0200"]

[reporter="dsefton", created="Tue, 19 Mar 2013 08:50:50 +0100"]

Description
I need the following shaders converted to an RTSS extension. As they are, the material doesn't benefit from the RTSS's lighting and performance benefits. I have attached GLSLES and GLSL variants and a 16 bit colour mask image with 3 changeable colours. It should work on both OpenGL and GLES 2.0.

Note
I am willing to pay anyone who implements this in good time. If you would like to take on the task, please let me know beforehand.

ColourMapVS.glsles

#version 100
precision highp float;

precision highp int;

precision lowp sampler2D;

precision lowp samplerCube;
uniform mat4 worldViewProjMatrix;
attribute vec4 vertex;

attribute vec2 uv0;
varying vec2 DiffuseTexCoord;
void main(void)

{

DiffuseTexCoord = uv0;

gl_Position = worldViewProjMatrix * vertex;

}

ColourMapFS.glsles

#version 100
precision highp float;

precision highp int;

precision lowp sampler2D;

precision lowp samplerCube;
varying vec2 DiffuseTexCoord;
uniform vec4 Color1, Color2, Color3, Color4;

uniform sampler2D Texture, Mask;
void main(void)

{

vec4 diffuseColor = texture2D(Texture, DiffuseTexCoord);

vec4 maskColor = texture2D(Mask, DiffuseTexCoord);
vec4 colorMix = mix(diffuseColor, Color1, maskColor.r);
colorMix = mix(colorMix, Color2, maskColor.g);
colorMix = mix(colorMix, Color3, maskColor.b);
colorMix = mix(colorMix, Color4, maskColor.a);

colorMix.a = diffuseColor.a;

gl_FragColor = colorMix;

}

#version 120
uniform mat4 worldViewProjMatrix;
attribute vec4 vertex;

attribute vec2 uv0;
varying vec2 DiffuseTexCoord;
void main(void)

{

DiffuseTexCoord = uv0;

gl_Position = worldViewProjMatrix * vertex;

}

#version 120
varying vec2 DiffuseTexCoord;
uniform vec4 Color1, Color2, Color3, Color4;

uniform sampler2D Texture, Mask;
void main(void)

{

vec4 diffuseColor = texture2D(Texture, DiffuseTexCoord);

vec4 maskColor = texture2D(Mask, DiffuseTexCoord);
vec4 colorMix = mix(diffuseColor, Color1, maskColor.r);
colorMix = mix(colorMix, Color2, maskColor.g);
colorMix = mix(colorMix, Color3, maskColor.b);
colorMix = mix(colorMix, Color4, maskColor.a);

colorMix.a = diffuseColor.a;

gl_FragColor = colorMix;

}

// GLSL Vertex shader definition
vertex_program ColourMap_VS_GLSL glsl
{
    source ColourMapVS.glsl
    default_params
    {
        param_named_auto worldViewProjMatrix worldviewproj_matrix
    }
}
// GLSL Pixel shader definition

fragment_program ColourMap_PS_GLSL glsl

{

source ColourMapFS.glsl

}
// GLSLES Vertex shader definition

vertex_program ColourMap_VS_GLSLES glsles

{

source ColourMapVS.glsles

profiles glsles

default_params

{

param_named_auto worldViewProjMatrix worldviewproj_matrix

}

}
// GLSLES Pixel shader definition

fragment_program ColourMap_PS_GLSLES glsles

{

source ColourMapFS.glsles

profiles glsles

}

material ColourMaskMaterialGLSL
{
    technique
    {
        pass
        {
            ambient 1 1 1
            diffuse 0 0 0 
            specular 0 0 0 0
        vertex_program_ref ColourMap_VS_GLSL
        {
        }

        fragment_program_ref ColourMap_PS_GLSL
        {
    param_named Color1 float4 0 1 0 1
    param_named Color2 float4 1 0 0 1
    param_named Color3 float4 0 0 1 1
    param_named Color4 float4 0 1 1 1
    param_named Texture <span class="code-object">int</span> 0
    param_named Mask <span class="code-object">int</span> 1
        }

        <span class="code-comment">// base texture

         texture_unit

{

// Replace with any texture

             texture basetex.png

}

// colormask

         texture_unit

{

texture colourmask_16.tga

}

}

}

}

[reporter="spacegaier", created="Sat, 24 Nov 2012 20:28:32 +0100"]

Original reporter: Femidko

All textures (rendered with compositor) are drawn with poorly appreciable distortions in the right bottom corner. I have laid out an initial code for a bright example of these distortions in this post:
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=67439

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=476

[reporter="dsefton", created="Sat, 8 Dec 2012 18:03:46 +0100"]

Billboard chains no longer face the camera after the following patch was applied in revision 42bd131:

http://www.ogre3d.org/mantis/view.php?id=403

https://bitbucket.org/sinbad/ogre/diff/OgreMain/src/OgreBillboardChain.cpp?diff2=42bd1316bcb4&at=v1-8

If I revert these changes, the billboard chain faces the camera as expected.

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=591

[reporter="spacegaier", created="Sat, 24 Nov 2012 19:52:36 +0100"]

Original reporter: myint

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=60939

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=360

[reporter="philiplb", created="Fri, 21 Dec 2012 13:00:21 +0100"]

It would be great, if the math library of Ogre could invert a matrix of any size. When the matrix is underdetermined, it should return a pseudoinverse like in http://www-evasion.imag.fr/people/Franck.Hetroy/Teaching/Geo3D/Articles/lindstrom2000.pdf .
Then I could implement having sharp and thin features in the volume rendering code some day.

See http://www.ogre3d.org/forums/viewtopic.php?f=25&t=75866&start=50#p479597

[reporter="mdias", created="Tue, 5 Mar 2013 07:37:44 +0100"]

Transparency sorting measures distance in world coords from Renderables origin to the Camera's origin. However, if the camera uses an orthographic projection matrix, this distance is wrong because in this case the distance should be from the Renderable's origin to the Camera's plane (Camera's origin and normal would be the direction the camera is looking at).

Currently the distance is measured by calling Renderable::getSquaredViewDepth.

Since there might potencially be more uses for "Orthographic distance measurement" for sorting other than the camera being in orthographic mode, I would like to purpose adding an extra flag to QueuedRenderableCollection::OrganisationMode, something like "OM_SORT_FORCEORTHOGRAPHIC".

This would be particularly useful for 2D games which use a normal perspective camera for parallax effect.

[reporter="mrjones", created="Thu, 20 Dec 2012 11:11:08 +0100"]

It seems to me that the depth map texture shadowing is broken in Ogre 1.8.0 with the D3D9 renderer on Win 7 64bit with Intel HD gpu. I am seeing weird artifacts which don't change a single bit when playing around with the sliders, but they flicker in funny ways when rotating or moving the camera. (screenshot attached) The "normal" texture shadows with no depth mapping look just fine.

While I use a "poor" on board i5 intel gpu, other modern games (e.g. Saints Row: The Third) manage their realtime texture-based full-scene shadows on this gpu flawlessly, so it has to be possible to get this working without looking so horribly broken.

[reporter="spacegaier", created="Sun, 25 Nov 2012 00:44:51 +0100"]

Original reporter: jmercier

The first video mode chosen by Ogre (1.7.3) on OS X, seems to be 1920x1080 (1080) interlaced . Some monitor only supports 1080p (progressive scan). It might be interesting to have an option to choose between the two modes, or simply get the current 'native' scan mode from the current 'active' monitor.
Steps To Reproduce
Additional Information Having ogre using fullscreen in 1920x1080 on a Gateway FHX2402L is not adequate (painful for the eyes).

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=505

[reporter="spacegaier", created="Sun, 25 Nov 2012 00:38:03 +0100"]

Original reporter: rride

The only way to clone correctly like the API says is to use a unique name, therefore if you create an entity, delete it, then try recreate an entity of the same name using .clone, it will actually still show your old entity. This seems like a bug to me. Why shouldn't you be able to recreate an entity with the same name as a previously deleted entity? And why should your old entity still be available?

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=67948

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=487

[reporter="Oogst", created="Mon, 29 Jul 2013 22:33:25 +0200"]

When I run the official SampleBrowser in DX11 and select a category from the "Select category" dropdown, it crashes with the following Ogre Exception:

OGRE EXCEPTION(3:RenderingApiException): Attempted to render to a D3D11 device without both vertex and fragment shaders there is no fixed pipeline d3d11 - use the RTSS or write custom shaders. in D3D11RenderSystem::_render at ..\..\..\..\..\RenderSystems\Direct3D11\src\OgreD3D11RenderSystem.cpp (line 2511)

Note that it works fine when I select DX9.

[reporter="fred1988", created="Mon, 13 May 2013 19:51:58 +0200"]

http://www.ogre3d.org/forums/viewtopic.php?f=1&t=77769&p=489547#p489547

Changing the colour depth value in the ogre browser sample, has no effect. And the Ogre.cfg file does not change the colour depth key (the other are changing).
Sample open the .exe with 32bits even if I set manually the colour depth key to 16 in the ogre.cfg.
I have the same issue with my prog, so I assume it's not a bug in the sample browser code.

I noticed this bug on 1.7.1 and 1.8.1 versions with an AMD GPU. This bug seems to be only on windows (masterfalcon) and I have no problem with Direct3D9 options

[reporter="spacegaier", created="Sat, 8 Dec 2012 17:55:31 +0100"]

Original author: MattStevens

How to reproduce: You need to use 2 scene managers and render with both of them. Then, modify some Ogre::Pass that is being used to mark it as dirty (something like the TextureUnitState so that the Pass's hash changes).

If the bug happens, you will either get an assert (in debug), or memory will start to leak (in release).

The following is a smaller repost of the forum thread where I exposed the problem. I added the thread link in the "Additional Information" field.

The issue is related to the RenderQueue cleanup when Passes are tagged as dirty. The usual behavior is that the Ogre::RenderPriorityGroup are cleared by the Ogre::RenderQueue at the beginning of a render to remove the dirty Ogre::Pass from the QueuedRenderableCollection::mGrouped map. (See RenderPriorityGroup::clear in OgreRenderQueueSortingGrouping.cpp) If this is not done, and the Pass's hash changed, the mGrouped map's key will be messed up and troubles happen. This works perfectly when using a single SceneManager, not when using 2 or more. The reason is that the dirty Pass list is static and cleared by the RenderQueue and by having 2 SceneManager you have 2 RenderQueue. With the current code, only 1 RenderQueue will be able to clean itself correctly, and the second one will cause a lot of troubles (Likely crash, memory leak or assert).

Forum thread explaining in greater details:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=73193

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=581

[reporter="skogler", created="Wed, 24 Jul 2013 15:33:39 +0200"]

The destructor of Ogre::Terrain is waiting for derived processes running in background threads before completing. While this is correct and necessary, I suspect it is the cause of some extensive lag which I am experiencing. It occurs when unloading terrain instances soon after they have been loaded.

A solution which could help and would not involve extensive changes is to introduce a method like requestDerivedDataUpdateTermination(). This method would set flags so the background tasks can terminate at an appropriate point.

A further method would need to be introduced to check whether all tasks have finished.

It could then be used in TerrainGroup when unloading terrains to create a list of Terrain instances which are to be deleted. After requesting the termination of any background tasks, the TerrainGroup could then check every frame if any of these instances are ready to be deleted and if so, delete them.

This could save valuable time in the main thread and minimize the impact of the Terrain destructor on the rendering.

I am unsure if this approach is suitable. Please leave comments on whether it is and/or what you think needs to be changed or what alternatives there are. I am available to implement and test this if we agree on what the best solution is.

[reporter="spacegaier", created="Sat, 24 Nov 2012 19:52:36 +0100"]

Original reporter: myint

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=60939

Original Mantis Ticket: http://www.ogre3d.org/mantis/view.php?id=360

[reporter="dsefton", created="Sat, 20 Apr 2013 07:44:00 +0200"]

Problem description
glGenVertexArraysOES is returning zero in the 1.9 branch after creating a camera, therefore throwing the following exception:

if (!mVAO)
{
    OGRE_EXCEPT(Exception::ERR_INTERNAL_ERROR,
    "Cannot create GL ES Vertex Array Object",
    "GLES2VertexDeclaration::GLES2VertexDeclaration");
}

Stack trace

#9  0x01e8edbc in Ogre::GLES2VertexDeclaration::GLES2VertexDeclaration() at RenderSystems/GLES2/src/OgreGLES2VertexDeclaration.cpp:48
#10 0x01e8ebb0 in Ogre::GLES2VertexDeclaration::GLES2VertexDeclaration() at RenderSystems/GLES2/src/OgreGLES2VertexDeclaration.cpp:54
#11 0x01e5dc68 in Ogre::GLES2HardwareBufferManagerBase::createVertexDeclarationImpl() at RenderSystems/GLES2/src/OgreGLES2HardwareBufferManager.cpp:123
#12 0x0091fd88 in Ogre::HardwareBufferManagerBase::createVertexDeclaration() at OgreMain/src/OgreHardwareBufferManager.cpp:87

As of yet I can't reproduce it in a test case, but ideas on why this might happen would be useful.

Stack Overflow question: http://stackoverflow.com/questions/13953755/glgenvertexarraysoes-returns-a-zero-vao-on-ios-sometimes

[reporter="bjoe", created="Tue, 26 Feb 2013 14:52:46 +0100"]

When a monitor is set to portrait mode (in Windows 7), the FSAA can accept only one value - '0' (NO Anti Alias).
Changing to a video mode with the right resolution, brings back the FSAA options (0, 2, 4, 8, 8 Quality)

The current implementation of restoreConfig() reads the ogre.cfg data to a MultiMap and then iterates through and sets the render system parameters. The problem is that it sets the 'FSAA' parameter BEFORE the 'Video Mode' parameter and causing the FSAA value to be ignored.

The obvious solution is to change the order of which the parameters are set so that the 'Video Mode' is set before the 'FSAA'.

[reporter="cyberkm", created="Thu, 11 Apr 2013 12:52:16 +0200"]

Right now to minimize render state batches Ogre sorts passes by hash.
The default hash is generated by MinTextureStateChangeHashFunc function which considers only 2 texture units. As a more and more complex effects emerge that require 3, 4 or even more texture units per pass to be processed by shaders this hash function doesn't perform well in those cases. While it is possible to write custom hash functions, it might be a benefit to write a new hash func that takes an "unlimited" amount of texture states in account to improve performance