Advertisement Jump to content
Sign in to follow this  
Alessandro Pozzer

Cannot Load 3d model using Assimp [Directx12]

This topic is 686 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys,

Im so sorry to post this but I am struggling with the implementation of a 3d model loader using Assimp and DirectX12 and I was wondering if you could give me an help doing it. I started from a project that - given vertices and indices - displays two cubes. From there I simply changed the InputLayout, the shaders and I used vertices, normals, texcoords and indices from assimp. 
Not the project failes and does not show anything. 

I upload here my main and modelLoader classes, and shaders. I really hope that you can give me some help. thank you. 



Here you could find the whole project:

Edited by alezz94

Share this post

Link to post
Share on other sites

I never used DirectX, so no idea what the code is expected to do, but I would say you moved too fast.


In any step that you take, you run the risk of making a mistake, and "it" does not work any more. Here, it sounds like you took 5 steps at the same time, if not more.

If it works after such a leap, you made big progress. If it fails (like now), you unfortunately have a big mess on your hands.



The general strategy is to break down the problem in smaller pieces, and check correctness of each of them in detail.

Lots of options exist how to do that, below are a few briefly explained.


1) Start with known input (as simple as possible), and work your way through all the steps from input to output, checking if the intermediate stored data matches with your expectations. This works very well if you understand what should be stored at each step along the way to get proper output (which may not be the case for you).

It really helps if you can relate between the working version and the non-working version. If you have points in both programs where the data should be the same (the easy option), or where the data can be converted back and forth (somewhat more tricky as conversions may introduce bugs), you can compare what gets actually stored in both, and see if it is equivalent.


You don't need to actually start at the input. You can also invent data that should exist somewhere, and inject it at that point in the program. Any code before the injection point has no influence on correctness, so if the injected data fails to work, there is a problem between the injection point and the output. Caveat here is that inventing data is a lot slower and more error-prone than having the computer generate it, which is why starting at the input is safer.


If you have enough knowledge, you can make bigger steps here, eg halfway. If data halfway matches the expectations, the first half is ok (for the example). Otherwise, at least the first part has a problem. Bigger steps however also require a better understanding how the data halfway relates to data at the input, which quickly explodes in complexity.

(You tried this trick from start to end for the program, which proved to be too big.)



2) Start with the working thing, and extend it (small step!) a bit towards the new, currently broken, thing. After the extension, it must work again.

In this case you greatly improved flexibility of the input, so likely the best approach is to start at the back of the chain, and extend the shader first. Make it work again, likely it needs some temporary data that you have to invent. Once you have that, extend a little more, and make it work again. Repeat until all extensions have been added.

If you extend an earlier step, the temporary data will disappear again, when you replace it by code that generates it. The big advantage here is that you have the expected result data, which you can compare with the real output of the code, which helps a lot in debugging.


Since you keep it working every cycle, if it fails to work after an extension, the fault is likely to be in that new code. This way you can concentrate on the problem area. You can also go back to the previous version, and try again, or compare data in the working version with data in the non-working version, and try to draw conclusions from it.



Good luck hunting them bugz!

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!