Wonky camera & transformations after porting from 1.x to 2.1

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


Post Reply
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Wonky camera & transformations after porting from 1.x to 2.1

Post by noorus »

Hey guys,
So I decided to port my game engine efforts from OGRE 1.9 straight to 2.1, preliminarily with as little changes as I could - adding the workspace & HLMS stuff, converting entities to items.
Once I finally got the whole thing to compile and correctly parse material scripts, I'm facing some really weird issues with the camera and object transformations (aside from the materials, which also do not work at all).

Here's what my sandbox used to look like in 1.9 - A very simple scene, one plane for ground, one directional light in the sky, one camera attached to one freely moving scene node:
Image

Now, after my porting efforts to 2.1, here's what it looks like: (this version doesn't have the nav mesh or physics debug stuff as seen in the 1.9 screenshot, but instead has another character capsule with a white FOV cone presentation)
Image

Everything is absolutely bonkers, and moving the camera does transformations so weird that it's hard to even describe.

Now, I did everything as best I could following the 2.1 samples code as well as the porting document, and I'm just flabbergasted as to what the hell is going on.
I wonder if someone with actual working knowledge of the 2.1 overhaul could help me with an educated guess as to where to begin looking for what's wrong..! :(

Thanks, Noora
Creator of Nice Input Library, for your advanced input needs.
Image
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Wonky camera & transformations after porting from 1.x to

Post by al2950 »

Difficult to say without inspecting your camera code. Are you using any of the _setDerivied** functions eg _setDeriviedPosition ?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Wonky camera & transformations after porting from 1.x to

Post by dark_sylinc »

Yes, al2950 made a really good point; how is your camera being set and updated?
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Re: Wonky camera & transformations after porting from 1.x to

Post by noorus »

Alrightie, here's my camera code in its entirety!

Base class Camera

Code: Select all

namespace Glacier {

  Camera::Camera( SceneManager* scene, const Ogre::String& name,
  const Vector3& position, const Radian& fovy ):
  mCamera( nullptr ), mNode( nullptr ),
  mScene( scene ), mModifier( nullptr )
  {
    assert( scene );

    // Create camera
    mCamera = mScene->createCamera( name );
    mCamera->detachFromParent();

    mCamera->setPosition( Vector3::ZERO );
    mCamera->setAutoAspectRatio( true );
    mCamera->setFOVy( fovy );

    // Create node, attach the camera
    mNode = mScene->getRootSceneNode()->createChildSceneNode();
    mNode->attachObject( mCamera );
    mNode->setPosition( position );
    mNode->setFixedYawAxis( true, Vector3::UNIT_Y );

    mCamera->setNearClipDistance( 0.0001f );
    mCamera->setFarClipDistance( 1024.0f );
  }

  const Radian& Camera::getFOVy()
  {
    return mCamera->getFOVy();
  }

  void Camera::setFOVy( const Radian& fovy )
  {
    mCamera->setFOVy( fovy );
  }

  void Camera::lookAt( const Vector3& position )
  {
    mCamera->lookAt( position );
  }

  void Camera::castViewportRay( const Vector2& position, Ray& ray )
  {
    assert( position.x >= 0.0f && position.x <= 1.0f );
    assert( position.y >= 0.0f && position.y <= 1.0f );

    mCamera->getCameraToViewportRay( position.x, position.y, &ray );
  }

  Camera::~Camera()
  {
    if ( mNode )
    {
      mNode->detachAllObjects();
      mScene->destroySceneNode( mNode );
    }
    if ( mCamera )
      mScene->destroyCamera( mCamera );
  }

}
Derived class GameCamera (arcball rotation around target scenenode) (excuse the ugly hacks, it's been subjected to lots of experimentation over time :P)

Code: Select all

namespace Glacier {

  const Real cMinimumWindow = 10.0f;
  const Real cMaximumWindow = 32.0f;
  const Real cRotationDeceleration = 20.0f;
  const Real cZoomAcceleration = 150.0f;
  const Real cZoomDeceleration = 15.0f;
  const Radian cFOVy = Radian( Ogre::Math::DegreesToRadians( 70.0f ) );
  const Real cDistance = 20.0f;
  const Real cSensitivity = 0.75f;
  const Radian cClampTop = Radian( 0.6f );
  const Radian cClampBottom = Radian( 1.0f );

  GameCamera::GameCamera( SceneManager* scene,
    const Ogre::String& name, const SceneNode* target ):
    Camera( scene, name, Vector3::ZERO, cFOVy ),
    mSensitivity( cSensitivity ),
    mTarget( target ),
    mRotation( Quaternion::IDENTITY ), mMovement( Vector3::ZERO ),
    mZoomVelocity( 0.0f ),
    mZoom( 0.0f ), mDirection( Vector3::ZERO ), mReverseAxes( true )
  {
    mDistance = cDistance;
    mCamera->setAutoTracking( true, (SceneNode*)mTarget );
    mCamera->setProjectionType( Ogre::PT_ORTHOGRAPHIC );
    mAngle = Ogre::Math::DegreesToRadians( 45.0f );
    mDirection = Quaternion( mAngle, Vector3::UNIT_Z ) * Vector3::UNIT_X;
    updateWindow();
  }

  void GameCamera::applyMovement( const Vector3& movement )
  {
    if ( mReverseAxes ) {
      mMovement.x += movement.x * mSensitivity;
      mMovement.y += movement.y * mSensitivity;
    }
    else {
      mMovement.x += -movement.x * mSensitivity;
      mMovement.y += -movement.y * mSensitivity;
    }
    mMovement.z += movement.z;
  }

  void GameCamera::updateWindow()
  {
    Real window = Math::interpolateLinear( cMaximumWindow, cMinimumWindow, mZoom );
    mCamera->setOrthoWindowWidth( window );
  }

  void GameCamera::update( const GameTime delta )
  {
    // Calculate the local X axis, as it changes with rotation along world Y
    Vector3 axis = Vector3( -mDirection.z, 0, mDirection.x );
    axis.normalise();

    // Handle new X,Y movement
    if ( mMovement.x != 0.0f || mMovement.y != 0.0f )
    {
      // Treat the movement input as degrees, and convert to radians
      Radian radiansX = Radian( Ogre::Math::DegreesToRadians( mMovement.x ) );
      Radian radiansY = Radian( Ogre::Math::DegreesToRadians( mMovement.y ) );
      bool resetRotation = false;
      if ( radiansY > mDirection.angleBetween( Vector3::UNIT_Y ) - cClampTop ) {
        radiansY = mDirection.angleBetween( Vector3::UNIT_Y ) - cClampTop;
        resetRotation = true;
      }
      else if ( radiansY < mDirection.angleBetween( Vector3::UNIT_Y ) - cClampBottom ) {
        radiansY = mDirection.angleBetween( Vector3::UNIT_Y ) - cClampBottom;
        resetRotation = true;
      }
      // Compose the rotation delta and add to existing velocity
      Quaternion rotationX( radiansY, axis );
      Quaternion rotationY( radiansX, Vector3::UNIT_Y );
      if ( resetRotation )
        mRotation = rotationX * rotationY;
      else
        mRotation = mRotation * rotationX * rotationY;
    }

    // Handle rotation velocity
    if ( mRotation != Quaternion::IDENTITY )
    {
      mRotation = mRotation.Slerp( cRotationDeceleration * (Real)delta, mRotation,
        Quaternion::IDENTITY, true );
      mDirection = mRotation * mDirection;
    }

    mDirection.normalise();

    // Handle Z mouse scroll (zoom)
    if ( mMovement.z )
      mZoomVelocity += mMovement.z;
    if ( mZoomVelocity != 0.0f )
    {
      mZoom += mZoomVelocity * cZoomAcceleration * (Real)delta;
      // TODO:MEDIUM - this could be softened a bit
      if ( mZoom > 1.0f ) {
        mZoom = 1.0f;
        mZoomVelocity = 0.0f;
      }
      else if ( mZoom < 0.0f ) {
        mZoom = 0.0f;
        mZoomVelocity = 0.0f;
      }
      else {
        if ( mZoomVelocity > 0.0f ) {
          mZoomVelocity -= (Real)delta * cZoomDeceleration;
          if ( mZoomVelocity < 0.0f ) mZoomVelocity = 0.0f;
        }
        else if ( mZoomVelocity < 0.0f ) {
          mZoomVelocity += (Real)delta * cZoomDeceleration;
          if ( mZoomVelocity > 0.0f ) mZoomVelocity = 0.0f;
        }
      }
    }

    updateWindow();

    // Reset movement for next frame
    mMovement = Vector3::ZERO;

    // Update camera position
    Vector3 target = mTarget->_getDerivedPosition();
    Vector3 offset = mDirection * mDistance;
    Vector3 vecPosition = target + offset;
    if ( mModifier )
      mModifier->updatePosition( this, target, offset, vecPosition );
    mNode->setPosition( vecPosition );
  }

  void GameCamera::setSensitivity( const Real sensitivity )
  {
    mSensitivity = sensitivity;
  }

  void GameCamera::setAxisReversion( const bool reverse )
  {
    mReverseAxes = reverse;
  }

  GameCamera::~GameCamera()
  {
    // Stubb
  }

}
TL;DR Yeah, the update method does call

Code: Select all

Vector3 target = mTarget->_getDerivedPosition();
Is that bad..?


EDIT: Also, it's not only the camera! The other character is angled weirdly and instead of spinning neatly around the Y axis, goes all over the place clipping through the ground etc.
I'd guess all of these problems are related to my doing something wrong when fetching objects world coordinates or something.
Creator of Nice Input Library, for your advanced input needs.
Image
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Wonky camera & transformations after porting from 1.x to

Post by al2950 »

noorus wrote: TL;DR Yeah, the update method does call

Code: Select all

Vector3 target = mTarget->_getDerivedPosition();
Is that bad..?
Well that depends! There is no longer checking on those functions which will ensure calcs are correct. Its difficult to say, however, I would be tempted to run in debug to see what asserts are raised. And yes running in debug in Ogre 2.1 is possible! If you get a lot of Node transform out of date, then do not ignore them, instead you can use getDerivedPositionUpdated but please do not ignore the performance penalty of doing so, although its less than 1.x! :D
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Re: Wonky camera & transformations after porting from 1.x to

Post by noorus »

al2950 wrote:
noorus wrote: TL;DR Yeah, the update method does call

Code: Select all

Vector3 target = mTarget->_getDerivedPosition();
Is that bad..?
Well that depends! There is no longer checking on those functions which will ensure calcs are correct. Its difficult to say, however, I would be tempted to run in debug to see what asserts are raised. And yes running in debug in Ogre 2.1 is possible! If you get a lot of Node transform out of date, then do not ignore them, instead you can use getDerivedPositionUpdated but please do not ignore the performance penalty of doing so, although its less than 1.x! :D
Thanks, I've been running in debug mode and faced a couple of those asserts, and changed the appropriate calls to _getDerivedPositionUpdated.
I did the same for the GameCamera class now, but nothing changed.
It's really weird, this bug, since it's almost like the Y and Z axes had switched places..?
Creator of Nice Input Library, for your advanced input needs.
Image
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Wonky camera & transformations after porting from 1.x to

Post by al2950 »

noorus wrote: It's really weird, this bug, since it's almost like the Y and Z axes had switched places..?
Not that I am aware of, lights had an issue where z was inverted in some cases i think, but not cameras.

Its late here so I ill have a think about it tomorrow.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Wonky camera & transformations after porting from 1.x to

Post by dark_sylinc »

I don't see something that stands out unfortunately. I suspect something in particular is screwing things up and once you stop doing that everything will likely start to work (whether an Ogre bug or some incompatibility or bad practice in your setup).

My recommendation is to disable almost everything and start enabling in chunks until you narrow the culprits. Try to render as little as possible (ie. not many objects). In particular I would watch out for:
  • Your near clip distance is very low ( 0.0001f ). Use something more stable, like 0.01f. Once you fix everything you can start going back to 0.001.
  • Disable the setAutoTracking.
  • Set camera projection to projection, and watchout for the FOV values you're suplying to setFOVy.
  • Are you / were you relying on a listener (RenderTargetListener, CompositorWorkspaceListener, etc)?
I'm not saying to make these changes permanent. Just stick to things that are thoroughly tested (i.e. I've tested orthographic projection and it works well, but I've tested projective projection a lot more for obvious reasons) until you find the culprit so we can take a closer look and fix it.

Edit: Quick test: Does the problem go away if you switch to the v2.1-pso branch?
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Re: Wonky camera & transformations after porting from 1.x to

Post by noorus »

dark_sylinc wrote:I don't see something that stands out unfortunately. I suspect something in particular is screwing things up and once you stop doing that everything will likely start to work (whether an Ogre bug or some incompatibility or bad practice in your setup).

My recommendation is to disable almost everything and start enabling in chunks until you narrow the culprits. Try to render as little as possible (ie. not many objects). In particular I would watch out for:
  • Your near clip distance is very low ( 0.0001f ). Use something more stable, like 0.01f. Once you fix everything you can start going back to 0.001.
  • Disable the setAutoTracking.
  • Set camera projection to projection, and watchout for the FOV values you're suplying to setFOVy.
  • Are you / were you relying on a listener (RenderTargetListener, CompositorWorkspaceListener, etc)?
I'm not saying to make these changes permanent. Just stick to things that are thoroughly tested (i.e. I've tested orthographic projection and it works well, but I've tested projective projection a lot more for obvious reasons) until you find the culprit so we can take a closer look and fix it.

Edit: Quick test: Does the problem go away if you switch to the v2.1-pso branch?
I did everything you suggested (the camera used to be perspective rather than orthogonal anyway), but alas no help there. I'm not relying to any listeners that I know of in my own code, I have a simple single-threaded game loop where logic stepping (including camera movement) is one thing and then rendering is another.

I'm switching to 2.1-pso tip now, and happened upon a little bug in the meanwhile: OgreWireAabb.cpp doesn't include OgreStableHeaders.h, so that causes a fatal error in MSVC. I'm fixing it locally now.

EDIT: Getting more serious errors in D3D11RenderSystem; I tried looking into it, but I can't see what the problem is (this being on Visual C++ 2015 Update 1):

Code: Select all

6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1923): error C2511: 'ID3D11InputLayout *Ogre::D3D11HLSLProgram::getLayoutForPso(const Ogre::VertexElement2VecVec &)': overloaded member function not found in 'Ogre::D3D11HLSLProgram'
6>         C:\Code\ogre\RenderSystems\Direct3D11\include\OgreD3D11HLSLProgram.h(47): note: see declaration of 'Ogre::D3D11HLSLProgram'
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1924): error C2352: 'Ogre::D3D11HLSLProgram::getNumInputs': illegal call of non-static member function
6>         C:\Code\ogre\RenderSystems\Direct3D11\include\OgreD3D11HLSLProgram.h(379): note: see declaration of 'Ogre::D3D11HLSLProgram::getNumInputs'
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1966): error C2597: illegal reference to non-static member 'Ogre::D3D11HLSLProgram::mD3d11ShaderInputParameters'
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1966): error C3867: 'Ogre::D3D11HLSLProgram::mD3d11ShaderInputParameters': non-standard syntax; use '&' to create a pointer to member
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1966): error C2109: subscript requires array or pointer type
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1998): error C2597: illegal reference to non-static member 'Ogre::D3D11HLSLProgram::mD3d11ShaderInputParameters'
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1998): error C3867: 'Ogre::D3D11HLSLProgram::mD3d11ShaderInputParameters': non-standard syntax; use '&' to create a pointer to member
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(1998): error C2109: subscript requires array or pointer type
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2020): error C2228: left of '.get' must have class/struct/union
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2027): error C2597: illegal reference to non-static member 'Ogre::D3D11HLSLProgram::mMicroCode'
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2027): error C3867: 'Ogre::D3D11HLSLProgram::mMicroCode': non-standard syntax; use '&' to create a pointer to member
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2027): error C2109: subscript requires array or pointer type
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2028): error C2228: left of '.size' must have class/struct/union
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2029): error C2660: 'ID3D11Device::CreateInputLayout': function does not take 3 arguments
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2031): error C2228: left of '.isError' must have class/struct/union
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2033): error C2228: left of '.getErrorDescription' must have class/struct/union
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2034): error C2597: illegal reference to non-static member 'Ogre::Resource::mName'
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2034): error C3867: 'Ogre::Resource::mName': non-standard syntax; use '&' to create a pointer to member
6>C:\Code\ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp(2034): error C2568: '+': unable to resolve function overload
EDIT: Fixed this too; Apparently the compiler was missing the definition for VertexElement2VecVec, even though Intellisense had it. Therefore:

Code: Select all

#include "Vao/OgreVertexBufferPacked.h"
Creator of Nice Input Library, for your advanced input needs.
Image
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Re: Wonky camera & transformations after porting from 1.x to

Post by noorus »

Alas, switching to 2.1-pso didn't help - although it almost seems like the angle changed (still very, very wrong) but I'm probably imagining it.

However, I might take this moment to mention that my entire codebase is public, if you care: https://github.com/noorus/glacier2

Straight to source: https://github.com/noorus/glacier2/tree ... acier2/src
Relevant files are probably Graphics.cpp, Director.cpp, GameCamera.cpp, DemoState.cpp, WorldPrimitives.cpp :?

Thanks for the help so far!
in 2.1-pso tip
in 2.1-pso tip
Creator of Nice Input Library, for your advanced input needs.
Image
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Wonky camera & transformations after porting from 1.x to

Post by dark_sylinc »

noorus wrote:I did everything you suggested (the camera used to be perspective rather than orthogonal anyway), but alas no help there. I'm not relying to any listeners that I know of in my own code, I have a simple single-threaded game loop where logic stepping (including camera movement) is one thing and then rendering is another.
Bummer!
You'll have to keep stripping things until you have the bare bones working, then start adding back again.
I'm switching to 2.1-pso tip now, and happened upon a little bug in the meanwhile: OgreWireAabb.cpp doesn't include OgreStableHeaders.h, so that causes a fatal error in MSVC. I'm fixing it locally now.(...)
EDIT: Fixed this too; Apparently the compiler was missing the definition for VertexElement2VecVec, even though Intellisense had it.
Sorry for that. My Windows build was using Unity builds to speed up compilation, which masked those errors. Fix pushed.
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Re: Wonky camera & transformations after porting from 1.x to

Post by noorus »

Alright, I'll start stripping stuff down, switching to a dummy static camera etc.
One favor to ask though: Does my graphics engine initialization and the workspace/compmgr2 stuff look correct? (in Graphics.cpp)

I'm also curious as to how I would recreate the one-color-only alpha-blended materials (such as the overlay backgrounds, the navigation debug visualization mesh etc.) in HLMS..?
I used to have a material like:

Code: Select all

material Debug/2DDebugRect
{
	technique
	{
		pass
		{
			scene_blend alpha_blend
			lighting off
			depth_write off
			texture_unit
			{
				colour_op_ex source1 src_manual src_current 0.1 0.1 0.1
				alpha_op_ex source1 src_manual src_current 0.6
			}
		}
	}
}
...to achieve that dimmed background for the render stats overlay in the up-right corner.

I tried recreating it like

Code: Select all

hlms Debug/2DDebugRect unlit
{
	scene_blend alpha_blend
	lighting off
	depth_write off
	colour_op_ex source1 src_manual src_current 0.0 0.0 0.0
	alpha_op_ex source1 src_manual src_current 0.6
}
...but all I get is that nasty glaring white box as seen in the 2.1 screenshots. :?

Thanks again for all the support :)
Creator of Nice Input Library, for your advanced input needs.
Image
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Wonky camera & transformations after porting from 1.x to

Post by dark_sylinc »

To make an unlit material that would dim you would have to write something like:

Code: Select all

hlms Debug/2DDebugRect unlit
{
   scene_blend alpha_blend
   depth_write off
   diffuse 0.1 0.1 0.1 0.6
}
Unless I'm missing something.
noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland
x 3

Re: Wonky camera & transformations after porting from 1.x to

Post by noorus »

Good news! :)
For whatever reason, after I made a new light setup (the dark-ass materials were getting on my nerves), everything seems to now be alright.
I guess the problem might've been that I was attaching my one directional global light straight to the dynamic root scene node.. Of course, the light had no position, but it has a direction, and that might've been screwing up the root node... Oops.
Back in 1.9 my light wasn't attached to anything, and it wasn't a problem. However, it's now safely tied to its own scene node, and all seems to be fine :P
dark_sylinc wrote:To make an unlit material that would dim you would have to write something like:

Code: Select all

hlms Debug/2DDebugRect unlit
{
   scene_blend alpha_blend
   depth_write off
   diffuse 0.1 0.1 0.1 0.6
}
Unless I'm missing something.
Oh right, yeah, that works nice. By the way, can these new HLMS materials descend from other materials, like the old materials used to? I definitely like having a base material for things that share the same properties aside from different textures or whatever. I tried to do it, but couldn't figure out a working syntax.

Finally, I'm getting a crash when shutting down the renderer. It's an assert failure for the first dynamic cast in D3D11DepthBuffer::isCompatible - the passed renderTarget is an Ogre::D3D11RenderWindowHwnd*, and casting that to a D3D11DepthTextureTarget* fails.
I'm probably shutting something down in the wrong order, or forgetting to release something, but what could it be? This happened with both 2.1 branches, but I had ignored it so far since I had more pressing problems.

Call stack:

Code: Select all

>	RenderSystem_Direct3D11_d.dll!Ogre::D3D11DepthBuffer::isCompatible(Ogre::RenderTarget * renderTarget=0x0000000001c74068, bool exactFormatMatch=true) Line 87
 	OgreMain_d.dll!Ogre::RenderTarget::attachDepthBuffer(Ogre::DepthBuffer * depthBuffer=0x0000000002141488, bool exactFormatMatch=true) Line 173
 	OgreMain_d.dll!Ogre::RenderSystem::setDepthBufferFor(Ogre::RenderTarget * renderTarget=0x0000000001c74068, bool exactMatch=true) Line 627
 	RenderSystem_Direct3D11_d.dll!Ogre::D3D11RenderSystem::_setRenderTargetViews(bool colourWrite=true) Line 2180
 	RenderSystem_Direct3D11_d.dll!Ogre::D3D11RenderSystem::_setRenderTarget(Ogre::RenderTarget * target=0x0000000001c74068, bool colourWrite=true) Line 2152
 	OgreMain_d.dll!Ogre::CompositorWorkspace::_validateFinalTarget() Line 611
 	OgreMain_d.dll!Ogre::CompositorManager2::_update(Ogre::SceneManagerEnumerator & sceneManagers={...}, Ogre::HlmsManager * hlmsManager=0x0000000001c4eec8) Line 527
 	OgreMain_d.dll!Ogre::Root::_updateAllRenderTargets(Ogre::FrameEvent & evt={...}) Line 1531
 	OgreMain_d.dll!Ogre::Root::renderOneFrame(float timeSinceLastFrame=0.134768322) Line 1069
Creator of Nice Input Library, for your advanced input needs.
Image
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Wonky camera & transformations after porting from 1.x to

Post by dark_sylinc »

That's fantastic news! And good to keep in mind if I see another user with the same problem. Yeah, Lights need their own node. Direction & position lives in the node. It's documented somewhere in the docs.
Oh right, yeah, that works nice. By the way, can these new HLMS materials descend from other materials, like the old materials used to? I definitely like having a base material for things that share the same properties aside from different textures or whatever. I tried to do it, but couldn't figure out a working syntax.
The following I think works:

Code: Select all

abstract hlms baseMaterial unlit
{
   scene_blend alpha_blend
   depth_write off
}
hlms Debug/2DDebugRect unlit : baseMaterial
{
   diffuse 0.1 0.1 0.1 0.6
}
That will work for keywords that came from the old system (like scene_blend, depth_write) but not for diffuse (which is new & specific to the Unlit hlms).
Finally, I'm getting a crash when shutting down the renderer. It's an assert failure for the first dynamic cast in D3D11DepthBuffer::isCompatible - the passed renderTarget is an Ogre::D3D11RenderWindowHwnd*, and casting that to a D3D11DepthTextureTarget* fails.
I'm probably shutting something down in the wrong order, or forgetting to release something, but what could it be? This happened with both 2.1 branches, but I had ignored it so far since I had more pressing problems.
The callstack indicates you're trying to render after shutting down procedure started. Once you've started shutting down, renderOneFrame shouldn't be called. This is a common mistake. Just ensure you don't try to render again after you started quitting.
Post Reply