Open Ratall opened 2 years ago
Necrym59
commented
2 years ago Assimp is a seperated library its called upon as needed no need to a seperate a utility as well thats just double handling, perhaps at a later date it could be looked at as a standalone but the problems are mainly texture handling from what i can see not so much the importer library functionality and as that is going through changes itself, may be better to wait for an extraction and re-write.
Ratall
commented
2 years ago Yes Assimp is a separate library but the dll is at the moment necessary to run a standalone. Which indicates there is some if not all of the importer code in the standalone exe . Even if it is not executed it's presence increases the size of the code and creates more opportunities for conflicts. If the code was written sensibly in a object oriented or even modular manner, then hiving off the importer would be no problem but given the way error fixes in on e part of the code seem to create problems in unrelated areas I would guess this is a good old fashioned 1980 monolithic design. (though I haven't seem the design docs so I am just surmising this from what I have observed) The import should be a standalone module that you feed the mesh and texture data in a assimp supported format and it spits out a dbo, fpe and appropriately formatted textures at the other It should not be part of the game engine proper. As for double handling there would be none the utility would be called from the menu system and to most would appear to be just part of the Max IDE. After all Assimp is only a library and requires a wrapper to work so the code has to be somewhere to drive it putting it a separate utility will make it easier to maintain with out risking the main code particularly given Assimp is still evolving and I can image that bit would be beneficial to max to handle as many formats as possible.
One point is nothing should be in the standalone that is not needed to run the game. It should be a lean mean mighty machine.
Any logic that is functional separate and self contain should be a separate module where possible this particularly applies when you have a team of programmers with varying levels of skills, it gives individual coders something they can take ownership of with out other coders constantly changing things.
Sorry for rambling on but I really want max to succeed but as long as it remains one long piece of spaghetti code that only its creator can truly understand then it is bound to eventually implode. Making the importer a separate entity seemed an obvious way to start the change.
Anyway it is Lee and his crew that must decide.
leonardosedevic
commented
2 years ago I hope they work on those problems, because WITHOUT import, GG-max is useless !
There are a lot of issues with the importer that are outstanding at the moment
3505
3501
3460
3447
3435
3434
3395
3311
3390
3327
3244
3229
3217
3139
2941
2779
Giving the number a variety of problems it may be time that the import be separated from the main code, rewritten and made a callable utility . (it would also remove the need for assimp in the standalone).
If this was done correctly it would it could continue to work as it currently does with the addition possibility for it to be used as a standalone utility that could be integrated in to an artists pipeline.
The separated code should be easier to maintain.
I am starting to suspect cramming everything in to one ore two executables is making the code increasingly hard to maintain.
Splitting the none time critical elements off (i.e. parts not in the main game play loop) will not only make maintenance simpler in the long run but will also make it easier to tighten up the time critical areas, making them leaner faster and less resource hungry.