It's ensured because SpliFF ripped out my (tested, functional) loader in favor of his unfinished assimp code (not something I appreciate much, if only because it means I wasted my time).SeanHeron wrote:I may get back to you as to how to ensure that an .obj format model is loaded via assimp, and not via (kloots?) .obj loader
Integrating alternate model formats
Moderator: Moderators
Re: Integrating alternate model formats
Re: Integrating alternate model formats
You knew Spliff is working on ASSIMP when you wrote your obj loader.Kloot wrote:(not something I appreciate much, if only because it means I wasted my time).
Re: Integrating alternate model formats
With FOSS you simply never know if / when someone is going to deliver on their promises, and halting all development in a direction that may or may not be "claimed" elsewhere is foolish. Even moreso when the ETA is measured in years.
Apart from that there was no practical need to replace the OBJ loader, because assimp can be configured to not handle such models. Hence my annoyance.
Apart from that there was no practical need to replace the OBJ loader, because assimp can be configured to not handle such models. Hence my annoyance.
Re: Integrating alternate model formats
@Kloot - Sounds to me like a solvable issue? Maybe if you haven't done so, chat about it in the lobby, if you can catch each other?
If SpliFF is of the opinion that it'd be more work for him to handle those exceptions (not loading obj with ASSIMP), you could always offer him to put that together for him?
All out of the blue here, I just think talking can often help (sorry to suggest perhaps the obvious - and I hope you haven't already talked and had a spat on the issue...).
If SpliFF is of the opinion that it'd be more work for him to handle those exceptions (not loading obj with ASSIMP), you could always offer him to put that together for him?
All out of the blue here, I just think talking can often help (sorry to suggest perhaps the obvious - and I hope you haven't already talked and had a spat on the issue...).
Re: Integrating alternate model formats
@spliff
four points:
* something in your merge went wrong, the java-null-ais don't compile, it looks like you reverted some stuff, for example:
tools/unitsync/test/synctest.dpr was deleted in master branch but still exists in your branch, this are files which you didn't change for assimp.
found by:
git remote add spring git://github.com/spring/spring.git
git fetch spring
git diff spring/master
in master the java ais compile fine... i don't know, what happens when merging from the 0.82 branch to master branch, maybe that was the problem :-/
* the testmod isn't displayed in the list of games
* you should convert dos-line endings to unix-line endings in rts/lib/assimp/
* please add a README_SPRING in rts/lib/assimp/ with a "what was changed in assimp to made it work for spring" or so... see rts/lib/lua/README_SPRING for an example)
four points:
* something in your merge went wrong, the java-null-ais don't compile, it looks like you reverted some stuff, for example:
tools/unitsync/test/synctest.dpr was deleted in master branch but still exists in your branch, this are files which you didn't change for assimp.
found by:
git remote add spring git://github.com/spring/spring.git
git fetch spring
git diff spring/master
in master the java ais compile fine... i don't know, what happens when merging from the 0.82 branch to master branch, maybe that was the problem :-/
* the testmod isn't displayed in the list of games
* you should convert dos-line endings to unix-line endings in rts/lib/assimp/
* please add a README_SPRING in rts/lib/assimp/ with a "what was changed in assimp to made it work for spring" or so... see rts/lib/lua/README_SPRING for an example)
Re: Integrating alternate model formats
@Kloot. I only took out the OBJ loader because the engine can't handle the case where two model loader classes compete for the same file extension. We could provide a switch to toggle them or use your OBJ loader exclusively but that would mean documenting and supporting two seperate metadata formats (or merging formats) and dealing with all the confusion that would entail. I'm also not aware of any published games using your OBJ loader so backwards compatibility isn't a factor.
There's no doubt the Assimp loader needs a lot more work and testing but it's questionable whether keeping a stopgap is the right way to go.
I realise you put a lot of work into it but it was far from wasted. A significant portion of the Assimp loader is code you wrote back when you and BrainDamage first got it working, or code based on or copied directly from ObjParser. There's nearly as much of your work in the Assimp parser as mine.
The dedicated OBJLoader can be put back easily enough but I don't think that's the right decision in the long run.
I would have communicated with you more but our timezones make it difficult. I will be at the next dev meeting and happy to put all sensible options on the table.
@abma
I've been having the Java OO compile issue for a long time. I assumed it was because I run OpenJava rather than the Sun flavour. I wouldn't have touched the Java or AI code directly so if it's something I've changed it must be in the CMake setup.
I don't know why the Assimp test mod won't display. It works on mine. I'll check the archive.
I heard git converted line endings automatically?
I wrote a README_SPRING, it was in rts/lib/assimp/ but I seemed to have forgotten to put it back when i updated Assimp to 2.0. I've copied it back now.
I'll go through and try to identify any files that may have been merged incorrectly.
There's no doubt the Assimp loader needs a lot more work and testing but it's questionable whether keeping a stopgap is the right way to go.
I realise you put a lot of work into it but it was far from wasted. A significant portion of the Assimp loader is code you wrote back when you and BrainDamage first got it working, or code based on or copied directly from ObjParser. There's nearly as much of your work in the Assimp parser as mine.
The dedicated OBJLoader can be put back easily enough but I don't think that's the right decision in the long run.
I would have communicated with you more but our timezones make it difficult. I will be at the next dev meeting and happy to put all sensible options on the table.
@abma
I've been having the Java OO compile issue for a long time. I assumed it was because I run OpenJava rather than the Sun flavour. I wouldn't have touched the Java or AI code directly so if it's something I've changed it must be in the CMake setup.
I don't know why the Assimp test mod won't display. It works on mine. I'll check the archive.
I heard git converted line endings automatically?
I wrote a README_SPRING, it was in rts/lib/assimp/ but I seemed to have forgotten to put it back when i updated Assimp to 2.0. I've copied it back now.
I'll go through and try to identify any files that may have been merged incorrectly.
Re: Integrating alternate model formats
After doing a big merge/rebase, before going on, always do something like this:
and make sure that your changes are the only ones that show up.
you can do the same on github if you have both branches at the right commit in the same repository, for example with:
https://github.com/SpliFF/spring/compar ... les_bucket
Code: Select all
git diff --color --stat origin/master spliff/assimp-2.0you can do the same on github if you have both branches at the right commit in the same repository, for example with:
https://github.com/SpliFF/spring/compar ... les_bucket
Re: Integrating alternate model formats
Thanks hoijoi, that's quite a useful command. I have no idea how those AI files got altered but I know it has something to do with the way I merged the spring master branch. There's obviously a git subtlety at play here. I know exactly which files don't need changing so if I check them out from origin master I should end up with a clean branch right?
For all testers and developers, be aware that there is a known issue with pre-game or menu lockups under win7 64bit. I don't know what's causing it and furthermore I don't have a win7 to test on. Would greatly appreciate anyone with this distro providing any insight into possible causes.
There is a new version of AssimpTest.sd7 with fixed archive format (uses a non-solid metafile).
For all testers and developers, be aware that there is a known issue with pre-game or menu lockups under win7 64bit. I don't know what's causing it and furthermore I don't have a win7 to test on. Would greatly appreciate anyone with this distro providing any insight into possible causes.
There is a new version of AssimpTest.sd7 with fixed archive format (uses a non-solid metafile).
Re: Integrating alternate model formats
Yeah, you can just copy the files over from master that are changed in your branch, but should not be, and make a new commit.
That is not a nice/clean solution of course (ugly history), and we probably want to do it the clean way before really merging your changes into master. We want to keep your history and the one of master both intact.
Maybe the best thing to do would be, to find which of your merges went wrong, and then git rebase -i <hash-of-previous-commit> on that one, fixing the merge commit. that should also be pretty hassle-less.
That is not a nice/clean solution of course (ugly history), and we probably want to do it the clean way before really merging your changes into master. We want to keep your history and the one of master both intact.
Maybe the best thing to do would be, to find which of your merges went wrong, and then git rebase -i <hash-of-previous-commit> on that one, fixing the merge commit. that should also be pretty hassle-less.
Re: Integrating alternate model formats
Ok, I've created a new branch called assimp-rebuild and applied the older assimp-1.1 branch on top of the latest spring master to bring in the history of Kloot and BD's commits. I've then applied the final version of my changes on top.
This loses some of my later commit history but should result in an overall cleaner history without any kinks (since this time I've bypassed the part where the 0.86.2 release branch was merged).
I've tested the build on linux. Win32 should work as well since the branch is nearly identical to the old assimp-2.0
Hopefully this can be merged soon before anything happens in master to break it again.
This loses some of my later commit history but should result in an overall cleaner history without any kinks (since this time I've bypassed the part where the 0.86.2 release branch was merged).
I've tested the build on linux. Win32 should work as well since the branch is nearly identical to the old assimp-2.0
Hopefully this can be merged soon before anything happens in master to break it again.
Re: Integrating alternate model formats
Code: Select all
git diff --stat --color master spliff/assimp-rebuild
Assimp adds 443 files with extensions .(c|cpp|h|hpp).
I made some minor changes to CMake build files:
https://github.com/hoijui/spring/commit ... 8a67d780df
you may include that commit in your branch.
as i had a look at the CMake files, i stumbled over this:
That is not fully correct, as DEBUG should not always be defined for example. but the more important thing is: does this not conflict with sync? as in, cause slightly different dimensions of models/collision volumes.rts/lib/assimp/CMakeLists.txt wrote: # Spring's compiler flags break assimp (especially -fsingle-precision-constants)
SET(CMAKE_CXX_FLAGS "-g -c -DDEBUG -D_DEBUG -gstabs")
i remember it being mentioned already by you, but i forgot the current status, eg if there have already been sync tests among different systems.
related:
these are the only two places where the string streflop appears under rts/lib/assimp/, so these statements seem outdated.rts/lib/assimp/README_SPRING wrote: 4.) <math.h> includes changed to "streflop_cond.h".
5.) Prepend streflop:: to math functions to resolve ambiguous calls.
i compiled all targets (with the changes in my commit) on my gentoo Linux 64bit machine with GCC 4.4.5.
/give all worked fine with spring.exe.
looking good so far!
Re: Integrating alternate model formats
Thanks hoijoi, i've merged your commit
You're right about the compiler flags. That's really a temporary hack until I can figure out how to remove only the problematic flags. I probably need to grep/replace them out of the original string.
As far as sync goes I was told by the developers of assimp that models should be returned reliably regardless of math library or compiler settings but we won't really know until it's tested.
As far as the streflop comments it looks like I didn't do that in the version 2.0 of the SDK. If we get sync issues though it may be necessary to restore those changes. For now i'll mark those lines as potential requirements.
The library appears to be working without BoostWorkaround now. Probably due to Spring catching up to boost 1.42. Rather than comment those lines out I'm thinking it'd probably make sense to leave them in and wrap it in "if (BoostWorkaround)" for testing purposes or in case we need it later.
There have been a few commits in the official assimp repo since the 2.0.863 SDK release but none of them appear critical enough to bother updating the lib just yet. I'd consider updating in a few months especially once the python importer improves.
I've left Kloot's OBJ loader in but commented out one line in IModelParser which actually loads and binds it to .obj. If it turns out that reverting assimp or providing a switch is desirable then it should be fairly easy.
Finally, sorry about the inconsistent indenting in some places. It looks fine in Code::Blocks but not on github. I always use tabs but there seems to be some kind of issue with tab width and tabs being converted to spaces. I don't know if it's git or code::blocks that's doing it.
You're right about the compiler flags. That's really a temporary hack until I can figure out how to remove only the problematic flags. I probably need to grep/replace them out of the original string.
As far as sync goes I was told by the developers of assimp that models should be returned reliably regardless of math library or compiler settings but we won't really know until it's tested.
As far as the streflop comments it looks like I didn't do that in the version 2.0 of the SDK. If we get sync issues though it may be necessary to restore those changes. For now i'll mark those lines as potential requirements.
The library appears to be working without BoostWorkaround now. Probably due to Spring catching up to boost 1.42. Rather than comment those lines out I'm thinking it'd probably make sense to leave them in and wrap it in "if (BoostWorkaround)" for testing purposes or in case we need it later.
There have been a few commits in the official assimp repo since the 2.0.863 SDK release but none of them appear critical enough to bother updating the lib just yet. I'd consider updating in a few months especially once the python importer improves.
I've left Kloot's OBJ loader in but commented out one line in IModelParser which actually loads and binds it to .obj. If it turns out that reverting assimp or providing a switch is desirable then it should be fairly easy.
Finally, sorry about the inconsistent indenting in some places. It looks fine in Code::Blocks but not on github. I always use tabs but there seems to be some kind of issue with tab width and tabs being converted to spaces. I don't know if it's git or code::blocks that's doing it.
Re: Integrating alternate model formats
i think that one should do (did not test):
doc: http://cmake.org/cmake/help/cmake-2-8-d ... and:string
i did not see wrong indenting, but ... just correct it if you know where it is, no big deal. gitk and git-gui use 8 spaces for a tab by default, i think. i usually have 4 in all my editors. that is a good way to see indenting errors before you commit them.
the rest of your post sounds good!
yeah, as you seem to do it anyway, we should keep all the libs (eg assimp) on the same version as long as possible; as long as no big new feature we need, and no important bug fix is available.
Code: Select all
string(REPLACE "-fsingle-precision-constants" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")i did not see wrong indenting, but ... just correct it if you know where it is, no big deal. gitk and git-gui use 8 spaces for a tab by default, i think. i usually have 4 in all my editors. that is a good way to see indenting errors before you commit them.
the rest of your post sounds good!
yeah, as you seem to do it anyway, we should keep all the libs (eg assimp) on the same version as long as possible; as long as no big new feature we need, and no important bug fix is available.
Re: Integrating alternate model formats
I've updated the assimp cmakelists.txt to use string replace on the CXX flags and added ENABLE_BOOST_WORKAROUND as a global cmake var. Compiled and ran ok under gentoo linux 64bit.
I forgot to mention. EFX.h wasn't finding "al.h" on my system. I deleted the FindOpenAL.cmake in spring from my branch because the one included with my system CMake 2.8 is newer. However this may have to be put back for users of older CMake builds. I don't know.
In the end the problem was only resolved by deleting my cmake cache but I don't know if the spring version of FindOpenAL was the original cause of the fault or not.
EDIT: Nevermind, the script is there now. I must have copied it back or pulled it in. I just don't remember doing that.
On a related note the cmake scripts have been complaining about the GLU script being depricated by the OpenGL script for almost a year now. Perhaps it's time to replace it?
I forgot to mention. EFX.h wasn't finding "al.h" on my system. I deleted the FindOpenAL.cmake in spring from my branch because the one included with my system CMake 2.8 is newer. However this may have to be put back for users of older CMake builds. I don't know.
In the end the problem was only resolved by deleting my cmake cache but I don't know if the spring version of FindOpenAL was the original cause of the fault or not.
EDIT: Nevermind, the script is there now. I must have copied it back or pulled it in. I just don't remember doing that.
On a related note the cmake scripts have been complaining about the GLU script being depricated by the OpenGL script for almost a year now. Perhaps it's time to replace it?
Re: Integrating alternate model formats
seems to work! :-D
an idea why the model is red? (i think its because the texture can't be loaded?)
but sometimes i get this crash at start:
*** glibc detected *** /home/abma/local/spring/assimp/bin/spring: realloc(): invalid next size: 0x00007f3294dc9b70 ***
http://pastebin.com/Xgg4EYH5
(could be also an issue in spring-master...)
an idea why the model is red? (i think its because the texture can't be loaded?)
but sometimes i get this crash at start:
*** glibc detected *** /home/abma/local/spring/assimp/bin/spring: realloc(): invalid next size: 0x00007f3294dc9b70 ***
http://pastebin.com/Xgg4EYH5
(could be also an issue in spring-master...)
Re: Integrating alternate model formats
The red is presumably teamcolor so either you are missing a texture or the alpha channel is the wrong way round (that could happen if you copied an existing s3o primary texture). There is is a option you can add to the models metafile to invert the teamcolor channel (invertteamcolor=true/false) but that only works for non-DDS textures. The default value of invertteamcolor is true for Assimp models to allow using standard textures from other sources that have no transparency.
The crash is probably unrelated to assimp, from your dump it appears to be in the sound thread and may be related to new EFX stuff in master. Assimp doesn't really do much until you actually load a model.
The crash is probably unrelated to assimp, from your dump it appears to be in the sound thread and may be related to new EFX stuff in master. Assimp doesn't really do much until you actually load a model.
Re: Integrating alternate model formats
just wondering, did you see my post in the "ANN: Universal model support. Testers wanted" thread?
http://springrts.com/phpbb/viewtopic.ph ... 0&start=20
http://springrts.com/phpbb/viewtopic.ph ... 0&start=20
knorke wrote:does not start at all for me.
no error, no infolog, when clicking spring.exe cursor just turns to hour glass for 0.5 seconds and nothing happens.
i did put in the mod and some map (alien desert)
win xp
amd 2800
geforce 6800
1 gb ram
*wild guess* needs SSE2?
Re: Integrating alternate model formats
yeah sorry, the windows build is old. i was waiting till it got merged to the official spring repo to do a rebuild but that hasn't happened yet. Wait a bit longer, otherwise I'll just do a seperate build again.
Re: Integrating alternate model formats
merged!
many thanks to jk, hoijui and especially to SpliFF! :)
i found one issue/crash after merge by my dreaded "/give all /give all 1"-test :-/
http://springrts.com/mantis/view.php?id=2393
normal installer from buildbot:
http://springrts.com/dl/buildbot/defaul ... a562a5.exe
or try the online installer (very experimantal):
http://springfiles.com/spring/spring-ba ... -installer
(its no april-fool :)
many thanks to jk, hoijui and especially to SpliFF! :)
i found one issue/crash after merge by my dreaded "/give all /give all 1"-test :-/
http://springrts.com/mantis/view.php?id=2393
normal installer from buildbot:
http://springrts.com/dl/buildbot/defaul ... a562a5.exe
or try the online installer (very experimantal):
http://springfiles.com/spring/spring-ba ... -installer
(its no april-fool :)
Re: Integrating alternate model formats
Thanks abma, that's great!
Credit is due Kloot and BrainDamage as well. Both made very significant contributions to make this happen.
Looking at your crash log it seems like a projectile was created that has no "ownerId". I'm not sure that is related to Assimp at all but perhaps there's a missing piece or model number somewhere.
Credit is due Kloot and BrainDamage as well. Both made very significant contributions to make this happen.
Looking at your crash log it seems like a projectile was created that has no "ownerId". I'm not sure that is related to Assimp at all but perhaps there's a missing piece or model number somewhere.