Wonky camera & transformations after porting from 1.x to 2.1
-
- 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
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:
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)
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
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:
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)
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
-
- 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
Difficult to say without inspecting your camera code. Are you using any of the _setDerivied** functions eg _setDeriviedPosition ?
- dark_sylinc
- 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
Yes, al2950 made a really good point; how is your camera being set and updated?
-
- 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
Alrightie, here's my camera code in its entirety!
Base class Camera
Derived class GameCamera (arcball rotation around target scenenode) (excuse the ugly hacks, it's been subjected to lots of experimentation over time )
TL;DR Yeah, the update method does call
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.
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 );
}
}
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
}
}
Code: Select all
Vector3 target = mTarget->_getDerivedPosition();
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.
-
- 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
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!noorus wrote: TL;DR Yeah, the update method does callIs that bad..?Code: Select all
Vector3 target = mTarget->_getDerivedPosition();
-
- 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
Thanks, I've been running in debug mode and faced a couple of those asserts, and changed the appropriate calls to _getDerivedPositionUpdated.al2950 wrote: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!noorus wrote: TL;DR Yeah, the update method does callIs that bad..?Code: Select all
Vector3 target = mTarget->_getDerivedPosition();
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..?
-
- 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
Not that I am aware of, lights had an issue where z was inverted in some cases i think, but not cameras.noorus wrote: It's really weird, this bug, since it's almost like the Y and Z axes had switched places..?
Its late here so I ill have a think about it tomorrow.
- dark_sylinc
- 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
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:
Edit: Quick test: Does the problem go away if you switch to the v2.1-pso branch?
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)?
Edit: Quick test: Does the problem go away if you switch to the v2.1-pso branch?
-
- 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
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.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: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.
- 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)?
Edit: Quick test: Does the problem go away if you switch to the v2.1-pso branch?
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
Code: Select all
#include "Vao/OgreVertexBufferPacked.h"
-
- 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
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!
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!
- dark_sylinc
- 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
Bummer!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.
You'll have to keep stripping things until you have the bare bones working, then start adding back again.
Sorry for that. My Windows build was using Unity builds to speed up compilation, which masked those errors. Fix pushed.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.
-
- 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
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:
...to achieve that dimmed background for the render stats overlay in the up-right corner.
I tried recreating it like
...but all I get is that nasty glaring white box as seen in the 2.1 screenshots.
Thanks again for all the support
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
}
}
}
}
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
}
Thanks again for all the support
- dark_sylinc
- 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
To make an unlit material that would dim you would have to write something like:
Unless I'm missing something.
Code: Select all
hlms Debug/2DDebugRect unlit
{
scene_blend alpha_blend
depth_write off
diffuse 0.1 0.1 0.1 0.6
}
-
- 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
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
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:
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
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.dark_sylinc wrote:To make an unlit material that would dim you would have to write something like:Unless I'm missing something.Code: Select all
hlms Debug/2DDebugRect unlit { scene_blend alpha_blend depth_write off diffuse 0.1 0.1 0.1 0.6 }
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
- dark_sylinc
- 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
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.
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).
The following I think works: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.
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
}
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.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.