Yes, indeed, it’s better like this, thank you!

I might take another look to see if we could store the assimp properties that are created and destroyed on each load, but it’s perfectly fine like this!

Not really the primary reason to avoid it, but this scaling also does make model sizes inconsistent between R3D and Raylib.

Sponza was actually 100 times bigger when loaded with assimp than with raylib, the dimensions still didn’t match but were much closer, but anyway, I think it’s better that way too

I'd imagine that could be from assimp handling scene data that Raylib doesn't, but that's just a guess. Which again makes overriding scaling likely to cause more problems than it solves. Maybe at least when the user hasn't set a unit scale nothing should be done instead of forcing it to be 1.

I was scratching my head for a bit wondering why my models were exactly 100 times smaller than they should be.

Maybe at least when the user hasn't set a unit scale nothing should be done instead of forcing it to be 1.

That could be better indeed, I’ll review that tomorrow regarding these properties, thanks for that, and sorry for making you scratch your head x)

@grunthon I’m posting this here, as there’s no better place at the moment. I’ve reworked the properties management, they’re now stored globally in R3D.state.loading.aiProps. They’re created at initialization and destroyed when R3D shuts down.

After checking aiImportFileExWithProperties and the rest of the implementation, the default properties, when not modified, seem to be the same applied as when passing NULL for the properties, only an additional copy is made, so this setup should be fine as is.

See: 5c04892

That seems good. When I have some time I'd like to look more into exactly how the assimp properties work internally.

Further off topic but I saw the new release and roadmap, which is nice. Something else I plan to start looking into is loading models on multiple threads, which would be a big improvement for real world usage. I'm a lot more familiar working with multiple threads in C++ than C, but I'll make a new discussion or something if and when I can come up with anything.

Further off topic but I saw the new release and roadmap, which is nice. Something else I plan to start looking into is loading models on multiple threads, which would be a big improvement for real world usage. I'm a lot more familiar working with multiple threads in C++ than C, but I'll make a new discussion or something if and when I can come up with anything.

I had already thought about it, I don’t think forcing a specific model for asynchronous loading is the best solution, but simply allowing deferred upload would be really good

Originally, I added a bool upload parameter to R3D_LoadModel to indicate whether the upload should happen immediately or not, but this turned out to be complicated for materials

The reason is that the vertex data stays in RAM, which is fine, but keeping images there is not a good idea, so there should be a way to separate mesh loading from material loading

Anyway, if you’d like to open an issue or start a discussion about this, I’m open to talking it through

Also, I’m not a purist, if you have a solution to a problem that’s easier to integrate in C++, that’s not an issue for me