Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Regarding loading 3d meshes dynamically

  1. #11
    Advanced Member Frequent Contributor
    Join Date
    Apr 2010
    Posts
    720
    Hmm, I must be missing something, just to clarify, I'm suggesting:

    Code :
        // in the load thread
     
        // create context for loading
        hrcNew = wglCreateContext(hdc);
        wglMakeCurrent(hdc, hrcNew);
     
        // ...
     
        // make no context current
        wglMakeCurrent(hdc, NULL);
        wglDeleteContext(hrcNew);

  2. #12
    Advanced Member Frequent Contributor
    Join Date
    Mar 2009
    Location
    Singapore
    Posts
    800
    HI Carsten,
    I tried to run this code while it seemed to work however when i put glIntercept in, it triggers a debug breakpoint exception saying
    GLI | Function wglCreateContext is being called on a thread that does not have the main context
    I went to the wiki page here: http://www.opengl.org/wiki/OpenGL_and_multithreading which tells me that I need to create both my openGL rendering contexts in the main thread including a call to wglShareLists so I moved the context creation in the main thread like this
    Code :
    hrcOld = wglGetCurrentContext();
        hdc = wglGetCurrentDC();
        hrcNew = wglCreateContext(hdc); 
        BOOL error = wglShareLists(hrcOld, hrcNew);
        if(error == FALSE)
        {
             DWORD errorCode=GetLastError();
             LPVOID lpMsgBuf;
             FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
                NULL, errorCode, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),(LPTSTR) &lpMsgBuf, 0, NULL);
             MessageBox( NULL, (LPCTSTR)lpMsgBuf, L"Error", MB_OK | MB_ICONINFORMATION );
             LocalFree(lpMsgBuf);
             //Destroy the GL context and just use 1 GL context
             wglDeleteContext(hrcNew);
          }
          wglMakeCurrent(hdc, hrcOld);
    ...
    boost::thread loader(LoadModels);
    The LoadModels function first make the new context current. It then calls the glGetString function as in SOIL library but it fails again saying

    GLI | Function wglMakeCurrent is being called on a thread that does not have the main context

    So then I move the wglmakeCurrent for the second thread just before calling the loading thread but then glGetString function fails.
    GLI | Function glGetString is being called on a thread that does not have the main context

    Is it so that I cannot call a gl function in another thread?
    Regards,
    Mobeen

  3. #13
    Advanced Member Frequent Contributor
    Join Date
    Apr 2010
    Posts
    720
    GLI | Function wglMakeCurrent is being called on a thread that does not have the main context
    Hmm, that is a bit confusing to me; if it were not possible to call wglMakeCurrent() in a thread that does not already have a context, when would one be allowed call it at all?! Is it possible that glIntercept does not work with multiple contexts/threads?

    So then I move the wglmakeCurrent for the second thread just before calling the loading thread but then glGetString function fails.
    That, on the other hand, is somewhat expected, since you are making the wglMakeCurrent call now from the main thread and not the (not yet spawned) loader thread, your loader thread ends up not having a current GL context.

    FWIW, from my understanding of using multiple contexts and threads your first approach should work.

  4. #14
    Advanced Member Frequent Contributor
    Join Date
    Mar 2009
    Location
    Singapore
    Posts
    800
    OK thanks for the response Carsten. It might as well be that glIntercept does not support multithreaded code yet but I am not so sure.
    Last edited by mobeen; 04-09-2013 at 06:38 PM.
    Regards,
    Mobeen

  5. #15
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    mobeen, I'm curious as to how that mesh data organized? what format are you reading? Is it something custom?

    Just as a pointer, I'm loading a 60MB OBJ file with complete setup in a little over a second on Linux with my own loader. Granted, it's not doing any indexing, i.e. prepping the model for use as indexed geometry, at this point in time.

  6. #16
    Advanced Member Frequent Contributor
    Join Date
    Mar 2009
    Location
    Singapore
    Posts
    800
    Hi Thokra,
    Thanks for your reply, actually I am using obj format. Currently, using an obj loader that i found online. After digging in further, the conclusion is that the meshes dont take long to load, it is the textures that are taking more time (some of them take ~3 secs to load they are very big I wonder if SOIL is doing something underneath that is causing this). By the way all of these numbers are for debug builds. Release builds are much faster.
    Regards,
    Mobeen

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •