Interestingly, the problem is kind of the opposite. The lighting is ‘full on’ in the browser, but only lights up the floor in the application. That suddenly happened a couple of weeks ago, I don’t know why. But I wondered if that was causing the ‘replaced cards’ not to show up, that is all. I am not going to fool with the lighting until I get the mechanics to work, the lighting is just fine in the browser for now (though a bit too strong on the player’s “ears” making them white).
What puzzles me is why replacing the card wall works fine in the browser but does not work at all (or at least I cannot see it) in the application. The initial images show up, but when I replace them, the wall is solid black. Puzzling. But works fine in the browser.
error: no member named ‘init_type’ in ‘InstancedNode::CData’; did you mean simply ‘init_type’?
CData::init_type();
^~~~~~~~~~~~~~~~
init_type
panda/src/pgraph/instancedNode.h:116:15: note: ‘init_type’ declared here
static void init_type() {
^
I dowloaded the latest webgl-port and the latest dependencies (thirdparty and editor directories).
Rebuilt all with new emscriptenmodule.c and the new webgl-port (and new dependencies). If anything, the images are worse with the old method.
But the Card implementation works fine in the browser if I can get rid of a glitch, though it still strangely does not work in the application version. I am working to track that down. Very odd. The first images put up are fine, but when they are replaced (which involves deleting the old one and re-creating the card), they are not there.
I found out why card doesn’t work in the application and works in the browser. The browser load saves the image as a file first, and in doing so must record the original x and y file size. I am able to retrieve these using tex.getOrigFileXSize() and for Y.
The application, however (using requests.get) never saves the images as a file, so getOrigFileXSize() returns 0. I have to either save the image as a file first or find another way to get the texture dimensions.
tex.getXSize() works perfectly on both, so looks like cards it will be.
As a sidenote, I don’t know if you are using non-power-of-2 textures, but support for those in the browser is poorer than on the desktop. Though, the default is for Panda to rescale the textures automatically, so unless you changed the configuration when running on the desktop, the behaviour shouldn’t be different.
I can’t really guess what the issue might be without having looked at your codebase and tried it for myself.
Maybe there’s a texture transform active? That doesn’t work with WebGL at the moment, because WebGL requires the use of a shader to do anything but the simplest of texturing. You could write a shader to apply the texture transform, though.
Something has happened in the latest builds, I think perhaps from something changed in the panda3d or emscripten image handling? The problem is only in the browser version. But in both cardmaker and model versions.
When I load the first 4 images in the pre-game (included in preload), they look fine. Then when I download 36 more images (saved as files) and put up four of them in the room (loading each as a texture), all images are extremely high contrast, washed out. It goes through the same code, and I have turned off all ambient lights and directional lights (which don’t seem to make any difference in the browser anyway, as you said). Is it possible that something in changing the image handling forces it to mangle the images when there are too many, or perhaps when it runs short of memory? I can’t see what is going on.
I am pretty sure a few days ago (before the update) all the images looked fine even when they were the wrong orientation.
I doubled the memory to no effect. The only difference I can see is that the images that work were loaded by preload, and the images that are washed out (again, both with the texture-on-model and texture-on-card methods) were downloaded at runtime. I am certain this was not the case last week.
I built with the old webgl-port and the images all look fine.
All right, I’ve checked in a fix to the webgl-port branch. My apologies for this.
Even though you may no longer need it, I’ve also checked in a change that enables use of texture transforms in the default shader applied in WebGL, so your wall models should now work correctly.
You are a star. I think all my problems are solved… except no doubt a few bugs of my own. Excellent! (And best part for me is that the loading of the initial screen is about 1/4 or less of what it was when I tried Godot. It took 3 minutes or more on Godot no matter what I tried. And I like so much better the pure python and especially the much better handling of signals/messages.)
!!
(Now I owe you testing on two clean devices and correcting the write-up.)
Perhaps not relevant, but I noticed that among the ‘could not locate thirdparty package’ items was jpeg. I downloaded the latest dependencies just to be sure.
Happy to hear that the issues were resolved! I’m grateful that you’re helping to find the kinks in the process. This is becoming a more viable method for deploying Panda apps, partly thanks to you.
That’s correct, you’re seeing that warning because it’s not building with libjpeg. I don’t think we need it, though, as we have other methods of loading .jpg files (the browser’s built-in decoding features when using async_wget(), or the stb_image loader bundled with Panda otherwise). Unless we run into particular jpg files that we can’t read properly without libjpeg, including libjpeg would just bloat the download size.
Um, what? Those errors make no sense to me. I didn’t touch those files at all since the beginning of January.
Did something change about your build environment? An incomplete checkout? A conflict with another build?
Perhaps you changed the version of Panda3D you’re using on the host? When building for emscripten, makepanda uses the version of the interrogate tool that ships with the host, not the one produced during the build. If you have a build of Panda3D 1.10.8 active, it should be fine.
If you continue getting the errors, please give me a more complete error log, perhaps there are other clues.
I did a from-scratch build on a different (mac) computer, and got the same libp3collide_igate.cxx error defining CollisionHandlerPhysical.
I also got earlier errors missing png.h and pngconf.h. I found copies of those files in a moai distribution, and that seemed to work – until the above error.
I can try a linux machine tomorrow. I used my script.
BTW, I believe PY_MODULE_DIR and PY_STDLIB_DIR are no longer used in freezify.py, correct?
