Project on youtube video (linked) is very slow on my computer

Scripting Issues
1

Extremely choppy camera movement / rainbow pinwheel
I’m trying to learn how to use Panda3d through this youtube video . But when I reach the step where a large cube made of blocks is made and zoom out, my cursor turns into the rainbow pinwheel and camera movement starts getting extremely choppy. Then, panda3d seems to ‘freeze’ and I can’t do anything (or even force quit) for a few seconds. I looked around online but nobody seems to have the same issue that I’m having.

Camera Movement on Panda3d on a MacBook

  • Two fingers to zoom in and out, one finger to pan.
  • Two fingers, wait, and then place third finger to rotate.

Smooth movement when looking at object indirectly
I tried running the fully completed code that he linked on github in the description and got similar results. What’s curious however is that when I manage to turn the camera away from the center of the block, it starts running perfectly smooth. But as soon as my crosshair even goes near the center of the block, it will move very choppily and then my cursor is forcibly moved away from the block. I can’t even put my crosshair on the block without getting the choppiness and getting camera moved away.

Movement in the completed project

  • Space to go up, shift to go down
  • WASD for lateral movement

Performance on MacBook vs Desktop
To follow this tutorial I used a MacBook Pro, but judging from the mouse clicking I can hear in the tutorial, I think he’s using a desktop. I tried running the completed project on my PC, and it ran perfectly. Though I am relieved that I would be able to at least make projects, I would much prefer to be able to make projects that work on both MacBooks and desktops, and also be able to work on them away fro home from my laptop.

2

Greetings, and welcome to the forum! I hope that you find your time here to be positive! :slight_smile:

As to your issue: I’m not all that familiar with Macs, but based on what you say, it sounds like the MaxBook is simply… not up to running that program at a solid framerate.

(Quite where it’s falling short I don’t know–as I said, I’m not all that familiar with Macs. You might be able to get more information by profiling the program with PStats, if available for Mac.)

I suppose let me ask: How does the same computer run other programs, as compared to the desktop that you mentioned?

I would guess that what’s happening here is that the different perspective allows Panda to cull more of the scene away, thus reducing the load on the computer and so improving performance.

3

Hi, I don’t think this is a question of laptop vs. desktop, there must be something else.

I downloaded the game from github and it was perfectly playable on an old mac mini (2011) with Intel integrated graphics, which is certainly worse than a MacBook pro. I got mostly around 30-60 FPS, and only when zooming out so that the whole cube (4000 blocks) was in view the frame rate fell to below 20.

4

Hi,

When I run the completed code, I can see that the scene contains around 4000 independent geoms, which is too many for Panda3D, or any other graphics engine. The only reason it runs on some systems is likely due to occlusion culling, where only the surface blocks are rendered. I am inclined to think your MacBook is unable to perform this occlusion culling properly.

5

I don’t think this is it, the code uses instancing (as in the ‘chorus line’ example in the manual), it should it be ok, although there is certainly room for optimization somewhere.

I’m now convinced there is a bug in the Mac specific code in Panda3D for newer Macs. That is, code that runs fine on older versions of Mac OS suddenly crashes or misbehaves on newer Macs. I already found two instances of this (a crash and a severe memory leak).

Now, when I try that game on a new Mac Mini (M1, MacOS 14.7) it indeed totally freezes, although the frame rate is around 500 fps. (that can be seen with “sync-video false” and “show-frame-rate-meter true” in settings.prc). I don’t know the reason.

1 Like
6

The sort of instancing described in that manual entry doesn’t actually (much) reduce the number of geoms from the perspective of rendering, as I recall.

Rather, its primary advantage is that it allows the (somewhat expensive) process of skinned animation to be performed just once, rather than once per animated model.

(Although I think that it can have other benefits in certain circumstances, too.)

Well, bear in mind that if the program freezes, the frame-rate meter will likewise freeze, regardless of what it showed just freezing.

All that said, you do make some good arguments for this issue being a problem with the engine running on recent Macs.

In that case, it might be worth putting together a small, simple example program that demonstrates the issue. Maybe something that does nothing more than load a significant number of the default “smiley” model into view, with the number tuned to run acceptably on the desktop and the older Mac, but that doesn’t run acceptably on the newer Mac.

Then you could file it as an issue on Panda’s GitHub site:

7

I agree that probably there are too many separate geometries.
It is nevertheless curious that it runs ok on a very old computer.

I did a few tests.
To make sure that the mouse isn’t the cause of the troubles, I disabled the “delta time”-factor for the mouse and set the mouse mode to “M_absolute” and the system cursor to not hidden.
Furthermore, I disabled the lighting.
Neither helped much.

diff:

@@ -73,7 +75,7 @@ class MyGame(ShowBase):
 
             currentH = self.camera.getH()
             currentP = self.camera.getP()
-
+            dt = .1
             self.camera.setHpr(
                 currentH - mouseChangeX * dt * self.cameraSwingFactor,
                 min(90, max(-90, currentP - mouseChangeY * dt * self.cameraSwingFactor)),
@@ -162,8 +164,8 @@ class MyGame(ShowBase):
         self.lastMouseY = md.getY()
 
         properties = WindowProperties()
-        properties.setCursorHidden(True)
-        properties.setMouseMode(WindowProperties.M_relative)
+        #properties.setCursorHidden(True)
+        properties.setMouseMode(WindowProperties.M_absolute)#M_relative)
         self.win.requestProperties(properties)
 
     def releaseMouse(self):
@@ -241,6 +243,7 @@ class MyGame(ShowBase):
         self.sandBlock = loader.loadModel('sand-block.glb')
 
     def setupLights(self):
+        return
         mainLight = DirectionalLight('main light')
         mainLightNodePath = render.attachNewNode(mainLight)
         mainLightNodePath.setHpr(30, -60, 0)

Whenever the whole cube comes into view, the movement becomes very choppy.

If I may speculate as to the reason, maybe it is the translation layer between OpenGL and the newer Mac Graphics (Metal) that is at fault. The old Computer has native OpenGL.

I also tried running the program on Panda3D 1.11, to see if it makes a difference, but it wouldn’t load the *.glb files.
“loader(error): Extension of file grass-block.glb is unrecognized; cannot load.”

8

Probably this:

You could try running Windows version of panda in WINE, but I think the support for DX isn not great.
If you put load-display pandagles2 in your settings changes anything?

9

Hello, thanks for your input!

To answer your question, I can’t really see a difference between the two. However, this is only because I’m new to coding and Panda3d (this is the first thing I’ve ever done on panda3d), and have only ever done very simple beginner-level things on both devices.

I searched more for my issue online but STILL couldn’t find any remotely similar issues. Perhaps this will be fixed in a future version?

10

If you mean that you don’t see any difference in performance between the two computers when running other programs, then that does seem to support the idea of an engine-bug.

In fairness, I think that I meant to suggest just other programs from other sources. For example, if you take a 3D game that runs well on the desktop, does it also run well on the MacBook?

I mean, it would I daresay be more likely to be fixed if you were to open an issue for it over on GitHub, as I suggested above. :stuck_out_tongue:

(In short, the GitHub “issues” page is, I believe, how the engine devs keep track of things that call for fixing or changing. Without an issue being filed, the problem may be forgotten.)

11

No, there is only “CocoaGraphicsPipe” available as a pipe type.

12

Hi there!

I don’t know why it ran better on an older Mac, but I ran the linked GitHub project on my M2 MacBook Air and I got the same choppiness when looking down. Maybe the arm64 CPUs botleneck in different ways. Or maybe you are actually running the x86_64 version of Python under emulation?

I ran it through PStats and I found that it is spending a huge amount of time in garbageCollectStates, which is due to a very large number of TransformState objects:

image
image1632×1250 161 KB

This is caused by there being a lot of objects all with their unique transformation (position). @Thaumaturge already went into more detail.

Now, it’s possible to set some settings to alter the transform cache, such as lowering “garbage-collect-states-rate” or even setting “garbage-collect-states false” in Config.prc, which will certainly help a bit, but mostly move the problem around. If I do that, I’m still seeing unacceptable performance, but now mostly in Cull, due to the huge amount of objects that the Cull pass is visiting.

Minecraft-like worlds are deceptively hard to render well with good performance.

The best way is to flatten multiple objects together, or even better generate the cubes procedurally as part of a large Geom. To get efficient collisions, you need to structure your collision scene hierarchically (and it would live separate from your render hierarchy). For a voxel scene, octrees work well.

Panda3D 1.11 (in development) is introducing InstancedNode, which allows you to get real instancing and render this kind of scene more efficiently without flattening or procedural generation.

I think it’s so slow that it’s not actually getting around to updating the frame rate meter. The “200 ms” frames I’m seeing in PStats speak for themselves. That’s 5 fps, not 500!

Yes, there is a severe memory leak that was recently fixed on newer Macs. The fix will be fixed in the upcoming 1.10.15 release. You can get a pre-release build from here:
https://buildbot.panda3d.org/downloads/52a7224d6ec86db4c18d18e658de0bbf79f649e2/

The next time you encounter a crash, if you could save the crash report information, that would be much appreciated!

1 Like