skeletal animation, wrong aspect at initialisation since nvidia 615.71.09 Topic is solved

Problems building or running the engine, queries about how to use features etc.
Post Reply
bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

Ogre Version: 14.5.2 :
Operating System: fedora 44:
Render System: : GL3+:

Hi,

I have a rendering application that displays animated character (walking).
It used to work well at least since Ogre1.12 and up to very recently = before install of nvidia driver 615.71.09.
It works well with same code same os with nvidia driver 610.57.04

In my code, for skeletal animation, at init, i do :

Code: Select all

      anim_state->setLoop(true);
      anim_state->setEnabled(true);
      anim_state->setTimePosition(0.0f);

and, for each dt step i do :

Code: Select all

anim_state->addTime(dt * current_speed / ref_speed);

With new version of driver, when current_speed = 0 at init, my characters appear with T-pose (pose corresponding to not applying skeletal animation).
If then current_speed becomes not zero, animation looks good. If current_speed gets back to 0, animation stops showing frozen character (which is expected).

I suspect a shader build or upload problem but i don't know how to investigate this.

What is also very surprising (with driver 615.71.09) :
in my app, i also have an alternative rendering technique based on scheme to show "type" of objects in the scene (sort of color coded type like solid blue for pedestrians, solid red for cars...).
Leaving current_speed = 0, character shown in T-pose,
At the moment the application creates a viewport showing this alternative rendering (in addition to default rendering - color code view shown as miniview overlay) the characters show correct aspect in all views = aspect at key_frame 0 of the animation.

As any one seen such behavior ?
Is there something i'm missing (which used to be non problematic until now ?)

paroj
OGRE Team Member
OGRE Team Member
Posts: 2295
Joined: Sun Mar 30, 2014 2:51 pm
x 1264
Contact:

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by paroj »

try:
anim_state->setTimePosition(1.0f);
anim_state->setTimePosition(0.0f);

at init to force an update

bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

during setup method (OgreBites::ApplicationContextQt)
i load the objects and perform the init.
placing here

anim_state->setTimePosition(1.0f);
anim_state->setTimePosition(0.0f);

does not 'fix'.

for quick test purpose, if i perform this force update trick the first time i enter frameRenderingQueued,
it does the job = aspect is ok (so i assume update has been correctly forced).

rpgplayerrobin
Bugbear
Posts: 812
Joined: Wed Mar 18, 2009 3:03 am
x 471

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by rpgplayerrobin »

What happens if you use ent->_updateAnimation after you have set the time position?
Also, have you set weight of all other animations to 0 and only this one to 1?

bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

i do enable(false) for other animations.

i'm going to test the use of _updateAnimation

rpgplayerrobin
Bugbear
Posts: 812
Joined: Wed Mar 18, 2009 3:03 am
x 471

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by rpgplayerrobin »

What if you do not just use enable(false), but also use setWeight(0.0f)?

bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

Hi,

thanks for your advices, it helped testing different code alternatives.

Finally, i just ended with following solution :

During setup (ApplicationContextQt overload)

  • load all the meshes and animations,
  • deactivate all animations (setEnabled(false);)

On my overloaded timerEvent, i first perform a "step(dt)" or a init() for the first call, and then call base-method (ApplicationContextQt::timerEvent which performs a renderOneFrame)

  • At init i enable the desired animation (setEnabled(true)) and set original anim position (setTimePosition(0.0))
  • For steps, addTime(dt * k) with possibly k == 0 (the characer is not moving)

This sequence sounds logical to me and It works just fine :-)

for the record), my original flow was
During setup (ApplicationContextQt overload)

  • load all the meshes and animations,
  • deactivate all animations (setEnabled(false);)
  • activate animations i desired (setEnabled(true))
  • setTimePosition(0)

Then, for every renderOneFrame i did addTime(dt * k) with possibly k == 0 (the characer is not moving)
k == 0 at startup, the character is shown t-pose until k gets non zero (with driver 615.71.09).

Sequance detailed this way and associated result sounds logical / consistent. For some reasons, this flow worked with older versions of the driver i.e. character had the proper aspect \o/

once again.
thaks for the support :-D

bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

Actually, i'm wrong it's still nok... :-(
It seems to be related to the fact that the animated entity is culled or not as i try to enable.
sounds like : if the entity is culled (far from camera) the setEnabled(true) is sort of ignored, so if animation has addTime(0) when the camera gets close to the animation it looks in t-pose
=> i think i need to detect the culled -> not culled transition to force a update ???

i'll dig this direction next days

rpgplayerrobin
Bugbear
Posts: 812
Joined: Wed Mar 18, 2009 3:03 am
x 471

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by rpgplayerrobin »

Did you try these below?
You never noted anything about it in your response.

setWeight(0.0f)
ent->_updateAnimation()

Also, if you know that it happens when the entity is not shown, debug _updateAnimation by going into that function in your code (F11 in Visual Studio) and see why it would not update the animation correctly when it is not visible.

bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

Hello.

I'm pretty sure it is related to the driver that changed.
To what i see i'd rather think that the solution may come from config of the driver, or from inside ogre close to the gpu.

Here is a little sample based on Samples/Tutorials/Bootstrap.cpp

It creates a scene with a walking boy.
As a user, pressing 'm' key steps the animation.
Pressing 'f' as "go Far" makes the camera to be far => showing empty scene
Pressing 'c' as "come Close" makes the camera back to face the walking boy.

For Mesa driver or nvidia 610.57.04 this application works fine :
when it start it shows the boy, pressing m shows the animation (step by step), pressing 'F' and 'C' do what is expected (show nothing, show the boy in the state it was left).

For new version of the driver 615.71.09 it's NOK :
when it starts the aspect of the boy is "no animation applied",
when pressing 'm' it shows correct animation,
then pressing f shows nothing (normal)
then pressing c shows boy "no animation applied".
--> as if animation shader had been unloaded ?!

Code: Select all

#include <Ogre.h>
#include <OgreApplicationContext.h>

int main(int argc, char* argv[])
{
  (void)(argc);
  (void)(argv);

  const auto data_filepath = "!!SOME_PATH_TO_SOURCE!!/scene_data";
  const auto conf_dir = "!!SOME_PATH_TO_THE_BIN!!";

  const auto scene_res_group_name = "SceneData";
  const auto character_mesh = "man1-tshirt02.005.mesh"; // cf. mesh
  const auto walk_anim_name = "walk";                   // cf. skeleton

  setenv("OGRE_CONFIG_DIR", conf_dir, 1);

  // Required in linux fedora context to grant use of nvidia gpu (would use mesa if not)
  setenv("__NV_PRIME_RENDER_OFFLOAD", "1", 1);
  setenv("__GLX_VENDOR_LIBRARY_NAME", "nvidia", 1);

  // Create context
  OgreBites::ApplicationContext ctx("TestApp");
  ctx.initApp();

  Ogre::Root* root = ctx.getRoot();
  Ogre::SceneManager* scnMgr = root->createSceneManager();

  Ogre::ResourceGroupManager& resMgr = Ogre::ResourceGroupManager::getSingleton();
  resMgr.createResourceGroup(scene_res_group_name);
  resMgr.addResourceLocation(data_filepath, "FileSystem", scene_res_group_name);
  resMgr.initialiseResourceGroup(scene_res_group_name);
  resMgr.loadResourceGroup(scene_res_group_name);

  Ogre::RTShader::ShaderGenerator* shadergen = Ogre::RTShader::ShaderGenerator::getSingletonPtr();
  shadergen->addSceneManager(scnMgr);

  // Create light
  Ogre::Light* light = scnMgr->createLight("MainLight");
  Ogre::SceneNode* lightNode = scnMgr->getRootSceneNode()->createChildSceneNode();
  lightNode->setPosition(15, 10, 0);
  lightNode->attachObject(light);

  // Create camera
  Ogre::Camera* cam = scnMgr->createCamera("MainCam");
  cam->setNearClipDistance(5);
  cam->setFarClipDistance(25);
  cam->setAutoAspectRatio(true);
  cam->setFOVy(Ogre::Radian(0.3f));
  Ogre::SceneNode* camNode = scnMgr->getRootSceneNode()->createChildSceneNode();
  camNode->setPosition(15, 0, 0);
  camNode->lookAt(Ogre::Vector3(0, 0, 0), Ogre::Node::TS_PARENT);
  camNode->attachObject(cam);

  auto* viewport = ctx.getRenderWindow()->addViewport(cam);
  viewport->setBackgroundColour(Ogre::ColourValue::Blue);
  viewport->setMaterialScheme(Ogre::RTShader::ShaderGenerator::DEFAULT_SCHEME_NAME);

  // Create "walking" character
  Ogre::Entity* ent = scnMgr->createEntity(
      Ogre::MeshManager::getSingleton().load(character_mesh, scene_res_group_name));
  Ogre::SceneNode* boyNode = scnMgr->getRootSceneNode()->createChildSceneNode();
  boyNode->attachObject(ent);

  Ogre::AnimationState* walkAnim = nullptr;
  auto* allAnims = ent->getAllAnimationStates();
  if (allAnims) {
    for (auto it : allAnims->getAnimationStates()) {
      auto* anim = it.second;
      anim->setLoop(true);
      anim->setEnabled(false);
      anim->setTimePosition(0.0f);

  if (it.first == walk_anim_name) {
    walkAnim = anim;
  }
}
  }

  boyNode->setPosition(0, 0, 0);
  if (walkAnim != nullptr) {
    walkAnim->setEnabled(true);
  }

  // Handle user actions (keys)
  class KeyHandler : public OgreBites::InputListener
  {

  public:
    Ogre::SceneNode* m_camNode = nullptr;
    Ogre::AnimationState* m_walkAnim = nullptr;

bool keyPressed(const OgreBites::KeyboardEvent& evt) override
{
  if (evt.keysym.sym == OgreBites::SDLK_ESCAPE) {
    Ogre::Root::getSingleton().queueEndRendering();
  } else if (evt.keysym.sym == 'f') {
    // go far from scene
    if (m_camNode != nullptr) {
      m_camNode->setPosition(3015, 0, 0);
    }
  } else if (evt.keysym.sym == 'c') {
    // come close to scene
    if (m_camNode != nullptr) {
      m_camNode->setPosition(15, 0, 0);
    }
  } else if (evt.keysym.sym == 'm') {
    // animate the walking boy (step into animation)
    if (m_walkAnim != nullptr) {
      m_walkAnim->addTime(0.1f);
    }
  }
  return true;
}
  };

  KeyHandler keyHandler;
  ctx.addInputListener(&keyHandler);
  keyHandler.m_camNode = camNode;
  keyHandler.m_walkAnim = walkAnim;

  // Play
  ctx.getRoot()->startRendering();
  ctx.closeApp();

  return 0;
}

I think that any mesh with animation skeleton can work (i'll try to use one from the samples)

Incorrect initial state could be tackled playing with setTimePosition and/or enable/disable , force update ..., although i'm not really happy with doing applicative modifications to handle such problems.
But incorrect aspect after being far from camera is a big issue and much more difficult to handle from the application perspective : need to listen to 'far from camera' state, or listen to "unload" if it's really what this is...

bro
Kobold
Posts: 28
Joined: Fri May 20, 2022 6:15 am
x 5

Re: skeletal animation, wrong aspect at initialisation since nvidia 615.71.09

Post by bro »

for now, i give up ==> i go back to driver 610.57.04
( btw, it has been painfull since this 'old' version is rather difficult to find :-( )

i keep my little sample as a benchmark for the future.

Post Reply