LPub3D 2.0.5 - Can't get fading to work with BUFEXCHG

[Kevin]

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.

[Trevor Sandy]

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.

Hi Kevin,

Thanks for the detail issue description. 

To be honest, I never intended fading to address some of the more complex directives like multiple buffer exchanges. I implemented this feature for my daughter to see the progress of straightforward additive building 

Anyway, I will take a look at your scenario and see if I can figure out what to do to address it.

Perhaps you can help by sending a step-by-step visual of the behavior you are experiencing - against what you expect nominally. A sequence of screenshots would be fine. 

Cheers,

[Kevin]

Trevor,

Thanks for taking a look.  Here are a couple images to demonstrate what I'm experiencing. 

In scenario 1, you see what happens when I use a BUFEXCHG RETRIEVE and then immediately add parts before displaying the results with a STEP or ROTSTEP.  In the second frame, all the additional pieces are faded when attached to the retrieved assembly.  In the fourth frame, some are faded and some are not.

   

In scenario 2, you can see that I'm getting the correct results if I add a STEP/ROTSTEP after the BUFEXCHG RETRIEVE but before I add the additional parts.  However, I don't want to see the faded assembly before I add parts.

   

Perhaps this could be fixed by adding an LPUB directive that signals sets a demarcation between faded and not-to-be faded parts in a step--the equivalent of a STEP/ROTSTEP without the display.

Once again, thanks for all your work on LPub3D.  It's an amazing tool. 

Kevin

[Trevor Sandy]

Trevor,

Thanks for taking a look.  Here are a couple images to demonstrate what I'm experiencing. 

In scenario 1, you see what happens when I use a BUFEXCHG RETRIEVE and then immediately add parts before displaying the results with a STEP or ROTSTEP.  In the second frame, all the additional pieces are faded when attached to the retrieved assembly.  In the fourth frame, some are faded and some are not.



In scenario 2, you can see that I'm getting the correct results if I add a STEP/ROTSTEP after the BUFEXCHG RETRIEVE but before I add the additional parts.  However, I don't want to see the faded assembly before I add parts.



Perhaps this could be fixed by adding an LPUB directive that signals sets a demarcation between faded and not-to-be faded parts in a step--the equivalent of a STEP/ROTSTEP without the display.

Once again, thanks for all your work on LPub3D.  It's an amazing tool. 

Kevin

Kevin,

Many thanks for the visual. The problem is clear. The current fade [demarcation] index is being thrown off by the buffer exchange. This shouldn't be too challenging to fix. I'll take a look.

Cheers,

[Kevin]

Trevor,

Thanks for taking a look.  Here are a couple images to demonstrate what I'm experiencing. 

In scenario 1, you see what happens when I use a BUFEXCHG RETRIEVE and then immediately add parts before displaying the results with a STEP or ROTSTEP.  In the second frame, all the additional pieces are faded when attached to the retrieved assembly.  In the fourth frame, some are faded and some are not.



In scenario 2, you can see that I'm getting the correct results if I add a STEP/ROTSTEP after the BUFEXCHG RETRIEVE but before I add the additional parts.  However, I don't want to see the faded assembly before I add parts.



Perhaps this could be fixed by adding an LPUB directive that signals sets a demarcation between faded and not-to-be faded parts in a step--the equivalent of a STEP/ROTSTEP without the display.

Once again, thanks for all your work on LPub3D.  It's an amazing tool. 

Kevin

Kevin,

Many thanks for the visual. The problem is clear. The current fade [demarcation] index is being thrown off by the buffer exchange. This shouldn't be too challenging to fix. I'll take a look.

Cheers,

Trevor,

Thanks.  I'd be happy to beta test the fixes if you'd like. 

Kevin

[Trevor Sandy]

Trevor,

Thanks for taking a look.  Here are a couple images to demonstrate what I'm experiencing. 

In scenario 1, you see what happens when I use a BUFEXCHG RETRIEVE and then immediately add parts before displaying the results with a STEP or ROTSTEP.  In the second frame, all the additional pieces are faded when attached to the retrieved assembly.  In the fourth frame, some are faded and some are not.



In scenario 2, you can see that I'm getting the correct results if I add a STEP/ROTSTEP after the BUFEXCHG RETRIEVE but before I add the additional parts.  However, I don't want to see the faded assembly before I add parts.



Perhaps this could be fixed by adding an LPUB directive that signals sets a demarcation between faded and not-to-be faded parts in a step--the equivalent of a STEP/ROTSTEP without the display.

Once again, thanks for all your work on LPub3D.  It's an amazing tool. 

Kevin

Kevin,

Many thanks for the visual. The problem is clear. The current fade [demarcation] index is being thrown off by the buffer exchange. This shouldn't be too challenging to fix. I'll take a look.

Cheers,

Trevor,

Thanks.  I'd be happy to beta test the fixes if you'd like. 

Kevin

Kevin,

This is fixed. It took just 3 lines of code  For details, see (r764) in version 2.0.7 Readme or change log.

You can download for review the full instructions sequence images here.

I've also attached the updated model file. I made some corrections to page 31/32. 

Now, both pages 11-13 and 31-32 render as expected and without a STEP/ROTSTEP after the BUFEXCHG RETRIEVE meta command.

Cheers,

[Kevin]

Trevor,

Thanks for taking a look.  Here are a couple images to demonstrate what I'm experiencing. 

In scenario 1, you see what happens when I use a BUFEXCHG RETRIEVE and then immediately add parts before displaying the results with a STEP or ROTSTEP.  In the second frame, all the additional pieces are faded when attached to the retrieved assembly.  In the fourth frame, some are faded and some are not.



In scenario 2, you can see that I'm getting the correct results if I add a STEP/ROTSTEP after the BUFEXCHG RETRIEVE but before I add the additional parts.  However, I don't want to see the faded assembly before I add parts.



Perhaps this could be fixed by adding an LPUB directive that signals sets a demarcation between faded and not-to-be faded parts in a step--the equivalent of a STEP/ROTSTEP without the display.

Once again, thanks for all your work on LPub3D.  It's an amazing tool. 

Kevin

Kevin,

Many thanks for the visual. The problem is clear. The current fade [demarcation] index is being thrown off by the buffer exchange. This shouldn't be too challenging to fix. I'll take a look.

Cheers,

Trevor,

Thanks.  I'd be happy to beta test the fixes if you'd like. 

Kevin

Kevin,

This is fixed. It took just 3 lines of code  For details, see (r764) in version 2.0.7 Readme or change log.

You can download for review the full instructions sequence images here.

I've also attached the updated model file. I made some corrections to page 31/32. 

Now, both pages 11-13 and 31-32 render as expected and without a STEP/ROTSTEP after the BUFEXCHG RETRIEVE meta command.

Cheers,

Wow!  Thanks for the fast turnaround on this fix.  It's working perfectly--or at least the way I think it should work.  :-)

Your corrections to my code for pages 31-32 are basically what I had done for pages 11-12.  The key to successful results is to make sure that the last buffer I retrieve contains everything that I want faded, and that any subsequent parts show up unfaded.  I can get away with doing it differently if I'm not using fading, but this seems like a pretty good habit to get into, regardless.

I think I've also found a work-around for my request for a way to add custom lighting to POV renders.  I found a thread that discusses using a customized front end to L3P to avoid the requirement for the LGEO files.  I think I can use that same idea to create a customized front end to specify my own lighting. 

Once again, thanks.  And keep up the good work.

Kevin

[David]

Hi!
First thank you for your work, LPub3D is an amazing soft, even if it is sometimes tricky to get the results we expect!!
And speaking about that, despite my many tries, and the very useful example I found in this thread, I cannot get the result I expect...
On the image attached, I would like to have the submodel described in the callout (viper_left_wing_subassy01) not faded...
Here is the piece of LPub commands I actually use:

Code:

0 !LPUB MULTI_STEP BEGIN
0 !LPUB MULTI_STEP PLACEMENT CENTER PAGE INSIDE -0.25 0
0 ROTSTEP 0 180 0 REL
1 15 13.400700 -139.521100 -29.464200 0.000000 1.000000 0.000000 -0.801953 0.000000 0.597388 0.597388 0.000000 0.801953 40490.dat
0 STEP
0 !LPUB ASSEM PLACEMENT LOCAL LEFT PAGE INSIDE 0.2 0
0 !LPUB PLI CONSTRAIN LOCAL HEIGHT 1.08
0 BUFEXCHG A STORE
0 !LPUB CALLOUT BEGIN
1 16 -12.753480 -75.206180 -16.509370 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 viper_left_wing_subassy01
0 !LPUB CALLOUT POINTER LEFT 0.911 0.933 0.616 0
0 !LPUB CALLOUT PLACEMENT RIGHT PAGE INSIDE -0.05 0.1
0 !LPUB CALLOUT END
0 BUFEXCHG B STORE
0 BUFEXCHG A RETRIEVE
0 !LPUB PART BEGIN IGN
0 GHOST 1 16 -82.753480 -75.206180 -16.509370 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 viper_left_wing_subassy01
0 !LPUB PART END
0 STEP
0 !LPUB MULTI_STEP END

If anyone can help?? or point to an example which illustrated this?

Many Thanks!

David

[Kevin]

David,

If you could attach your entire file, I'll be happy to try to help you.  There seems to be something else going on--I don't think the liftarm in the previous step should be faded when attached to the wing assembly.

Kevin

[David]

David,

If you could attach your entire file, I'll be happy to try to help you.  There seems to be something else going on--I don't think the liftarm in the previous step should be faded when attached to the wing assembly.

Kevin

For the record! I totally forgot to update this thread...
The solution is quite strange, but the only problem is that the submodel did not have the ".ldr" extension! I used Stud.io to generate the .ldr export, and by default, it does not add any extension to the submodels inside the ldr file... so when you create submodels in Stud.io and you plan to use LPUB3D, keep in mind that you have to add the ".ldr" extension manually to your submodel's name.
Then everything works as expected...