-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loading blend files with lights in second runs moves them in-game. #44
Comments
If you disable the model cache, by setting |
Yes |
I suppose I should include the following: Blender: 2.90/2.91 I'm running this inside a vscode .devcontainer, but that shouldn't be making a difference. |
It may be an issue with Panda's model cache then, could you add a Then, try loading the resulting bam file and see if the problem is reproduced. If so, please share the bam file. |
Issue is present in saved bam file, regardless of whether the model cache is disabled. There's no difference in the information printed by |
Thanks, and can you share the .blend file as well for comparison? |
scene.blend.zip |
I think this is a bug in Panda3D, and I will look into fixing it. You can use this as a workaround: scene.clearLight()
for light in scene.findAllMatches("**/+Light"):
scene.setLight(light) |
I don't think this issue can be fixed in Panda3D 1.10.8 (but will need to be in 1.11), but a workaround can be implemented in blend2bam, see #45. |
Thanks! |
When a LightAttrib is set on the root of a model and the light is contained within that model, creating a copy (like the one Loader makes automatically) causes the LightAttrib to still point to the original light, not to the newly copied light. This works around it only for the case when the LightAttrib is set on the root, and only for the case of NodePath::copy_to() (it turns out there are edge cases when doing it in PandaNode::copy_subgraph() that would be hard to explain). See Moguri/blend2bam#44
When a LightAttrib is set on the root of a model and the light is contained within that model, creating a copy (like the one Loader makes automatically) causes the LightAttrib to still point to the original light, not to the newly copied light. This works around it only for the case when the LightAttrib is set on the root, and only for the case of NodePath::copy_to() (it turns out there are edge cases when doing it in PandaNode::copy_subgraph() that would be hard to explain). See Moguri/blend2bam#44
Sorta.
Taking a blend file and loading it via
loader.loadModel("reference/to/the/file.blend")
, the second time the program is run the light is ...missing. Or something. It's no longer having the same effect on the render result, but the listed position from printing the tree hasn't changed.This only seems to have an effect on "live"
.blend
files - manually packing the.bam
file for distribution works fine. Saving the file resets the issue. So whatever is going is almost certainly related to the conversion cache, but it's not clear why.First run:
![image](https://user-images.githubusercontent.com/5569508/100807948-14d71000-33e8-11eb-8f60-136a28f887c6.png)
Second run:
![image](https://user-images.githubusercontent.com/5569508/100807973-23bdc280-33e8-11eb-8c3b-558661d95d93.png)
Changing the light type from point to directional (Sun) makes it imply that the light is rotated around somewhere:
![image](https://user-images.githubusercontent.com/5569508/100808867-cd518380-33e9-11eb-9d03-378a78c2b07c.png)
Trivial program file:
The text was updated successfully, but these errors were encountered: