I’m finding some strange behaviour with panda only in release mode when loading models. They seem not to be loaded properly because the meshes appear distorted and they are drawn in solid black. However, everything is rendered fine in debug mode.
In the beginning I was missing some info because I didn’t have a console. I changed that, and I found that I had an assertion failure:
Assertion failed: Thread::get_current_thread() == Thread::get_main_thread() at line 502 of c:\panda_src\panda3d1.6.2\panda\src\pgraph\renderAttrib.cxx
Known pipe types:
wglGraphicsPipe
(all display modules loaded.)
Loading panda-model
Loading panda-model
Loading panda-model
It happends in RenderAttrib::init_attribs() because Thread::get_current_thread() is different than Thread::get_main_thread(). But the most strange thing is that in debug mode they are the same.
In my application Panda is actaully inside a module that’s an static lib. The panda-related code is run in a separate thread, where I initialize stuff and run the main loop with framework.doframe(). I also allow access from other threads to manage the scene (load models, change camera positions, etc).
I’ve tried to move framework.open_framework( m_argc, m_argv ) to my-app-main-thread scope. There both pointers are the same and the assertion failure goes away, but it behaves the same way in the end. If I also move window creation or all the code but render loop to the main thread scope, execution is then aborted in framework.doframe(Thread::get_current_thread()).
I’m using boost::threads with panda with true threads, but it also happens if support-threads #f is set. I tried 1.7.0 with same results (not sure if I set simple_threads to undef there). But, as I said, in 1.6.2 in debug mode it does work fine
I had a similar problem some time ago, I thought it was fixed, but when I retook the graphic part I found that the strange models thing actually wasn’t solved
What do you mean, precisely, by “release mode”, and what do you mean, precisely, by “debug mode”?
Are you running against the standard Panda3D library provided here (which is compiled in a modified “release mode”, with NDEBUG not defined), or are you building your own version of Panda3D? If you are building your own, are you certain that your Panda3D compilation settings precisely match those of your application?
Getting Release/Debug settings wrong, or getting NDEBUG/not NDEBUG settings wrong, can result in strange behaviors such as what you describe. (Though usually it just results in a crash.)
Edit: my apologies, I see that you are compiling Panda with true threads enabled, and therefore you must be compiling your own. Still, the question remains: precisely how did you build Panda?
I just set HAVE_THREADS to 1 and SIMPLE_THREADS to UNDEF in makepanda.py, and then compile twice, first in debug and then in release.
I copy both builds in separate folders that I add to my project:
c:\etc\project\extern\panda3D\debug
and
c:\etc\project\extern\panda3D\release
Finally, I include and link them to my lib and application projects with these settings:
[GraphicModule:]
OutputDirectoy: …\bin
Configuration type: .lib
MFC: USe standar windows libraries
ATL: Not using ATL
Character set: Unicode (tried not set, but I still used it in all other modules and main app)
CLR: No CLR support
Whole program opt: Use link time code generation
Additional include directories:
.; …\src; …\extern\include;
…\extern\panda3d\built\include;
…\extern\panda3d\built\python\include;
…\extern\boost;
…\extern\include\wxwidgets\msvc;
…\extern\include\wxwidgets;
…\extern\sfml\include
Preprocessor definitions: WIN32;
Runtime library multi-threaded dll (/MD)
Additional dependencies:
libpandaexpress.lib libp3framework.lib libpanda.lib libpandafx.lib libp3dtool.lib libp3dtoolconfig.lib libp3pystub.lib libp3direct.lib sfml-audio-s.lib sfml-system-s.lib
Additional lib directories:
…\bin; …\extern\lib;
…\extern\panda3d\built\lib;
…\extern\panda3d\built\python;
…\extern\panda3d\built\python\Lib;
…\extern\panda3d\built\python\libs;
…\extern\boost\lib;
…\extern\sfml\lib\vc2008;
[some other lib modules…]
…
[MainApp]
OutputDirectoy: …\bin
Configuration type: .exe
MFC: USe standar windows libraries
ATL: Not using ATL
Character set: Unicode
CLR: No CLR support
whole program opt: Use link time code generation
Environment: PATH=%PATH%;…\extern\bin;
…\extern\bin\opencv;
…\extern\panda3d\built\bin;
…\extern\panda3d\built\python;
…\extern\panda3d\built\python\DLLs;
…\extern\sfml\extlibs\bin;
…\etc\BBDD\PostgreSQL\bin;
…\extern\debea\vc_release_static;
Additional include directories:
.; …\src;
…\extern\include;
…\extern\panda3d\built\include;
…\extern\panda3d\built\python\include;
…\extern\include\opencv;
…\extern\include\wxwidgets;
…\extern\include\wxwidgets\msvc;
…\extern\boost;
…\extern\sfml\include;
…\extern\debea\include
Preprocessor definitions: WIN32;_WINDOWS;_MSVC;
Runtime library multi-threaded dll (/MD)
Additional dependencies: icog.lib igui.lib ipercept.lib ipersistence.lib igraphicmodule.lib
Additional lib directories:
…\bin;
…\extern\lib;
…\extern\bin;
…\extern\panda3d\built\python\libs;
…\extern\boost\lib;
“$(OutDir)”
CLR Thread Attribute: STA threading attribute (/CLRTHREADATTRIBUTE:STA)
NDEBUG is not declared in the whole project in release. I use _DEBUG in debug.
Besides I include winsock2.h at the very first in main.cpp (because of winsock vs ws2def collisions)
Trying more things I used pview and I got scared as the models where distorted as well. However, I realized that pview was loading corrupted .bam models from cache-models. Wiping them pview loaded the models well. And then back into my application the models where loadded correctly because of the pview-generated .bam cached models. However, if cache-models is cleaned new models are loaded bad again and written bad in cache. So I guess It must be due to my project configuration or the use of threads
It is true that threaded Panda is not fully exercised, since most Panda users use SIMPLE_THREADS or no threads at all. It is possible that something non-thread-safe in the egg loader is causing a corruption of the models.
If that’s the case, perhaps a simple workaround is to pre-convert all of your egg files to bam files.
