lwjglgamedev/lwjglbook-leg

Separate FBX Animation Files

Quadrocompile opened this issue · 6 comments

Hi,
first of all a big thank you for providing these awesome tutorials!
I ran into an issue with chapter 27 (Assimp). I have a bundle of FBX files that consist of a base file which contains the mesh, texcoords and bone hierarchy, and a set of files where each file contains the frames for one animation (e.g. walking, running,...). It is possible to load them with the code with some minor changes, but the application crashed without any exception or output after the rendering method. The files itself seem to be working fine, it is poissible to load them into unity, view them in a 3D modelling software and I even managed to render them with my low level C++/DirectX code some years ago. I'm desperate to get this working but have no clue what might be the problem here (due to the lack of any error message whatsoever). Any help would be greatly appreciated.
Best,
Phil

Hi,

Thanks for your comments. Two ideas:

  • Have you tried using RenderDoc to debug what is happening? I cannot stress enough how wonderful tool RenderDoc is, amazing.
  • Maybe you can share also the models so I can check them in my spare time.

Regards.

Thank you for bringing RenderDoc to my attention. I worked with a similar app on my DirectX projects and I'll definetly use it in the future. However, it does not help me with the current problem because it only captures the first two frames (glClear and SwapBuffer) and then the openGL application crashes.

I've forked the code and pushed my adjustments to the debug-fbx branch (https://github.com/Quadrocompile/lwjglbook)

I added two fbx files, both from the same studio. I reached out to them and they confirmed that both files were created by the same program (3D max) and that they share the same fbx file version.

Module:
chapter27/c27-p2

Entrypoint:
org.lwjglb.game.Main

Code for loading the models:
org.lwjglb.game.DummyGame

Adjustments:
org.lwjglb.engine.Utils@ioResourceToByteBuffer(String resource, int bufferSize)
Added default texture

org.lwjglb.engine.loaders.assimp@buildTransFormationMatrices(AINodeAnim aiNodeAnim, Node node)
Added statement to ignore missing rotaion keys (e.g. if an animation frame only has translation keys)

Error description:
org.lwjglb.engine.GameEngine@render()
l. 114 gameLogic.render(window);
l. 115 window.update();

The application crashes asynchronously after l. 114. E.g. set a breakpoint at line 115. The application will run until the breakpoint and halt. The application crashes shortly after, even while halted. With no breakpoint the application will run and crash at a random point shortly after launch.

Two years ago I managed to load and render the fbx files that are not working in this instance with my own DirectX10/C++ code, which also used Assimp to load the model. However, since the animation fbx files mainly contain the animation frames my setup differs slightly from this one here. What I did back then was to load the mesh and bone hierarchy from the base fbx file and only the animation keyframes from the animation fbx files. I noticed that the skeleton of the animation files did not exactly match that of the base model and coped with it by replacing "missmatches" with identity offset matrices.
Model viewer can load and display the file correctly (e.g. https://www.creators3d.com/online-viewer), so the files seem to be valid.

It seems to me like a memory problem, some used memory may have been de-referenced. The GC frees it and the program crashes when it tries to accces it (this explains the randomness). I've sent you and email to check if you can share the model with me. Have you tried to execute it with -Dorg.lwjgl.util.Debug=true or -Dorg.lwjgl.util.DebugAllocator=true ? (you can check the infor here https://github.com/LWJGL/lwjgl3-wiki/wiki/2.5.-Troubleshooting).

I've had problems in the past with assimp freeing resources too early (although they should not be used any more, it crashed the program). I'm currentñy working on samples for a new Vulkan book and had a lot of headaches with that.

I hope it helps.

Thank you very much for the input. It does indeed sound like a memory problem. I'd bet it's something shader related but without any meaningful exception I don't even know where to start looking for this. I've tried everything from the troubleshooting page when this problem occurred. There is no output with the DebugAllocator VM option, and the Debug option just prints the libraries on startup and nothing except that.

Ok, Problem solved. The issue was that, for that model, texture coordinates were not being created. This created inconsistencies in the memory structures in the assigned for the meshes which made the driver to crash. The problem is solved by creating the placeholder for texture coordinates for each of the vertices (same number of items).