I’ve just run into a problem with my level: I seem to have hit a point at which Panda will no longer load the level’s egg file, at least on my machine.
Specifically, both my game and PView return an error indicating that something is exceeding the “total heap single size”; right now I’m presuming that the “model” is simply becoming too large. This is borne up by partial exports working well, as I recall.
Now, in all fairness, it does look as though my vertex count is higher than I’d realised–just below 550 000 vertices, according to Blender. Still, while I think that I’ve identified a few places in which I might simplify geometry, I’m not sure of what to do going forward: This is a fairly small level–what do I do when I start in on larger levels?
The error could indeed mean that memory simply ran out, but 500k vertices isn’t going to do that. Not even close. It is more likely to indicate a bug in Panda3D, which we’d like to reproduce.
I am assuming you are using 1.9.4. The memory system had some reworking and fixes happen in 1.10 so I wonder if you would run into the same issue there.
Interesting. I’ll probably still reduce the complexity of some of my meshes, but that does give me some hope going forward.
So. memory issues.
While I had already reduced the vertex-count to a point at which the level was loading in 1.9.4, for the purpose of testing I duplicated a large mesh a few times, which seems to have successfully pushed it over again.
As to 1.10, I’ve downloaded and installed a recent buildbot version of the SDK, I believe. I don’t have my framebuffer set up as 1.10 likes (I once again have a blood-red scene. It’s… kinda eerie. o_o), but I imagine that this makes little difference–the issue seems, after all, to be related to model-loading.
With this version, the model does seem to load! (It does take a little while, but that may be at least in part because this is its first time loading this model, and thus caching/conversion is happening as well.)
So, does this mean that I’m stuck with switching to 1.10, or is it feasible to fix the issue in 1.9.4?
The issue with your framebuffer should be fixable by using setRgbaBits on your framebuffer properties.
I do think it might be best to switch to 1.10. In some areas it seems to be stabler than 1.9.4. I couldn’t tell you which specific change happened to fix this issue.
Indeed–I simply didn’t bother to make the change for the purpose of this quick test, as I recall.
Hum… My main qualm here is Deploy-ng–how reliable and stable is it, at the moment? I don’t want to have a build system that’s not yet quite ready, and as I recall it seemed that the old “rtdist” system may not work properly in 1.10. (That last was one of the reasons that I decided to stick with 1.9.4, as I recall.)
Sorry, I’d meant to reply to this sooner. Deploy-ng seems to work fairly well as far as has been tried, but it does not yet support creating installers, and it has not yet been very well tested with applications that use complex thirdparty libraries (like wxPython and numpy). However, if you do run into issues, I’m happy to look into them.
One inherent advantage of deploy-ng over packp3d is that the deploy-ng pipeline is significantly simpler, which makes it inherently stabler and makes it easier to fix issues. Our efforts are currently focused on improving deploy-ng moreso than continuing to support packp3d et al.
I imagine that Bullet (which my project uses) is the sort of third-party package that you mention? (Although, in all fairness, I think that it’s the only one.)
As to installers, for the moment I would be happy to leave aside an installer, as long as it can produce something self-contained: something that, once downloaded, provides all that’s (reasonably) required for it to run, and doesn’t involve any additional downloads, or an internet connection. A folder with all dependencies (as the rtdist system’s self-contained installers used to produce) or a monolithic executable would be examples of what I mean.
The thing is, I want to start working towards creating a limited public demo (i.e. released on a game-dev forum, but not promoted outside of that just yet) of my game in the near future, hoping to get feedback. I’m thus hesitant to use a system that’s not yet quite ready. I’m even more hesitant when looking further ahead to perhaps releasing a promotional demo.
On the other hand, 1.9.4 won’t load the level. While I’ve been getting around that during development by simply exporting only selected parts for each test, it does look as though moving to 1.10 might be called for in order to get the game actually working…
Do I take it that the rtdist system has been left so long as of 1.10 that, even if we got it working, it wouldn’t be wise to rely on it any more due to the potential for things to have broken?
I can vouch for deploy-ng on windows using py3.6. Once I learned about having to tell setup about used plugins, and setting the default model extension to bam (and sometimes building the bams beforehand)…and copying sqlite.dll… all my attempts at deploying worked fine
With deploy-ng you get a folder with an exe (with python scripts packed in it), some dlls, a etc folder with prc files and your own model/texture/whatever folders. As far as I know end users need not download any runtime, no internet connection is needed, no secret folders are created. One thing that could make it a bit more ‘clean’ would be a ‘bin’ folder with all the dll in it, so it would be easier for end users to find the executable and maybe redirecting stdout to a log file, but the later can be done in the python script.
Does it cross-compile? I develop under Ubuntu, but would want to compile for Windows.
Is there any documentation on these points? How to tell it about the plugins, any specifics on the bam conversion business (such as where to set the model extension–a PRC, I imagine, bu if so which and where)? Whether SQLite is required for single-player games?
(The point about setting the model-extension and building bams oneself is a pity, but I imagine that automatic handling of this will come as the system is developed further.)
To be honest I didn’t try cross compiling so I can’t really tell.
The setup script will run egg2bam for each egg model it finds, but I had some errors with the bam files it made (wrong texture path) - it may be because I had 2 versions of p3d sdk installed, or just my cursed pc just doing it’s thing. The prc for default models extensions is ‘default-model-extension’ so I just used load_prc_file_data(’’,‘default-model-extension .bam’).
The plugins is something added some time ago (check the setup.py in the asteroids demo in the deploy-ng branch), I’m not sure if there are any docs on it. The names of the plugins are like just like the names of the libs used by panda3d just without ‘lib’ and extension (.dll or .so?) like: ‘pandagl’, ‘pandabullet’, ‘p3openal_audio’ or so I understood it from a chat with rdb on irc.
SQLite - you need it only if you use it. It’s a good choice for storing game states, levels or saves for single player. On windows I had to manually copy sqlite.dll from my python installation for it to work after deploying. If you don’t use sqlite you don’t need to worry about it.
Moguri and I are planning to spend some time working on deploy-ng this week, with the intention to work towards getting the code stable enough to be merged into the master branch. Your game might prove to be a great testcase to see what kind of difficulty we might run into with a bigger game project.
The egg2bam behaviour will be changed slightly so that changing the default-model-extension will no longer be necessary.
Crosscompiling should work; I did try various cross-compilation configurations but I don’t remember if I recently tried compiling for Windows from Linux in particular. I’ll be sure to try that sometime this week.
As for bullet, this doesn’t count as a thirdparty library in the sense I intended, since it’s a part of Panda and should work just fine with deploy-ng. I was talking more about other Python modules that have their own C extensions, such as wxPython and PyGame.
Indeed, for the simple reason that the rtdist system is more complex and as such has more potential points of failure.
We’re not intending to continue supporting the rtdist going forward because the maintenance cost of the rtdist is simply too high, which is why we are aiming to make deploy-ng a reliable replacement.
Ah, I see, and fair enough. Well, we’ll see how it goes, I suppose!
Fair enough, and good to know. I’m not using it–I store my levels and game-saves in text files via my “GameSaver” module–so I should be fine there, I believe.
Fair enough–that’s good to read!
It does seem as though Deploy-ng is far enough along that I’m willing to hazard this. I’m not sure of when I’ll be ready to build the demo, but I can perhaps make test-builds as I go along. It’s probably a good idea anyway: it may help to iron out issues, both on my end and in Deploy-ng, before hitting the point at which I want to post something publicly!
Ah, excellent, on both counts.
In the case that cross-compilation does prove non-functional, I can perhaps switch over to Windows for the purposes of making builds. Not ideal, but workable.
Ah, that’s good to know. Do I take it then that the same applies to OpenAL, which Wezu mentioned above when talking about third-party plugins, I believe?
Ah, okay–that’s good to know. Should Bullet also be added to the list of plugins? You indicated that it was considered to be “part of Panda”, but also that OpenAL was similar, so I’m not clear on where it stands… ^^;
All right, I intend to make the switch over to 1.10 tonight. To that end, I’d like to check that I’m going about this correctly. Note that I intend to build from source. So, if I may ask:
First, since we’re interested in trying the “Deploy-ng” distribution tool, do I take it correctly that I should download the “deploy-ng” branch to build from? Or would “master” work just as well, and be more up-to-date?
Second, do I build as I did 1.9.4, but only the SDK? That is, I shouldn’t build anything other than the SDK (no “runtime”, and of course no “rtdist”), and I should still use “MakePanda”, like so:
Yeah, you would need the deploy-ng branch. We plan to merge it into master soon.
Yes, it’s just the SDK. You should pass at least “–everything --wheel”, and you probably want to pass “–no-eigen --threads=4” (substitute how many CPUs you have) to make the build go faster.
However, you don’t need to build Panda from source. We continuously make binary wheels available for the latest git versions that can be installed more easily, including for the deploy-ng branch. This is all that’s needed to install the latest version of Python:
You can also use virtualenv, a tool that lets you contain a Python environment including a Panda3D installation inside a directory. You can then “switch” to that environment and install the desired version of Panda into it using “pip”. It’s a very easy way to avoid contaminating your existing Python installation.
I’d missed or overlooked that “threads” option, I suspect–that looks useful! (Although I might leave a CPU open for other tasks while I wait for the build to run.)
I haven’t used PIP before, I believe (which is what I take it that the “wheel” parameter refers to, given reference to PIP elsewhere). I should have it installed now!
Nevertheless, I think that I’d prefer to do so. Even if I don’t make the rendering change mentioned in the “can a node have two parents” thread, I like to be confident of excluding certain packages. (And indeed, I tend to build with a fairly long list of “–no-<…>” parameters.)
That’s good to know, but I think that I’m happy enough moving over to the new version. If it causes problems, however, I may take the above advice!
Well, I think that I’m ready to build, then–I’ll likely post again once I’ve done so and performed some tests. (And made the relevant frame-buffer configuration changes to prevent the “blood-red view” issue.)
