Thanks for reading my report.
On variations: I understand that you’ve already done a great job on this level, sorry if my critic was too harsh. But adding text to street signs is not so hard and it could help the case, don’t you think so?
Yes, it’s the way to reproduce it. I am running windows build on windows 10. I’ve noticed that it drops on 2nd or 3rd time and then either restores in 2-3 minutes, or doesn’t restore at all, so I have to restart the game.
It wasn’t too harsh at all! Don’t worry about that. Whatever feedback you have, I want to hear it. 
Hmm… I only have a few street-signs present in the level right now, and I’m not sure that they alone would add enough to justify the work. If I’m going to add further in this way, I think that I would rather that it be in the form of something that helps to build the world–graffiti, or items lying around, etc. It’s something that I’m still giving thought to!
Ah, that’s interesting–in particular the fact that the frame-rate does recover.
You see, I have noticed that there’s a significant spike in program-activity when loading a level. This makes some sense: there’s a fair bit of cleanup to do, followed by a fair bit of construction, and then presumably engine-level tasks as Panda sorts out what data the graphics card has.
On my machine, this spike disappears almost immediately after loading. But perhaps, if it’s a little too high, your machine might not be recovering from it quite so readily…
I can perhaps look into whether that spike can be brought down, but I do have my doubts…
Still, I intend to consider opening a thread here on the forum asking for advice on this, as I’m otherwise not sure of how to proceed with it…
Looks very cool 
Is there a macOS build available? I currently have no to access to Windows or Linux (only through a VM) 
Thank you very much! 
I’m afraid not: my situation is more or less the inverse of yours, being that I have access only to Windows and Linux, but not to Mac. (And I don’t want to put out a build for a platform that I haven’t tested on.) ^^;
Ah, alright, that’s understandable 
I’ve just released a “redux” demo–a version of the demo that incorporates myriad fixes, tweaks, and changes, some in response to player-feedback.
I’ve updated the first post, but in short:
Demo link:
Major updates:
Have fun, and let me know what you think!
I can say 3 things at the start.
Grass obviously lacks volumetric shadows, or some shadows.
These shadow artifacts look strange for 2020
When I thought to minimize the game, to answer on the site, the game crashed.
Indeed. In part that’s a stylistic choice: it resembles the way that one might paint grass. And in part it’s a performance choice: creating shadows for all that grass would, I fear, be prohibitive.
(Indeed, I’ve actually been considering reducing the degree of dynamic shadowing, using a static shadow-map for most things and a dynamic one for only carriable objects.)
Yup, I may want to get around to going through that article that I have on improving shadow-map quality. It’s an awkward angle that the sunlight meets the pyramid, too.
Oof, that’s a new one! I… don’t think that I’ve tried minimising the game before.
Hmm… A quick test seems to indicate that it works on my end, under Ubuntu at least. I should try it under Windows. In the meanwhile, I don’t suppose that the log-file contains a crash-report, does it?
Thank you for reporting this! (And for trying out the game, of course!)
Ah forgot, I’m on the window 7.
I minimized the application when starting 1 level. And this time the game slammed shut without a message.
log:
Known pipe types:
wglGraphicsPipe
(all display modules loaded.)
:Actor(warning): Cannot control joint head
Assertion failed: !child_vector.is_nan() at line 59 of c:\buildslave\sdk-windows-amd64\build\panda\src\physics\linearForce.cxx
Assertion failed: !child_vector.is_nan() at line 59 of c:\buildslave\sdk-windows-amd64\build\panda\src\physics\linearForce.cxx
:task(error): Exception occurred in PythonTask manager-update
:GameMessages(warning): Traceback (most recent call last):
File "GameCore.py", line 1474, in <module>
File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5.dev125-cp36-cp36m-win_amd64.whl/direct/showbase/ShowBase.py", line 3152, in run
File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5.dev125-cp36-cp36m-win_amd64.whl/direct/task/Task.py", line 537, in run
File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5.dev125-cp36-cp36m-win_amd64.whl/direct/task/Task.py", line 491, in step
File "/home/thaumaturge/Documents/My Game Projects/DoorToTheMists_DEMO/build/__whl_cache__/panda3d-1.10.5.dev125-cp36-cp36m-win_amd64.whl/direct/showbase/ShowBase.py", line 1815, in updateManagers
AssertionError: !child_vector.is_nan() at line 59 of c:\buildslave\sdk-windows-amd64\build\panda\src\physics\linearForce.cxx
An old error surfaced!
Argh! I do wonder what’s causing that one–and why in all existence it turned up when minimising the application! o_0
Well, I’m very glad that the logfile caught it–at least we know what error we’re dealing with.
And one positive of it being this error is that I don’t think that it’s related to the operating system: I’m pretty sure that I’ve had it happen under Linux. That at least aids investigation for me.
[edit] You say that it happened when you were loading a “1 level”–do you mean the prologue/tutorial level? Or the one after that? Or am I misreading you?
If it’s related to a particle force, it might help to know which level, and thus which particle-system…
There are two situations.
When level 1 is loaded, when minimizing the game without action. This error comes out AssertionError: !child_vector.is_nan(). Stably repeats.
However, it is worth going a few steps and minimizing the game, then the application crashes.
log:
Known pipe types:
wglGraphicsPipe
(all display modules loaded.)
:Actor(warning): Cannot control joint head
Assertion failed: !pmin.is_nan() at line 1356 of c:\buildslave\sdk-windows-amd64\build\panda\src\gobj\geom.cxxPyramid
Ah, thank you for the clarifications!
Hmm… the odd thing is that the new error that you just posted looks like something else–something in “geom.cxx”–although I suppose that it’s possible that it’s related to particles, still…
To my annoyance, the same procedure doesn’t seem to be producing the error under Linux. I may well give it a shot under Windows 8 tomorrow–but I don’t have Panda installed there for debugging purposes.
I thought that it might be related to something not being properly cleaned up, perhaps being caught out during loading–but why minimising would affect that I don’t know, and it seems unlikely given that it can happen after taking a few steps in the level…
I can add that this does not happen immediately, but after 5 - 7 seconds. It seems to be that mystical 
Most odd. o_0
If it were a slightly shorter time, it might be the time required for the first particle to be birthed: I think that the particle systems in that level “give birth” at a rate of one particle every few seconds.
But as you know, this is not all. If you manage to return to the game before the error, then everything is OK, you can play on.
I think for starters you need to create an application with an empty window and particle effects enabled. To avoid unnecessary thought about your code. It just might be a panda bug. Now in this phenomenon there is a clear moment in time for tracking.
You’re quite right, indeed; that’s a good idea.
The tricky bit is going to be reproducing it–I may ask for your help with that, if that’s okay. But I’ll not do that tonight I think–it’s late. Perhaps tomorrow!
While you were sleeping, I discovered a problem!
A short example.
TestWindows.zip (2.0 KB)
To do this, set full screen mode, when you open the window, minimize the application and wait.
The issue here is:
f0 = ForceGroup.ForceGroup('LeafForce')
# Force parameters
force0 = LinearVectorForce(Vec3(0.0000, 0.0000, -9.8000), 1.0000, 0)
force0.setVectorMasks(0, 0, 1)
force0.setActive(1)
f0.addForce(force0)
force1 = LinearFrictionForce(1.0000, 30.0000, 0)
force1.setVectorMasks(0, 0, 1)
force1.setActive(1)
f0.addForce(force1)
force2 = LinearNoiseForce(0.0100, 0)
force2.setVectorMasks(1, 1, 0)
force2.setActive(1)
f0.addForce(force2)
self.addForceGroup(f0)
I have not found a connection yet. But I think the clue is close.
Some forces seem to conflict with each other. Separately, they work without crashing the application.
This pair of forces seems to cause a glitch.
force0 = LinearVectorForce(Vec3(0.0000, 0.0000, -9.8000), 1.0000, 0)
force0.setVectorMasks(0, 0, 1)
force0.setActive(1)
f0.addForce(force0)
force1 = LinearFrictionForce(1.0000, 30.0000, 0)
force1.setVectorMasks(0, 0, 1)
force1.setActive(1)
f0.addForce(force1)
Known pipe types:
wglGraphicsPipe
(all display modules loaded.)
Assertion failed: friction.almost_equal(LVector3::zero()) || IS_NEARLY_EQUAL(nor
malize(v).dot(normalize(friction)), -1.0f), file c:\buildslave\sdk-windows-amd64
\build\panda\src\physics\linearFrictionForce.cxx, line 65
However, this is how they work.
force0 = LinearVectorForce(Vec3(0.0000, 0.0000, -9.8000), 1.0000, 0)
force0.setVectorMasks(0, 1, 0)
force0.setActive(1)
f0.addForce(force0)
force1 = LinearFrictionForce(1.0000, 30.0000, 0)
force1.setVectorMasks(0, 0, 1)
force1.setActive(1)
f0.addForce(force1)
I changed force0.setVectorMasks (0, 1, 0)
I tested the full game by replacing this line. The application did not crash when minimized. However, the leaves fly slowly.
Fascinating… And thank you very much for so researching this! I really appreciate it.
Hm. It’s been a while since I made this system, and I’m struggling to find a reference for those masks. However, I imagine that the leaves are moving slowly because, in the working version, only the y-element of the force is being used (per the force-mask), and the y-element of the LinearVectorForce is 0. Thus the leaves don’t accelerate downwards any more.
So… It seems like the combination of acceleration and friction is what’s causing the problem…
I’ll update the GitHub issue with this information, I think.
Hmm… As to the demo, if this proves problematic to fix, I may be able to get away with just applying a static initial velocity–although I’ll want to be confident that the NoiseForce still has the desired effect, if so…
[edit] I’ve linked your example-program in the issue, by the way; if that’s a problem, please let me know!