Do you use pure panda or you use something like Ursina?
Usually :linmath(warning): Tried to invert singular LMatrix4. pops up when you tries to downscale a model to negative values.
no, probably because the program was much less complex (as in, it only placed three models in specific spots, but the main program generated buildings, cars and NPCs randomly)
also, for your second question, yeah, i change the scale of cj.glb to 0.02 and i change the size (not scale but maybe those are the same thing) of cube.glb to many different things
@imbomania pure panda
If you make all models by yourself, make shure that their axis is all the same.
Maybe somewhere you setting scale within loop and don’t check for scale > 0.
Also make shure that you don’t call .removeNode() on loaded model somewhere.
For initial problem, try to store a path to file and then load the models with stored path + “model_path”.
Something like:
from panda3d.core import *
import os
default_path = Filename.fromOsSpecific(os.path.dirname(os.path.abspath(__file__)))
#default_path here will be a /c/my_game if currently running py file is in C:\\my_game
path_to_model = default_path + "/models/model_name.glb"
#path_to_model become "/c/my_game/models/model_name.glb"
model = loader.loadModel(path_to_model)
yeah the thing is i just downloaded them from sketchfab or something
In that case, indeed, it sounds like it’s coming from something in your code–perhaps somewhere, somehow, a scale (or component of a scale) is ending up as zero.
I’m… not sure of how one could change the size without changing the scale… Unless you’re doing it in a shader or something?
But yes, maybe it would help if we could see just the portions of code that change the scale/size of objects. Maybe there’s something there that could be causing the problem!
A minor clarification here: To the best of my knowledge, It’s not the negative values themselves that are the problem–a scale of -1 is perfectly valid.
However, since things tend to start at positive scales, moving (e.g. interpolating) to negative scales can involve passing through zero–and it’s at a scale of zero that one can encounter problems.
Hence code that shifts something from a positive to a negative scale can incur such an error.
self.ground = self.loader.loadModel(to_panda_path(os.path.join(exe_dir, "models", "cube.glb")))
self.ground.reparentTo(self.render)
self.ground.setScale(200,200,1)
this makes the ground
Hmm… I see no obvious problem there.
Is there no other code in which you alter scale/size in any way?
there’s one where i just do setScale(0.02)
Hmm… That should be fine, I imagine.
Could there be an animation associated with one of your animated models that applies a scaling factor?
(Or–just to check–are you using any Intervals that might affect scaling? e.g. a ScaleInterval or a LerpPosHprScaleInterval, or some such thing?)
nope, no animation, i only move the models
Very odd!
Let me just check, to be cautious: Is there anything–even if it’s not the thing that looks odd–that might be scaled at all, the code for which you haven’t shown us? Even a GUI-object, or a TextNode, or something?
You might also try the test suggested in the following post–it may turn up an object that’s been overlooked!
(Click through for proper formatting; it looks like the preview removes a lot of white-space, thus breaking code formatting.
The basic idea would be to add that code to some place in your main program that’s run at around the time that you’re seeing errors.)
Oh, and one more check: For the loading of glb files, are you using panda3d-gltf, or Assimp, or something else?
On another note, looking at the manual, I do see that there’s advice there to convert glb and gltf files to bam. It might be worth trying that, and seeing whether the problems persist.
Can you share the code on github or something? Just code will be enough.
I suspect cx_freeze is not pulling panda3d-gltf into the frozen binary, and you might be getting the Assimp gltf importer instead. You can try adding import gltf to your main script to get cx_freeze to notice it.
1 Like
nope, that didn’t work
@Thaumaturge i have no idea but i’d assume i’m using panda3d-gltf
That’s actually a good thought: it might be worth checking that gltf is making it into the build.
What I might suggest is this: in your main program, import “gltf”, as Moguri suggested. Then, directly after, print it–that is, run the line: print (gltf)
I think that doing so should print out a string-representation of the module, if the module has been imported successfully.
Try this in both as interpreted script and as a built executable (the latter either run from command-line or writing to a log-file), and see whether the printed output differs between them.
python file: “<module ‘gltf’ from ‘C:\Users\my username\AppData\Local\Programs\Python\Python311\Lib\site-packages\gltf\__init__.py’>”
EXE: <module ‘gltf’ from ‘C:\Users\my username\OneDrive\Pulpit\gta\build\exe.win-amd64-3.11\lib\gltf\__init__.pyc’>
Well, I’m no expert in this side of things, but it looks at least as though gltf is being successfully imported.
Well, in that case, I might suggest again trying to convert your models to bam-files, and seeing whether the problems persist when using that format.