Generate Fade Color Parts List crashes


Generate Fade Color Parts List crashes
#1
Hi Trevor,

I got a question from a fellow Dutchman who wants to use fade steps.

Generate Fade Color Parts List crashes after a few %.
What exactly does this do anyway?
Not doing so generates fade steps just fine.


Jaco
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Generate Fade Color Parts List crashes
#2
(2016-12-07, 7:51)Jaco van der Molen Wrote: I got a question from a fellow Dutchman who wants to use fade steps.

Generate Fade Color Parts List crashes after a few %.
What exactly does this do anyway?
Not doing so generates fade steps just fine.

And a follow up question: Is there a way to fade the current step and then in the next step, the parts return to their original color?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Generate Fade Color Parts List crashes
#4
(2016-12-07, 7:52)Jaco van der Molen Wrote: Is there a way to fade the current step and then in the next step, the parts return to their original color?

Yes, but it's a bit of a manual process. The fade step functionality is quite automated and there are no settings to automatically produce the behaviour you describe.

However, if you load the model steps twice, with fade step on and off, using the LDView renderer with the 'multiple files single call rendering' checkbox checked and renaming your lpub3d generated cache files after each model load, you can subsequently replace the steps image and temp file you wish to suppress fading with the faded steps off version. As long as no model file modifications are made during this process, the updated cache will not be disturbed during file export.

Cheers,
Reply
RE: Generate Fade Color Parts List crashes
#3
Jaco,

See my returns below...

(2016-12-07, 7:51)Jaco van der Molen Wrote: Generate Fade Color Parts List crashes after a few %.

This is a known behaviour, I'm not yet sure where the problem is as my error trace don't seem to implicate my code - although I'm quite sure the segfault is initiated from my code. furthermore, the behaviour is not consistently reproducible on my system (Win10). I've seen it appear after the first (and sometimes second) generation attempt on a new install or after library download only to disappear on subsequent attempts. I think the issue may be the way I'm using threads to execute this function. I'll see if adding some assert statements will help.

(2016-12-07, 7:51)Jaco van der Molen Wrote: What exactly does this do anyway?

Generating fade parts is not required to enable the fade step functionality. The sole purpose of this feature is to re/build the colour parts list. This list captures the LDraw library parts that contain static colours excluding colour codes 16 and 24. This list is used during by the fade step capability to identify child-parts that must also be faded for the entire part to be successful faded. For example, when fading a battery box which is actually an assembly of parts with some components statically coloured, the fade step routine will check each child part against the list to see if it must also be faded. The goal is to optimize the fade step performance by fade parsing (searching and replacing the part colour) only the files on this list versus blindly parsing every child file encountered.

Generating the list is not really necessary because entries can also be manually added to the list. For example if a part is not completely faded and the implicated child part is determined to not be on the fade part list, the part can simply be added to the list via the Configuration/Edit Parameter Files/Edit Fade Colour Parts List menu item. After updating the list, re-loading the step will fade the part as expected. I also, from time to time, update the list distributed with a new release.

Cheers,
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)