Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

SimpleOpenGL dwarf stays untexturized

Help
2010-06-09
2013-06-03
  • Martin Walser
    Martin Walser
    2010-06-09

    Hi,

    Huuu… not too easy to understand this library.

    Finally I found the sample code … but the dwarf stays untexturized.

    What might have gone wrong there?

    log says:

    Error, T4436: Unable to open file "../../test/models/X/dwarf.x".
    Info,  T4436: Found a matching importer for this file format
    Info,  T4436: Import root directory is '../../../../test/models/X\'
    Info,  T4436: Entering post processing pipeline
    Info,  T4436: Points: 0, Lines: 0, Triangles: 2, Polygons: 0 (Meshes, X = remove
    d)
    Warn,  T4436: Simplified dummy tracks with just one key
    Skipping one or more lines with the same contents
    Info,  T4436: JoinVerticesProcess finished | Verts in: 5688 out: 2001 | ~64.8%
    Info,  T4436: Cache relevant are 2 meshes (1896 faces). Average output ACMR is 1
    .150844
    Info,  T4436: Leaving post processing pipeline

     
  • Kim Kulling
    Kim Kulling
    2010-06-09

    The solution is pretty simple: the SimpleOpenGL-viewer does not provide texturing. Maybe we should add this feature as well. I will put it on my ToDo-list.

    Kimmi

     
  • Martin Walser
    Martin Walser
    2010-06-09

    Hey kimmi. :)

    Awww….

    I thought the apply_material function would do that.
    (Really… don't get it yet, how the library works)

    Thought the error above would be somehow the
    cause.

    Hmm. Where might I find a working texturing
    example?

     
  • Kim Kulling
    Kim Kulling
    2010-06-10

    Hi Samhayne,

    currently we don't have a simple OpenGL-Texture-Code-example in our repository. The applyMaterial-function just sets the components diffuse / ambient etc. colors.
    But to apply textures to your code you need an image-library like DevIL. OpenGL itself does not support the import of any image formats directly. You can use GLU / GLUT to do that also. Search for the Nehe-Tutorials-Texturing. There you can see an example how to load images and create valid OpenGL textures with them.
    If you got these you have to set the texture on every material with a valid texture for a new mesh:

      glEnable( TetxureType );
      glBindTexture( TextureType, textureId );

    I will try to adapt our code example to point this out.

    Kimmi

     
  • Martin Walser
    Martin Walser
    2010-06-26

    Hi kimmi,

    Phew… found this to be a tough one.

    Got it to work though and made a little example app out of it
    based on NeHe's OpenGL Tut Framework and code from the SimpleOpenGL example.

    http://www.stud.uni-karlsruhe.de/~utbv/SimpleTexturedOpenGL.7z

    Should just work when put in the samples directory.
    dlls and DevIL are included… though the dlls in the release and debug
    folders can be deleted as they should be copied in in the post-process build.
    Just kept them in… just in case.

    Maybe you'd want to add it to your samples dir… the code's a bit wild though,
    I guess…. yet, I would have loved it as a starting point.

    Grüße nach Lübeck! ;)

     
  • I really like it! Would imo be nice to have it in Assimp.

    We just need to integrate it into the ./samples/workspaces/vcN solution. Or , maybe, take the easier way and get rid of one global solution for all samples at all. Any opinions?

    Bye, Alex

     
  • Fine!

    I just added the new sample to Assimp. Would you mind double-checking whether I missed something? I did some minor changes (i.e. directory layout, location for binaries).

    Also, under which name would you like to appear in the CREDITS?

    Bye & thanks,
    Alex

     
  • Martin Walser
    Martin Walser
    2010-06-30

    Hey Aramis!

    Glad I can contribute something to your project. :)

    Uhh… credit me with… can't decide… Martin Walser (Samhayne).

    Checked the current assimp out from svn… but the path to the dwarf model and texture is no longer correct.

    Fixed that and also removed some comments and (minor) memory holes.
    Also added a larger comment on top with some notes and a credit to NeHe
    (change it at will!).

    You can get the new cpp here:
    http://www.stud.uni-karlsruhe.de/~utbv/model_loading.cpp

    changes:

    ===

    scene = new aiScene(); (line 117)

    to:

    remove line (memory hole and not even needed)

    ===

    std::string texturepath = "../../test/models/X/";

    to:

    std::string texturepath = "../../../test/models/X/";

    ===

    if (!Import3DFromFile("../../test/models/X/dwarf.x")) return 0;

    to

    if (!Import3DFromFile("../../../test/models/X/dwarf.x")) return 0;

    ===

    cleanup of textureIds array added at main shutdown:

    // *** cleanup ***

    // clear map
    textureIdMap.clear(); //no need to delete pointers in it manually here. (Pointers point to textureIds deleted in next step)

    // clear texture ids
    if (textureIds)
    {
    delete textureIds;
    textureIds = NULL;
    }

    // *** cleanup end ***

    ====

    By the way… I also made notices about my experience when trying to make the other example run:

    Maybe you'd want to change that to ease things up for new users:

    - sample won't build => Linker needs to point to "..\..\..\..\lib\assimp_debug-dll_win32".
    Not "..\..\..\..\lib\assimp_debug_win32"

      There is a lib in there but linking will result in errors:

      assimp.lib(BaseImporter.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::_String_iterator<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::erase(class std::_String_const_iterator<char,struct std::char_traits<char>,class std::allocator<char> >)" (__imp_?erase@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE?AV?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@@Z)
    assimp.lib(BaseImporter.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::_String_iterator<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::erase(class std::_String_const_iterator<char,struct std::char_traits<char>,class std::allocator<char> >,class std::_String_const_iterator<char,struct std::char_traits<char>,class std::allocator<char> >)" (__imp_?erase@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE?AV?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@0@Z)
    assimp.lib(ColladaLoader.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl std::ctype<char>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@D@std@@SAIPAPBVfacet@locale@2@PBV42@@Z)
    assimp.lib(BVHLoader.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl std::ctype<char>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@D@std@@SAIPAPBVfacet@locale@2@PBV42@@Z)
    assimp.lib(ColladaParser.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl std::ctype<char>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@D@std@@SAIPAPBVfacet@locale@2@PBV42@@Z)
    assimp.lib(XFileParser.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl std::ctype<char>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@D@std@@SAIPAPBVfacet@locale@2@PBV42@@Z)
    C:\libs\assimp svn\trunk\samples\workspaces\vc8\..\..\SimpleOpenGL\SimpleOpenGL.exe : fatal error LNK1120: 3 unresolved externals

    - Post built in debug copies wrong dll
    Should be: copy "$(SolutionDir)..\..\..\bin\assimp_debug-dll_win32\Assimp32d.dll" "$(SolutionDir)..\..\SimpleOpenGL\"
    (should be 'debug', not 'release' and put in quotes just in case the SolutionDir contains spaces)

    Quotes in release mode would be better too:
    copy "$(SolutionDir)..\..\..\bin\assimp_release-dll_win32\Assimp32.dll" "$(SolutionDir)..\..\SimpleOpenGL\"

     
  • Ummm … I made the release build copy the created executable to ./samples/bin and changed the paths and the debugger's workin directory accordingly, but forgot about debug. I'll fix that (+take the new model_loading.cpp), thanks for noticing!

    Bye, Alex

     
  • Martin Walser
    Martin Walser
    2010-06-30

    ahh… okay. :)
    I only tried the debug mode, right.
    I saw that you removed the path for the working dir completely but thought that was intentional.

     
  • OK, should be mostly fine now. Launching from the IDE results in an error of course, because the debugger settings are iirc in the vcproj.user file, not the vcproj file. I'll look if I can find a better solution - for the moment, the ability to read the README is a requirement for getting the samples running.

    Bye, Alex

     
  • Martin Walser
    Martin Walser
    2010-07-02

    Hey Alex.

    Oh my!
    Wasn't aware that working folder settings are defined in the user's .vcproj file.

    Thought something was wrong when checking it out … but yeah… the "..\..\bin" path was missing in the working folder settings
    …which you can't make to be automatically set.

    Pretty… odd MS does want that.

    It seems to be possible to define some macro to auto-setup the working dir in a pre-build event… but this
    smells like a possible source of confusion later.

    Sorry you have so much trouble integrating it in your sample structure.

     
  • No trouble at all, but because this is the second sample I'd just like to establish a 'standard' for any future samples. I thought putting the created binaries all in one directory would be nice, but after all it doesn't seem too nice thanks to this vcproj.user thing :-)

    Maybe I'll change that back, provided nobody else knows a simple workaround to avoid the problem.

    Bye, Alex