Panda3D 1.4.0 slower than 1.3.2

General Discussion
1

I installed Panda3D 1.4.0 on my laptop and it runs slower than 1.3.2. For example:

Roaming Ralph
1.3.2: average is about 49 to 50 fps, slow points 46 fps
1.4.0: average is about 31 to 33 fps, slow points 21 fps

There are some performance decreases in other sample programs, like Airblade but it was not as apparent as Roaming Ralph.

The laptop is a few years old (1.6 GHz Pentium M, 32 MB ATI Radeon, 512 MB RAM), but I’ve noticed a similar trend on my PC. I was just wondering if anyone else has noticed this performance drop :confused:

2

Hmm, that’s disturbing. In general, 1.4.0 includes several performance enhancements, and in fact the latest Panda does run measurably faster on our own games here within Disney. I haven’t done a side-by-side on Airblade or Roaming Ralph, though. I’ll look into it.

David

3

run faster here too

4

Would it be possible to try testing Roaming Ralph on the two versions? Maybe its because I have an old video card on both my PC and laptop.

5

v1.4.0 has a serious collision performance drop :
discourse.panda3d.org/viewtopic.php?p=15391

6

Indeed, collision system has dropped frame rate very noticable. :frowning:

7

Saw your post yhjh_jo about your menu and the 1.4.0 performance drop.

I was worried about these kinds of problems and didn’t upgrade to 1.4.0 until yesterday. Running my main project- I haven’t seen any performance drop (yet). I use a lot of collision spheres and haven’t seen any issues. Are you using collisions spheres or other types of collision solids?

On average in my program I have about 20 ‘from’ colspheres and probably 150 ‘into’ colspheres.

–EDITED–
After some more tests- I confirm the same frame rate drop. Guess, I’ll be going back to 1.3.2

8

I just tested Roaming Ralph and I too get the same drop in frame rate.

1.4.0: 13-15 fps

1.3.2: 25-30 fps

9

Atleast I am not the only one experiencing this drop in frame rate… Is there any way this problem can be addressed and fixed in the next version, say a 1.4.1 or something?

I would rather upgrade to the latest version instead of having to use 1.3.2.

10

Wellllll… thats what the x.y.0 Versions are for - testing. ^^

Seems like you did a good job. Hope, Josh, David and folks can fix it in the upcoming 1.4.1.

If not, I would expect to see an 1.4.2 somewhen in the not-so-far future addressing it :smiley:

Regards, Bigfoot29

11

It seems very likely that it will be fixed in 1.4.1 or 1.4.2. (These little bugfix releases usually come pretty soon after the major release).

But really, panda 1.3.2 is still quite recent, and very stable.

12

Josh,

Do you know if this was addressed in the new 1.4.1?

Thanks,

13

Yes, it’s supposed to be. But David has also told me that there’s a different way of doing collision against geometry — you convert the geometry to “collision geometry” by putting a special tag in the egg file. Doing this makes the detection vastly faster, since collision geometry is optimized for this sort of thing. This is the way it’s supposed to be done. I’m going to eventually fix the roaming ralph sample to do it the right way.

14

Josh,

Any idea how to do that programatically? I use dynamically updated terrain…

15

Unfortunately not. However, if all you’re trying to do is keep Ralph at the right elevation (which is what Roaming Ralph is trying to do), then I would just use the original heightfield to fetch the elevation.

In the long run, I think we’re going to need a subroutine that converts standard geometry into collision geometry.

16

If you were to add “collision geometry” to roaming Ralph, what would be the procedure? Can it be down to the egg as it is now or does a completely new egg file need to be created?

17

The procedure would be to add a few words to the egg file indicating that a certain collection of polygons are collision geometry, not regular geometry. I don’t remember the magic words - I think it might be { Polyset } or something like that. To find the actual incantation, I’d have to read the eggSyntax.txt document. You can find a link to this document by reading the panda manual under egg importing and exporting.

18

to convert Geom into CollisionPolygons, you need to do :

  1. create CollisionNode
  2. for every triangle, create a CollisionPolygon and add it to the CollisionNode

taken from my polygonal button :
discourse.panda3d.org/viewtopic.php?p=15762

  def convertGeom2CollPoly(self):
      geomParent=self.geom.getParent()
      cn=CollisionNode('CN-'+self.geom.getName())
      self.collNP=geomParent.attachNewNode(cn)

      collGeom=self.geom.copyTo(geomParent)
      collGeom.setTransform(self.geom.getTransform())
      collGeom.flattenStrong()

      collNumVtx=0
      collVertices=[]
      geom=collGeom.node().getGeom(0)
      collVtxData=geom.getVertexData()
      numVtx=collVtxData.getNumRows()
      # create vertex reader
      collvtxreader=GeomVertexReader(collVtxData)
      # set the start position for reading the vertices,
      # begin reading at column 0, which is vertex position
      collvtxreader.setColumn(0)
      for prim in range(geom.getNumPrimitives()):
          # decompose high-order primitive
          collFaceData=geom.getPrimitive(prim).decompose()
          for i in range(0,collFaceData.getNumFaces()*3,3):
              collvtxreader.setRow( collFaceData.getVertex(i) )
              vtx1=collvtxreader.getData3f()
              collvtxreader.setRow( collFaceData.getVertex(i+1) )
              vtx2=collvtxreader.getData3f()
              collvtxreader.setRow( collFaceData.getVertex(i+2) )
              vtx3=collvtxreader.getData3f()
              cn.addSolid( CollisionPolygon(vtx1,vtx2,vtx3) )
      # remove the temporary Geom
      collGeom.removeNode()
      # put the collision node to be the visible geometry's child
      self.collNP.wrtReparentTo(self.geom)

In there, I simply make a copy of the geom and flatten the transform, since I don’t need any fancy structure for buttons.

PS : I haven’t tried v1.4.1 yet

19

Thanks ynjh_jo! I’ll implement this into my terrain system.