Project health, ecosystem & deployment

Everything below is drawn from the community-mined catalogue and is preserved as community-sourced opinion and history, with maintainer quotes flagged (maintainer) and verbatim.

These are the meta-issues that cause many of the technical ones elsewhere in the manual.

Bus factor: one part-time maintainer carries the project

Severity: major · Status: by-nature-of-project

Development and maintenance are overwhelmingly concentrated in one person (rdb). It is the root cause behind doc gaps, stale samples, unaddressed feature requests, and slow releases.

Do note that the maintainer and core community are very responsive, Panda3D is very stable, and any critical errors get imediately dealt with. rdb has been providing superior work for a very long time now. The question is how to help him with the workload, and not if he is not enough.

Institutional withdrawal (Disney → CMU → community)

Severity: historical/formative · Status: improved (community took over)

Panda originated at Disney’s VR Studio, was transferred to CMU’s ETC, and then CMU effectively stopped maintaining it (~2009, after Josh Yelon left) — only hosting servers. rdb candidly warned the project would die without a maintainer and engineered the pivot to community maintenance. The funding question (donations, a paid developer) was raised but never durably solved.

Donate on open collective - Panda3D

and the Sponsors page

Recurring “Is Panda3D dead?” perception

Severity: major · Status: still-open

The project’s image lags its actual activity. Dated website, old “stable” download dates, and stale blog posts make newcomers assume abandonment - a direct adoption deterrent.

“The question ‘Is Panda3D dead?’ comes nearly every half a year.” — bigfoot29, t/3450

“I was a bit concerned when I first looked at the website, thinking that the project was no longer maintained. The latest version considered stable… released two years ago.” — AndreM, t/13274

Misleading “Active developers: CMU and Disney” in the manual

Severity: minor · Status: improved

The manual credited CMU and Disney long after both had effectively stepped back, both misattributing credit and discouraging contribution (“two big companies are on it, they don’t need me”). rdb conceded the page was misleading.

“Reading the manual page again, it is true that the manual page is a bit misleading, though.” — rdb (maintainer), t/13274

Small community vs. mainstream engines; users weigh switching to Godot

Severity: major · Status: by-nature-of-project

The community is small relative to Unity/Unreal/Godot, with thin advertising and few learning resources. drwr notes only “two people officially associated with Panda” frequent the forums and the community is “somewhat smaller than Ogre3D.”

“there are only two people officially associated with Panda who frequent these forums.” — drwr (maintainer), t/1514

“if I was making games only but still really needed an open source engine, I’d invest time switching to Godot over Panda… If Godot chose Python over a custom language I’d be gone by now.” — sutemp, t/29653

Maintainers’ own tech-debt admissions: “old and crufty,” “needs a rewrite”

Severity: major · Status: still-open

Across years, drwr and rdb openly describe large swaths of the engine as legacy cruft: ShowBase, the shader generator, genPyCode, interrogate, the Max exporter, half-finished parallel-render code.

“This is an example of some of the cruft that has accumulated in ShowBase over the years.” — drwr (maintainer), t/2859

“The genPyCode version makepanda uses is a mess though… it definitely needs a rewrite.” — rdb (maintainer), t/4624

No first-party visual / level / scene / shader editor

Severity: major · Status: by-design + resource-limited

Panda has no visual editor. The CMU-era SceneEditor was buggy, broke across releases, and was removed as “half-finished.” rdb frames code-first as intentional but ties the missing editor to “limited developer resources.” Users repeatedly cite this as an adoption cost vs. Unity/Unreal.

“The scene editor is only half-finished… It needs a developer.” — Josh_Yelon (maintainer), t/1918

“I can’t make any promises about a visual shader editor, though. Aside from the limited developer resources, Panda3D has always been a bit more of a hands-on engine than Unity and Unreal.” — rdb (maintainer), t/28342

PR-review bottleneck

Severity: minor · Status: still-open (symptom of the bus factor)

The single-maintainer bottleneck shows up as CHANGES_REQUESTED/“needs rebase” stalls on the tracker; community PRs (e.g. type-stub work, #1217) stall and get revived months later. A direct consequence of the bus factor (see above).

Documentation & learning curve

Documentation is incomplete/sparse — maintainers concur

Severity: major · Status: still-open (improving)

Entire subsystems (particles, collision specifics, networking, clip planes, cube maps) are sparse or undocumented; drwr’s standard answer for gaps is “look in the source code.”

“As for where to find this sort of information when the manual is lacking, well, I looked in the source code…” — drwr (maintainer), t/9447

“Yes, fair, the documentation is a mess.” — rdb (maintainer), t/28342

Auto-generated API reference is hard to navigate and example-free

Severity: major · Status: improved (Sphinx, 2019)

The Python API reference is auto-generated from C++ by interrogate. It historically lacked method descriptions, inheritance info, and examples, and contained confusing “semantic twins” (panda3d.core.Loader vs showbase.Loader.Loader). (The interrogate binding generator is documented in dtool / interrogate / config.)

“The API reference is automatically generated from scanning the source files. It is true that it is far from perfect.” — drwr (maintainer), t/8953

C++ API documentation perpetually incomplete

Severity: major · Status: still-open

Because docs are generated from the C++ side but written for Python consumers, C++ users hit “To-Do” placeholders for years; the Sphinx migration explicitly deferred a C++ API reference.

“most of the parts of C++ manual is incomplete with a ‘To-Do’ markings here and there.” — Juggernaut, t/12231

Outdated/incorrect docs — covers removed APIs, wrong sample paths

Severity: major · Status: still-open (perennial)

Manual pages reference removed APIs (makeGsg/makeOutput), point to wrong sample locations, and describe deprecated workflows. Beginners waste time on dead tangents.

“The base.graphicsEngine.makeGsg is also not there any more. The manual seems outdated?” — clcheung, t/5418

Ancient sample programs teaching obsolete patterns

Severity: major · Status: still-open

Bundled samples “look as if they were made 10 years ago” and teach obsolete patterns (native physics, fixed-function, old camera drivers), with no samples for modern needs (PBR, terrain collision, water, networking). A 2019 rewrite effort stalled.

“we still have the same old samples that look as if they were made 10 years ago (and they where).” — wezu 2019, t/24289

Steep learning curve despite “short learning curve” marketing

Severity: major · Status: still-open

Panda markets an “easy learning curve” (its ETC teaching origin), but thin docs invert that for beginners.

“the learning curve with sketchy documentation makes it that much harder and a lot of good programmers leave. I almost left the other day because of the docs.” — ta2025, t/311

Build & installation

pip wheels lag new Python releases (“No matching distribution found”)

Severity: major · Status: still-open (structural; reactively mitigated)

Panda ships per-Python-version binary wheels, so each new CPython release breaks pip install panda3d until a maintainer manually builds new wheels — and the pip error gives no hint that a missing wheel is the cause. Recurs every Python cycle. (A downstream consequence of the bus factor — see above.)

“This is because there are no Python 3.9 builds of Panda 1.10.7 on PyPI.” — Moguri (maintainer), #1030

Three build systems over time (ppremake → makepanda → CMake), each confusing

Severity: major · Status: makepanda standard; CMake migration still incomplete

ppremake and makepanda were mutually-incompatible (mixing them silently corrupted builds); the multi-year CMake migration (PR #717/#859/#322) still doesn’t cover wheels, installers, Maya/Max tools, Android, or makepanda’s critical compiler flags — so the project maintains all three simultaneously.

“the problem is that you used both build systems: ppremake, and makepanda. The two aren’t compatible with each other.” — Josh_Yelon (maintainer), t/279

“one thing I’m still missing from the CMake branch is the compiler options that makepanda specifies… some of these are fairly critical.” — rdb (maintainer), #717

interrogate (homegrown C++→Python binding generator) is fragile and mandatory

Severity: major · Status: still-open (by-design tool; recurring bugs)

Bindings come from a bespoke tool that re-parses C++ via its own CPPParser. It’s mandatory (the build can’t skip it), breaks with each new Python C-API change, and has fragile static-init/build-order assumptions. When it fails, the whole build fails. (See dtool / interrogate / config for how the tool works.)

“Makepanda cannot function without interrogate.” — Josh_Yelon (maintainer), t/279

Source builds depend on fragile, version-pinned thirdparty packages

Severity: major · Status: still-open (recurrent breakage)

Builds break whenever a bundled/system dep drifts: OpenEXR 2.3→2.4 (linker errors), OpenCV 4.x (removed CV_CAP_*), QuickTime removal on Mojave, libjpeg.so mismatches. The standard mitigation is “disable that optional feature” (--no-opencv, …).

macOS install-location churn & maintainer-bandwidth gaps

Severity: major · Status: mitigated

The SDK installed into /Developer (deprecated, then removed in Catalina); the installer then refused to run; and import panda3d failed because the install location wasn’t on Python 3.7+’s sys.path. Compounded by the maintainer lacking hardware new enough to reproduce — another symptom of limited resources.

“Given that my Mac Mini cannot install Mojave, let alone Catalina, it seems we have a need for a new macOS maintainer.” — rdb (maintainer), #760

Deployment & packaging

The old .p3d web-browser plugin / runtime: abandoned, removed

Severity: historical · Status: removed-in-1.11

For ~5 years Panda’s flagship distribution story was an NPAPI browser plugin + “Panda3D Runtime” (packp3d/pdeploy/.p3d) — heavily prioritized by drwr over other work. Browsers killed NPAPI, making the whole effort dead weight and leaving a generation of docs pointing at the defunct runtime.panda3d.org.

“due to major browsers having dropped support for native browser plug-ins… there’s no point in continuing development on it.” — rdb (maintainer), t/24059

“the full multi-stage pipeline implementation has been put off a bit longer, to make room for the browser plugin, which is much more important to my employer.” — drwr (maintainer), t/3904

build_apps static dependency analysis silently drops modules

Severity: major · Status: mitigated (manual include_modules)

It freezes only statically-detectable imports, so dynamically-imported deps (numpy via a transitive dep, scipy, tensorflow, pywin32, keyring) are silently omitted → runtime ImportError. Panda even hard-codes “hidden imports” for scipy.

“numpy isn’t being detected because build_apps isn’t detecting that you’re using it.” — rdb (maintainer), #1409

macOS codesign / notarization minefield

Severity: major · Status: partially-fixed

Frozen Mach-O binaries fail Apple’s strict codesign validation (“main executable failed strict validation”), blocking notarization; and a codesign --remove-signature step randomly inflated .dylibs into the gigabyte range (#871, #927).

Mobile (iOS/Android) perpetually experimental/unsupported

Severity: major · Status: still-open

10+ years of “experimental proof-of-concept ports” with no packaging path, no docs, no release builds.

“We have experimental proof-of-concept iOS and Android ports. Lot of work to still do, though.” — rdb (maintainer), t/14229

Severity & status summary

  • Blocker (on affected configs): macOS modern-GPU/Metal (10.4), core-profile default-shader cliff (6.3).

  • Major (the bulk): build/wheel fragility, the C++/Python lifetime cycles, thread-unsafety, transparency/shader-generator gaps, .bam version lock, glTF-as-addon, Bullet sync/units, single-precision worlds, DirectGUI, the bus factor.

  • Minor / footgun (correct-but-surprising): setColor vs setColorScale, Func(fn()), forward-slash paths, NPOT resize, loadPrcFileData("", ...), stereo-no-spatialize, async requestProperties.

What improved over time: the docs migration to Sphinx + GitHub PR contributions (2019), snake_case API aliases, ShowBaseGlobal as a builtins escape hatch, the Cg→in-house-shader-compiler and shader-generator/FFP parity work in 1.10/1.11, thread-safe build options, many real engine-side leak fixes, and the tp_traverse GC integration for Python subclasses. The trajectory is positive; the constraint is maintainer bandwidth.