3dsmax (2009) exporter exports meshes fine, but does not appear to export animations properly. Either the model disappears completely in pview (exported animations and model in single file) or just plays animation without anything happening (exported seperate model and animation). Happens both with skin and physique and using bones and biped on any model.
[size=75]EDIT: Temporary solution: use Pandasoft .x exporter and convert the exported .x to egg with x2egg[/size]
PStats is a huge frame time hog for me, scoring from 50 to 100+ms and virtually crippling the speed of the actual application it’s supposed to analyze. The heavyness doesn’t appear to be scene related. It is NOT a processing power issue either as we made some comparisons between me and ThomasEgi. I’m tempted to suggest it may be some Vista issue since I’m using 64bit Vista SP1.
[size=75]EDIT: Fixable with config var: pstats-max-rate 10[/size]
I’ve seen that kind of PStats degradation on certain platforms. It seems to be due to blocking network messages. One workaround is to limit the PStats bandwidth, with something like:
pstats-max-rate 10
in your Config.prc file.
Another workaround is to build with thread support, which allows the PStats write process to block in another thread, without blocking the main thread. Of course, enabling thread support also imposes its own performance overhead (discussed in another post). We have recently added support on the CVS trunk to support this even when Panda is compiled with SIMPLE_THREADS (which provides a thread-like support without the runtime overhead).
drwr,
does enabling SIMPLE_THREADS really give no extra performance loss and only gives benefits? If so, could it be an idea to enable it in the default builds?
I would, in fact, recommend that for the next version release, presumably the 1.6 release. (There are several threading enhancements that I’m working on now, and all of them will benefit from having SIMPLE_THREADS enabled.)
I’m not sure if it’s stable enough in the 1.5 branch; and in any case, changing that compilation flag would hardly qualify as a minor version change.
It’s not 100% true that SIMPLE_THREADS only gives benefits. There are a few complexities associated with having SIMPLE_THREADS enabled in the build.
The most important to the end-user is that it becomes vitally important never to use Python’s thread or threading module, or any external thread calls, in a Panda app; instead, you’ll have to use Panda’s PythonThread class and Panda’s ConditionVar and Mutex classes. These are functionally similar to Python’s native threading implementation, so it’s no loss; but it’s a slightly different interface and you do have to know about it.
Presently, without SIMPLE_THREADS or any other threading implementation compiled into Panda, you really shouldn’t use Python’s native threading because you risk hitting a race condition, but you might nevertheless get away with it. If you try it with a Panda build that has SIMPLE_THREADS enabled, though, you will certainly crash and burn in a horrible cloud of black smoke.
Okay, I guess I’ll make sure makepanda will set it by default, for the 1.6.x series. We’ll also need to document it somewhere in the manual how to use this new threading interface.
I hope you do not mean that literally your computer blows up or so
when starting panda3d with simple threads we could mask the threading module to say some thing like “sorry you cant use the threads now use panda3d threads instead”
I don’t think it’s a good idea to mask those modules, since if we do that they won’t be able to run non-panda python apps anymore if it uses threading.
If they really use the python threading module with panda they will themselves notice they shouldn’t have done that the moment they see black smoke coming out of their computer.
We could maybe add something in panda that checks if the python interpreter has more than 1 thread running, maybe in ShowBase using threading.activeCount() or so. Dunno if something like that is already there, tho. Or we can just acquire the global interpreter lock and never release it
And by the way, guys. We’ve just decided (on the IRC) its a good idea to make a final 1.5.4 release to put an end to the 1.5 series. This release won’t cover new features but just bugfixes, hopefully all of the bugs mentioned above. Then, we’ll fully focus on the 1.6 series.
Well, we could “mask” the modules by playing games with sys.modules at runtime only, for instance when ShowBase starts up. That way you could still use the Python threading modules for your non-Panda apps. This seems like a good idea to me; counting on people to know what went wrong when they see the black smoke pouring out isn’t always reliable.
We still need to lock and release the Python global interpreter lock per each “thread” when running with Panda SIMPLE_THREADS. As far as Python is concerned, you’re still running multiple threads, and Python deals with them the same way it deals with true threads. It doesn’t know that Panda is managing the “threads” instead of the OS.
Also, checking for the existence of OS-level threads isn’t really reliable either, because you might have linked with a third-party library that spawns its own threads (like FMod, for instance), and as long as these threads never ever make a call into any Panda code, it’s safe. So we can and should allow these third-party OS-level threads to exist.
As to the new release, that sounds great. The general philosophy we’ve been trying to maintain with the release numbering is that the minor releases (e.g. 1.5.2 to 1.5.3) should generally be bugfixes only, while new features should be held back for the major releases (e.g. 1.6.0). Of course there is considerable flexibility in this rule, since we sometimes slip in new features that we deem small enough or urgent enough into a minor release.
Getting started to work on a 1.6.x release now is fine–it would be useful to start a build or two and see what’s going to break, for instance–but keep in mind I’m in the middle of a development cycle that may take another 4 to 8 weeks to complete. When I’m done, there will be a new series of features that will be useful to call a 1.6.x release; until then, I think it’s not quite stable enough or feature-complete enough to introduce it to the rest of the world.
Right now I’m working on the task manager, moving it into C++ (and thereby making it more efficient) and also adding new features like optionally threaded tasks and built-in generator support.
I’ve recently added support for threaded texture loads and threaded animation channel loads. I think it’s pretty cool. Now, loading a texture or an animation file on-the-fly doesn’t necessarily cause a chug in rendering; it will load in the background and become available whenever it finishes loading.
Threaded vertex paging has been available for a while, but has recently been refined. Good for managing lots of data on a low-memory machine.
Oh yeah, loading dds files directly is supported now. Doesn’t add much functionality, but it’s been requested.
Another interesting new feature: tinydisplay, a built-in software renderer, based loosely on the public-domain TinyGL project. It’s blazingly fast, for a software renderer; using it, I can get a slightly better frame rate than I get with hardware rendering on certain cheap integrated graphics cards. Visual quality is not as good, though–filtering is still too expensive to do on the CPU. But software rendering means you can be confident your application will run on anyone’s computer, no matter what the state of their graphics drivers (which are always full of bugs).
I’m afraid I have to report another bug. I noticed the DirectX file loader kept loading files from some cache (other than the /modelcache/ ) today even after I emptied the modelcache and DELETED the file I was trying to load. It didn’t seem to affect .eggs converted from the said .x files. The current solution then is to x2egg the .x files rather than using them directly.
[size=75]EDIT: Not a bug after all. Solution: release model(s) from caches with ModelPool.releaseModel(‘myFile.x’) or ModelPool.releaseAllModels()[/size]
Well, I used the usual Actor(“model”) syntax for loading the model. Then I exported a completely different model (under the same name) and noticed nothing changing. After that I moved the .X file to a subdirectory, but that changed nothing either.
Then I deleted the file entirely and yet again nothing changed. I finally emptied /modelcache/, but the model kept haunting me anyway. pview was also under this spell, although it did notice that the file was missing, but after I introduced the completely different model under the same name, it was still showing me the old model that I deleted.
There are two caches in Panda: an on-disk cache, and an in-memory cache.
I think you were running into the in-memory cache. Whenever you load a model, the second time you load that same model (in a given session) it doesn’t hit the disk at all. If you want to force a reload of a given model, you can either restart your Python program, or you can call:
ModelPool.releaseModel('myFile.x')
or even:
ModelPool.releaseAllModels()
This shouldn’t affect pview, of course, but maybe you were getting burned by the on-disk cache for pview.
Normally, the on-disk cache will not take precedence over a newly created model file, since the loader checks the date stamps and will load the original file if it is newer than the cached file. (This doesn’t apply to the in-memory cache, of course, since the whole point of the in-memory cache is to avoid going to the disk at all.)
Also, there is only the one on-disk cache. Once you have emptied the on-disk cache and restarted your session, there’s no more cache. The next model load will definitely load the file you name.
None of this has anything to do with the on-the-fly conversion of .x files. The same caching rules apply to .x files, .egg files, and .bam files.
Okay, not a bug then. Maybe it was just bad luck since I have yet to see the same happen with .egg files. Thanks for the release methods though, I’m sure they will become very useful
one question…when you said the max exporter was “fixed” did you mean that I can now add normal maps directly in max and export them instead of having to set them in maya? I can successfully do that in maya but its a pain exiting max and loading maya then export yada yada!
@timoshii: Yeah, in 1.5.3 you can already export normal maps in MAX, though after you’ve exported it you need to call a certain command. See the other thread for more information.
@drwr: Yeah, I knew about the release thing, though 1.5.3 was an exception to that since everyone wanted BSD in it and Josh wanted the new maxegg in it as well.
Right now I tagged 1.5.4 as 1.5.3, though am also picking up the bugs listed here. But, about this problem: discourse.panda3d.org/viewtopic.php?t=4909
Did you commit a fix for that? If so, what file? I wouldn’t have an idea where the problematic file could be.
Same question for this bug: discourse.panda3d.org/viewtopic.php?t=4913
I don’t really remember which file I fixed for the first thread linked. I could probably find it by digging around in the cvs logs, but I do remember it was a pretty contrived situation, and I don’t know if it’s worth the effort to pick up the fix for 1.5.4–I highly doubt anyone else will run into this particular bug in the next six to twelve months, so it can happily wait until 1.6.
As to the second thread linked, that turned out not to be a bug at all, but just roundoff error due to the very large coordinates used to define the collision polygon. I imagine this problem will be fixed when I implement the double-precision proposal that would solve the small-polygon issue, but again, this is a fringe case: the collision system wasn’t really designed for very small, or very far away, collision polygons, and I don’t know that it’s critical to pick this fix up quickly.
