I'm working on a model that has a lot of black parts, so I've started using fading to make it clearer where the parts go for each step. However, I've run in to a problem that I can't seem to figure out. When I use BUFEXCHG to go from an "exploded" view with arrows to the resulting assembly, the fading isn't working consistently on the subsequent step. In one place, all of the parts added to the retrieved buffer in the next step are faded when they shouldn't be--resulting in a step that is all faded. In another place, some of the parts are faded and some are not.
I've been flailing away at this for a while, but haven't come up with a way to get it to work properly.
The closest I've come is this approach:
1) Assemble the parts that are common the the "exploded" view and the final assembly (including 3 sub-assemblies). This generates the building instructions for two of the sub-assemblies. The third sub-assemble is a call-out
2) Store this in two buffers, A and B
3) Build up the rest of the assembly with parts in the proper position.
4) Store the resulting assembly in buffer B
5) Retrieve buffer A
6) Build up the rest of the "exploded" assembly between !LPUB PART BEGIN IGN and !LPUB PART END statements
7) Display this "exploded" assembly with a ROTSTEP statement
8) Retrieve buffer B
9) Display this assembly with a STEP statement. Entire assembly shows up as faded.
10) Add the next step's parts and display with STEP statement.
I don't really want to display the faded assembly in step 9, but that's the only way I've gotten the subsequent step to display properly. If I leave out the STEP statement at step 9, the parts in step 10 ended up faded along with the assembly generated in step 3.
It seems like LPub3D is having a hard time sorting out what constitutes a prior assembly for fading after buffer exchanges.
If anybody has gotten this to work properly, please share your technique. I'd be eternally grateful.
Trevor--if this is something that hadn't yet been planned for in the LPub code, I have a suggestion: create a new 0 !LPUB directive that provides an unambiguous demarcation--a way to tell LPub that the current state of the assembly should be faded (without display) and subsequent parts not faded up until the next STEP, ROTSTEP, or the end of the (sub-)assembly.
For the record, I am resetting all caches prior to each attempt. Also, it seems that resetting image and 3D caches (the first choice in the dropdown), also resets unsaved changes in the mpd file. Minor inconvenience now that I've figured it out, but a frustrating PITA before that.
I'm attaching the current version of my mpd file. The problem areas are in pages 11-13 and 31-32.
Thank you.
BTW--I use a custom annotation font and pli.mpd file, so you're results will probably be slightly different than mine, but these don't affect the fading.
I've been flailing away at this for a while, but haven't come up with a way to get it to work properly.
The closest I've come is this approach:
1) Assemble the parts that are common the the "exploded" view and the final assembly (including 3 sub-assemblies). This generates the building instructions for two of the sub-assemblies. The third sub-assemble is a call-out
2) Store this in two buffers, A and B
3) Build up the rest of the assembly with parts in the proper position.
4) Store the resulting assembly in buffer B
5) Retrieve buffer A
6) Build up the rest of the "exploded" assembly between !LPUB PART BEGIN IGN and !LPUB PART END statements
7) Display this "exploded" assembly with a ROTSTEP statement
8) Retrieve buffer B
9) Display this assembly with a STEP statement. Entire assembly shows up as faded.
10) Add the next step's parts and display with STEP statement.
I don't really want to display the faded assembly in step 9, but that's the only way I've gotten the subsequent step to display properly. If I leave out the STEP statement at step 9, the parts in step 10 ended up faded along with the assembly generated in step 3.
It seems like LPub3D is having a hard time sorting out what constitutes a prior assembly for fading after buffer exchanges.
If anybody has gotten this to work properly, please share your technique. I'd be eternally grateful.
Trevor--if this is something that hadn't yet been planned for in the LPub code, I have a suggestion: create a new 0 !LPUB directive that provides an unambiguous demarcation--a way to tell LPub that the current state of the assembly should be faded (without display) and subsequent parts not faded up until the next STEP, ROTSTEP, or the end of the (sub-)assembly.
For the record, I am resetting all caches prior to each attempt. Also, it seems that resetting image and 3D caches (the first choice in the dropdown), also resets unsaved changes in the mpd file. Minor inconvenience now that I've figured it out, but a frustrating PITA before that.
I'm attaching the current version of my mpd file. The problem areas are in pages 11-13 and 31-32.
Thank you.
BTW--I use a custom annotation font and pli.mpd file, so you're results will probably be slightly different than mine, but these don't affect the fading.