in daematerials.cxx and daematerials.h

make change to:

same in ftltheader.h and fltheader.cxx

in maxeggloader.cxx (have a closer look at this one)

need to have a look too to .\panda3d\pandatool\src\vrmlegg\indexedFaceSet.h
class VrmlPolygon {
EggPolygon _attrib;
epvector _verts;
}; ???

… and so on

At this point let me switch to --no-pandatool and try to pursue…

… almost done, but for whatever reason pzip is giving problems while compressing models (first time I see this…)


I am interested to test this out too. :slight_smile:

I think odeBody has the same issue with the set_quaternion function. After making the suggested change the build continues. Will see where it ends up in the morning.


pzip is generating crashes at the end of the build
this seems to be related to compress_stream.cxx in libpandaexpress.dll

here is the call stack:


Make sure too that
.\panda3d\thirdparty\win-libs-vc9\eigen\include\Eigen directory is moved to build/include


I’ve committed the suggested changes to the repository, thanks for that.

I’ll be able to investigate the runtime crash in a couple of hours. My apologies for these unexpected issues; I hadn’t actually tried to run this thing on Windows yet (I’ve been doing most of my development on OSX and Linux).

Edit: the pzip crash appears to be intermittent. I saw it happen once, but now I can’t get it to happen again. Still investigating. . .



Go David go! :stuck_out_tongue:


Almost ok, but still getting pzip.exe and flt2egg.exe crashing at the very end of the build

build launched with

1>**Number of tasks left 31 out of [T1] Compressing  497built/models/misc/fade_sphere.egg.pz 
1> starting tasksbuilt/bin/flt2egg -ps keep -o built/models/misc/fade_sphere.egg dmodels/src/misc/fade_sphere.flt
1>Reading dmodels/src/misc/camera.fltReading dmodels/src/misc/fade.flt
1>Writing built/models/misc/camera.egg
1>Writing built/models/misc/fade.egg
1>built/bin/pzip built/models/misc/camera.egg
1>The following command returned a non-zero value: built/bin/flt2egg -ps keep -o built/models/misc/fade_sphere.egg dmodels/src/misc/fade_sphere.flt
1>Storing dependency cache.
1>The following command returned a non-zero value: built/bin/pzip built/models/misc/camera.egg
1>The following command returned a non-zero value: built/bin/flt2egg -ps keep -o built/models/misc/fade.egg dmodels/src/misc/fade.flt
1>Elapsed Time: 1 hours 9 min
1>Build process aborting.
1>Build terminated.
1>Build log was saved at "file://c:\Users\jc\Desktop\PANDA_BUILD_BOT\Source MAJ\panda3d\built\BuildLog.htm"
1>makepanda - 0 error(s), 235 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========


I get the same thing. If I keep running the build repeatedly it eventually makes it to then end, but the resulting build crashes.


I think I found it. It was a problem with our underlying ptmalloc2 scheme, which didn’t like being asked to provide 16-byte alignment for some reason. I fixed it by not using that scheme anymore; it turns out not be the performance advantage it used to be anyway.

Let me know if you’re still seeing these crashes. My own Windows build seems to be stable.



too bad, something new is popping up :


Whoops, sorry, there are lots of different build options, and I missed a case. :frowning:

Please try it again.



ok, restarting!

btw. where is LINMATH_ALIGN defined?

edit: DONE! Thank you once more David !


In makepanda.py. It’s hardcoded on by default.



I was able to build successfully, but got a bit of a snag here:

from panda3d.core import *
from direct.showbase.ShowBase import ShowBase

class Game(ShowBase):
    def __init__(self):
        """Get the game ready to play."""
        self.node = render
        self.model = self.loader.loadModel('smiley')
        shaderdata = Mat4(0, 0, 0, 0,
                          0, 0, 0, 0,
                          0, 0, 0, 0,
                          0, 0, 0, 0)
        self.model.setShaderInput('shaderdata', shaderdata)

game = Game()
Assertion failed: sizeof(mat(0, 0)) * mat.size() == pta.size() * sizeof(pta[0]) at line 338 of c:\work\panda3d\built\include\shader.I
Traceback (most recent call last):
  File "test.py", line 18, in <module>
    game = Game()
  File "test.py", line 16, in __init__
    self.model.setShaderInput('shaderdata', shaderdata)
AssertionError: sizeof(mat(0, 0)) * mat.size() == pta.size() * sizeof(pta[0]) at line 338 of c:\work\panda3d\built\include\shader.I


Whoops. Clearly when I said “I think I’m done” back in post 2 of this thread, what I really meant was “I’ve committed everything and haven’t tested a damn thing.”

Please give it another try now. :wink:



Hey David,
Forgive us to have put you under pressure… but you know Panda’s groupies are like spoiled children waiting anxiously for Xmas morning!
:laughing: :laughing:


As far as I believe now, everything is correct and working. Please let me know how your own experiments go. :slight_smile:



First thing I notice is Panda is using up a lot more system memory. Running my game the frame rate was actually a bit lower, but then I remembered about clearing out the BAM cache. Unfortunately, it is now crashing with an out of memory message (presumably while generating BAM files):

Couldn't allocate memory page of size 131072: Not enough storage is available to
 process this command.

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

That is for the game client. The server does run and takes up about 1.2GB of RAM as opposed to 0.6GB previously.


Hmm, that’s strange. I would have expected a bit more memory usage, due to the 16-byte memory alignment requirements, but not double. Maybe the code itself is now much bigger due to the template explosion problem? This bears investigation.



My early experiments seem to indicate about 20-30% more memory required by ordinary Panda operations. I’m trying a compile now with the original alternative malloc scheme to see how much of this bloat is due to alignment requirements and how much is due to the change in malloc schemes.

Is that 30% additional requirement enough to push you over the edge on the client? How close were you running previously? How much does memory grow before your client dies?

Edit: another thought–are you perhaps comparing against the memory usage in 1.7.2? It’s also possible that the threading change with 1.8.0 is another major contributor to more memory consumption.

Would you be satisfied to use a Panda3D compiled with Win64, to allow it take advantage of more than 2GB of RAM?