I installed panda3d because of its diverse feature set and community. Since my project will require some modifications to panda3d, I decided to install from source. I chose the PPREMAKE method, because I am familiar with the configure/make/make install format, and figured it would be easier to build with changes.
I got everything compiled and installed (after I fully read the instructions, doh), but there seems to be some problems with the sample programs.
Apparently, recently the API changed so that extensions where not auto-detected. Unfortunately, the sample programs have not been update. After some searching, I found the config default-model-extension. This only works if the sample just uses one type, but for some like Firefly and Steam-Example in Particles, the examples required editing of the source.
The other problem was model directories. In order to get things to work, I had to add model-path . to detect models with the directory. Also, some samples require models from the src/models directory, or the dmodels directory.
FractalPlants fails to start on an assertion in GeomVertexWriter.
Music-Box fails on assertion when the box is closed.
I hope to continue using Panda3D, but I must say it is very frustrating and discouraging when out of the box, the sample programs do not work. It gives the feeling of careless, unfinished work, though I know there has been a lot of good quality work done here, and the library is very sound.
I will look into generating more detailed bug reports and hopefully some fixes.
Which source code did you get?
Latest release 1.7.2 (stable) or from the cvs repository (unstable)?
It is possible the assertions you are getting are due to the way in which the code has been compiled. I use the makepanda system to do my compiles, but I know for example that if I enable threading in my build Panda becomes very unstable.
You could try downloading the precompiled release and see if you get the same problems. This would help identify if it is a problem with your compile or not.
I compiled with simple threads ( I will need threading later).
I will try compiling without threads and check out a prebuild dist.
The assertion error I get for Fractal-Plants is:
:gobj: Loading texture /opt/develop/panda3d/src/samples/Fractal-Plants/barkTexture.jpg
Assertion failed: _pointer_begin == _pointer_end || _pointer <= _pointer_end at line 844 of ./geomVertexWriter.I
Traceback (most recent call last):
File "Tut-Fractal-Plants.py", line 423, in <module>
t=MyTapper()
File "Tut-Fractal-Plants.py", line 353, in __init__
makeFractalTree(bodydata,treeNodePath,Vec3(4,4,7))
File "Tut-Fractal-Plants.py", line 302, in makeFractalTree
makeFractalTree(bodydata, nodePath,length,newPos, numIterations-1,numCopies,smallRandomAxis(vecList))
File "Tut-Fractal-Plants.py", line 287, in makeFractalTree
drawBody(nodePath, bodydata, pos, vecList, length.getX())
File "Tut-Fractal-Plants.py", line 190, in drawBody
colorWriter.setRow(startRow)
AssertionError: _pointer_begin == _pointer_end || _pointer <= _pointer_end at line 844 of ./geomVertexWriter.I
Hmm, sounds like you’ve run into some packaging issues. Tell me more about the problems with default-model-extension. This is not a new change at all; the config variable was introduced many years ago. All of the sample programs should be loading model files that end in .egg.pz; and they either load them with an implicit extension or with the extension “.egg”. default-model-extension should be set to .egg.
If you haven’t compiled in zlib support, then the automatic loading of .pz files will fail; likewise, if you haven’t set default-model-extension to .egg, then many of the samples will fail. The prebuilt distribution does both of these things. It is true that the prebuilt distribution will tend to be more heavily exercised and out-of-the-box stable than any home-built version.
The Tut-Fractal-Plants error looks like something else, and may indeed be related to threading; I will investigate. Though the prebuilt distribution is also compiled with “simple threads” enabled. Are you sure you want simple threads instead of full threading?
However, I’m surprised at the report that compiling with threading enabled results in an unstable build; this is the first I’ve heard of such a thing. Can you tell me more about that, teedee?
setting default-model-extension to .egg does enable me to run most of the samples. My biggest problem was that this is not set in any of the standard config files or mentioned in the docs.
Also, a couple samples pull from local model egg.pz files as well as bam models in DMODELS. In order to run these, I had to add the .bam extension in the source for those models and use defaul-model-extension .egg for the rest.
drwr, I am not sure which threading I want yet. I may need to use full threading eventually. Especially if I migrate most of the code from python to c++ .
Right, I agree that everything should run out-of-the-box. The problem is that we disagree slightly as to what constitutes “the box”. Generally, all of the samples have been written against, and are meant to run against, the prebuilt and prepackaged version of Panda that is provided from this site for download; and with that version, they do generally run out-of-the-box (barring issues with your graphics driver).
They also generally run against the version of Panda that is built using makepanda with default parameters. Makepanda is designed to generate a consistent build of Panda with relatively few user-configurable parts. It also comes with a config file that sets some reasonable default values such as default-model-extension and model-path.
The ppremake build system, on the other hand, is meant for hardcore tinkerers who intend to build a custom version of Panda for their own specialized purposes. It’s possible to use ppremake to build a version of Panda that can run all of the samples, but this isn’t necessarily what you get automatically.
With some effort, we could rejigger the ppremake system so that it is more compatible with what the makepanda system produces, and thus more immediately compatible with the sample programs. The problem is that the ppremake system was designed independently, for different reasons than the makepanda system; and it serves different needs.
Maybe it would help if just we had bigger warnings in the INSTALL-PP document, advising the new user that he is about to walk down a path meant for hardcore developers, and gently directing towards makepanda.
Well there was the old issue with FMOD, and more recently the shutdown crash that I was experiencing. Those were both with simple threads. Both were fixed by disabling threading. Whenever I’ve tried full threading things just seems to crash on load.
The other thing, there is a significant performance benefit running with threads disabled as opposed to simple threads, at least in my case. I don’t see any benefit for running simple threads over no threads.
Ah, right. Sorry about that. We haven’t found a volunteer to offer to fix the FMod problem yet, though we admittedly haven’t been looking very hard. I’ll try to see if I can get to it myself, though I don’t really use FMod and know relatively little about it.
I don’t really know what was causing your shutdown error, either. I only guessed you had threading involved because you mentioned a 10% performance drop, which is what you get when you enable true threads (but not simple threads). Simply enabling threading wouldn’t cause a crash on exit, though, so there may have been something more subtle going on in your build. I’d be happy to help you research this further if you are interested.
For the record, the breakdown on the threading models is this:
(1) No threads. Fastest possible performance on a single CPU. You may not use any threading constructs in Panda or Python. This is the default compilation model for ppremake.
(2) Simple threads. Basically the same performance as no threads for single-CPU work. You may use Panda threading constructs to do parallel tasks such as loading models in the background while rendering continues in the foreground. However, background tasks may interfere somewhat with the performance of foreground tasks. You may use the Panda-provided stdpy.threading module to simulate Python threading constructs, but you may not use actual Python threading constructs. In any case, your program will still be limited to a single CPU, even if you have multiple cores on your PC. Minimal risk from deadlocks and race conditions. This is the default compilation model for makepanda.
(3) Full threads. Roughly a 10% performance drop across the board for single-CPU work, but now you can take advantage of multiple CPU’s (with the normal risk of deadlocks and race conditions if you are not careful). Most internal Panda structures are protected from race conditions but you still need to protect your own structures, of course. You may use either Panda threading constructs or system threading constructs. If you use Python, however, your Python code is still limited to one CPU by the nature of Python itself. Background tasks are less likely to interfere with foreground task performance.
Well I was pretty sure it was with simple threads enabled in makepanda that I got the performance drop, though I suppose it is possible that somehow it still compiled with full threads somehow.
I’m satisfied with my threads-disabled build. My main concern with this was the eventual game release and I thought it would be nice to be able to use an official release as opposed to a custom build.
I can think of a lot of things I could use full threading for, though I don’t know if I will have time to implement it before the project is released.
For the shutdown crash I can try to whittle down my code into a minimal example, though we should figure out if my build is simple threads vs. full threads first. Is there a way that I can confirm my build is compiled with either option?
For the record, the error with Tut-Fractal-Plants:
AssertionError: _pointer_begin == _pointer_end || _pointer <= _pointer_end at line 844 of ./geomVertexWriter.I
turns out to be unrelated to threading, but is in fact an inappropriate assertion that is only revealed in OPTIMIZE 1 or 2. It’s not in the default build, which is OPTIMIZE 3. (For the record, I would generally recommend OPTIMIZE 3 for application developers, and OPTIMIZE 1 or 2 for developers of Panda3D itself, though C++ application developers on Windows may indeed prefer OPTIMIZE 2 since this allows your own application to be compiled with a debug heap.) In any case, please accept my apologies for this bug; I’ve just committed a fix.
I think I will start with this shutdown crash. I built with default makepanda configuration, and Thread.isTrueThreads() and Thread.isSimpleThreads() both return 1. With this setup I get the shutdown crash that I do not get with threads disabled. I will cut down my code and try to find the exact cause.
I have identified the problem as the PRC setting “window-type none”. Without this setting Panda shuts down just fine. This is for the server component of my game and thus it should not open a graphics window. Sometimes the crash is the TransformState one, and sometimes it is python returning an error code.
Example code (crashes when clicking close button on the text output window):
from panda3d.core import *
loadPrcFileData('', 'window-type none')
loadPrcFileData('', 'audio-library-name null')
import direct.directbase.DirectStart
from direct.showbase.DirectObject import DirectObject
class Game(DirectObject):
def __init__(self):
pass
print 'LOADING...'
Game()
print 'READY.'
run()
For the FMOD problem, as you explained the problem is likely FMOD accessing the vfs at the same time as Panda. So in theory if we prevent FMOD from performing any asynchronous task (streaming) and instead load the sounds up front it might be OK?
FMOD also supports a new method of getting data that was not available when the Panda implementation was originally written. Here is the description from the FMOD docs:
I suppose this would allow for Panda to wait until it was safe to provide data to FMOD if I am understanding it correctly.
PS sorry for hijacking this thread, I hope the original problem was resolved.
I’ve actually just committed a solution to the FMod problem, which will become part of 1.8.x (but not 1.7.x). I’m looking into the shutdown problem you reported as well. I’ll post any additional followups in the original threads, so as to avoid leading this thread further astray.
