Add a New Comment Rich Markup
Thanks for the update, I'll look into it when time permits!
I was mistaken about the reason for the changes to the 3D lighting. Rather than generating lighting values, the program uses those from a different design (presumably a bad pointer). The workaround is to first create the 3D design then immediately update the 2D design before exiting Settings. If you later decide to change the 2D design, you should copy the 3D design to a new board and do the same thing.
When you change a 2D design, it also results in changes to the lighting of its 3D equivalent (sometimes subtle, sometimes dramatic). Then when you try to reverse the changes to the 3D board, nothing is saved. I have "before and after" xml sections if you want to see them, but you should be able to recreate the problem easily. I think what's happening is that when you change the 2D design it enters the code used for NEW designs and generates at least the lighting values for a 3D equivalent. As for why no lighting changes are changed for 3D boards, note that it's not like the "General" parameters - it clearly should be saved since it makes a big difference in board appearance.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Copyright © 2024 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Page source code
Powered by Savane 3.13-d3ae.Corresponding source code