[Feature] Enable "true" part fade and part highlight

[trevorsandy]

Subject of the issue

Enable true part fade by manipulating the fade part colour's ALPHA value.

Your environment

• Version of LPub3D - next release
• Operating system - All

Expected behaviour

Be able to produce fade steps that look like this:

[trevorsandy]

Don, Travis, I couldn't find an easy way to move our email exchange to this ticket.

Anyhow, the LDGLite commit Started work on transparent fade effect for LPub3D. Uses -fa for now. looks good.

I like the command line format you're using.

• Fade Command Line Format: -fa<fade percent>,<first colour code>,<last colour code>
• Silhouette Command Line Format: -sa=<edge line width>,<first colour code>,<last colour code>

I imagine the command must also be used in combination with the 0 !COLOUR meta to point to the designated fade/highlight colour defined in the command ?

It seems like the command format could also be easily defined as a meta command. For example
0 !FADE <fade percent>,<start colour code>,<end colour code> 0 !SILHOUETTE <edge line width>,<start colour code>,<end colour code> The only difference being reading it from the LDraw file versus the command line. Which brings me to the next point.

Regarding your remarks:

Is it global scope, even if it appears in a subfile of an mpd? Does it only affect parts that appear after it? Can it be updated later in the file by another !0 FADE on the same color_number?

The scope should be the same as that for the 0 !COLOUR meta if this will allow static coloured/patterned parts to be treated with less effort to modify the renderer code. The LDraw.org colour definition spec states "It's recommended that colour definitions be limited in scope. A color definition will affect colors from the point it first appears, continuing through the end of the file. Commands preceding a colour definition will not be affected by the definition. Color definitions will expire at the end of the file in which they appear, effectively falling out of scope. Color definitions will be passed to subfiles.". This scope definition is ok for LPub3D because I already update parts and subfiles with the appropriate colour code. The current fade logic is doing this.

It seems to me that the main use for this is fading large groups of previous bricks prior to adding bricks for a new step. If the large group of bricks is many colored, what's the advantage of fading individual colors over say !0 FADE 50% to start fading and !0 FADE 100% to return to normal? Am I mistaken about the purpose of this?

Indeed, using only 0 !FADE <fade percent> is more efficient that defining individual fade colours. For me, this could be the default meta definition so if no fade colour codes are defined, all colours encountered after the meta in the current LDraw file should be faded with 0 !FADE 100 effectively serving to 'turn off' fading while 0 !SILHOUETTE 0 will behave the same to turn off highlighting.

So whether using the command line flags -fa, -sa or meta commands 0 !FADE, 0 !SILHOUETTE, the generated LPub3D LDraw content to request fade 50 percent for the previous steps and highlight the current step would look like this:

Generated model file - using specified colour codes:

0 // ROTSTEP  0 0 0
0
0 // LPub3D fade step colours
0 !COLOUR LPub3D_Fade_Light_Bluish_Grey CODE 10071 VALUE #A0A5A9 EDGE #333333 ALPHA 128
0
0 //LPub3D highlight step colour
0 !COLOUR LPub3D_Highlight_Black CODE 1010 VALUE #A0A5A9 EDGE #FFFF00 ALPHA 255  
0
0 !FADE 50 10071
1 10071 -7.07107 -2.76289 6.50895 0.707107 0 0.707107 0.276289 0.920505 -0.276289 -0.650895 0.390731 0.650895 58120-fade.dat
0 !SILHOUETTE 2.5 1010
1 1010 7.07107 2.76289 -6.50895 -0.707107 0 0.707107 0.276289 0.920505 0.276289 -0.650895 0.390731 -0.650895 2780.dat

Generated part/subfile - using specified colour codes:

0 // LPub3D fade step colours
0 !COLOUR LPub3D_Fade_Black CODE 1000 VALUE #05131D EDGE #595959 ALPHA 128
0 !COLOUR LPub3D_Fade_Orange CODE 10025 VALUE #FE8A18 EDGE #333333 ALPHA 128
0 !COLOUR LPub3D_Fade_Dark_Bluish_Grey CODE 10072 VALUE #6C6E68 EDGE #333333 ALPHA 128
0
0 electric power functions medium motor
0 name: 58120.dat
0 author: philippe hurbain [philo]
0 !ldraw_org shortcut update 2012-01
0 !license redistributable under ccal version 2.0 : see careadme.txt

0 bfc certify cw

0 !history 2012-03-30 [ptadmin] official update 2012-01

0 !FADE 50 10072,10025,1000
1 10072 0 0 0 1 0 0 0 1 0 0 0 1 59143.dat
1 10025 0 0 0 1 0 0 0 1 0 0 0 1 47157.dat
1 16 0 0 120 1 0 0 0 1 0 0 0 1 59142.dat
1 1000 0 -23 118 0 0 1 -0.7071 2.1213 0 -0.7071 -2.1213 0 s\58124s03.dat

Alternatively we could also have:

Generated model file - without colour codes:

0 // ROTSTEP  0 0 0
0
0 !FADE 50
1 71 -7.07107 -2.76289 6.50895 0.707107 0 0.707107 0.276289 0.920505 -0.276289 -0.650895 0.390731 0.650895 58120-fade.dat
0 !FADE 100
0
0 !SILHOUETTE 2.5
1 0 7.07107 2.76289 -6.50895 -0.707107 0 0.707107 0.276289 0.920505 0.276289 -0.650895 0.390731 -0.650895 2780.dat

Generated part/subfile - without colour codes:

0 electric power functions medium motor
0 name: 58120.dat
0 author: philippe hurbain [philo]
0 !ldraw_org shortcut update 2012-01
0 !license redistributable under ccal version 2.0 : see careadme.txt

0 bfc certify cw

0 !history 2012-03-30 [ptadmin] official update 2012-01
0
0 !FADE 50
1 72 0 0 0 1 0 0 0 1 0 0 0 1 59143.dat
1 25 0 0 0 1 0 0 0 1 0 0 0 1 47157.dat
1 16 0 0 120 1 0 0 0 1 0 0 0 1 59142.dat
1 0 0 -23 118 0 0 1 -0.7071 2.1213 0 -0.7071 -2.1213 0 s\58124s03.dat

Cheers,

[deeice]

Hmm, I didn't actually know that 0 !COLOUR settings are supposed to expire at the end of the file where they appear. That precludes the use of it for personal preference config files, other than LDConfig.ldr, which is hardly personal. It seems arbitrarily limiting, and I don't particularly like it. Since it's pretty simple to reset FADE and SILHOUETTE, I'd suggest an explicit reset as the way to close the scope, not the end of the file.

This strikes me as double diping on the transparency.

0 !COLOUR LPub3D_Fade_Light_Bluish_Grey CODE 10071 VALUE #A0A5A9 EDGE #333333 ALPHA 128 0 !FADE 50 10071

You have ALPHA 128 transparency and FADE 50 applied to the same color. In my mind that sort of thing should result in ldglite using the 25% stipple pattern. Is that what's intended?

[deeice]

So I guess I prefer the 2nd example, except for the 50 percent fade in the subfile. It's unterminated, and also unnecessary as the fade from the main file would apply to the subfile. In fact you should be able to use the original subfile since you don't the redundant FADE meta command in the subfile.

[trevorsandy]

That precludes the use of it for personal preference config files, other than LDConfig.ldr, which is hardly personal.

Actually, the reference spec shown is only targeting 0 !COLOUR codes used in a model file or part. The LDConfig.ldr or any file containing 0 !LDRAW_ORG Configuration UPDATE YYYY-MM-DD with valid 0 !COLOUR entries are not affected by the scoping rules. See the Colour Definition page on LDraw.org for more details.

This strikes me as double diping on the transparency.

0 !COLOUR LPub3D_Fade_Light_Bluish_Grey CODE 10071 VALUE #A0A5A9 EDGE #333333 ALPHA 128 0 !FADE 50 10071

If I am only using a render that supports the 0 !FADE meta command, 'double diping' would be true; however, basically I have to ensure compatibility across 3 renderers - LDGLite, LDView and my 3DViewer (LeoCAD) while taking into account the existing code and functionality. I've placed the example as I have with the understanding that some part of the parameters provided are not supported they'll simply be ignored - versus causing any soft of abend. Once I bring the rest of the modules in line with the core specs, my generated content will not include the additional parameters.

So I guess I prefer the 2nd example, except for the 50 percent fade in the subfile. It's unterminated, and also unnecessary as the fade from the main file would apply to the subfile.

0 !FADE 50 is used with the assumption this meta would respect the same scope as 0 !COLOUR. If that assumption is invalid and 0 !FADE will implicate all files and subfiles that comes after its declaration, then, indeed, the 50 declaration is not necessary and a terminating declaration is required. The current 'fake' colour fade in LPub3D must implicate all subfiles/parts as the logic is based on manipulating the colour code. I carried this pattern over to the new 'true' fade thinking. However, I'll be happy to know I can remove the chunk of code that treats subfiles/ parts from the true fade logic.

Here's what I'm doing now with the current capabilities. The UI shot shows an LDView produced document image. The 3D Viewer is LeoCAD. LDGLite is not compatible with the number scheme I'm using so my highlighted pin simply appears grey.

Here's what the generated files look like

Cheers,

[deeice]

Ah, I forgot about the leocad panel. So this answers my earlier question. The redefining of colors is there as a fallback method that does something close to what you want.

The problem I tried to point out is this. What happens if you're mixing the new !0 FADE command with the fallback color redefinitions, but you have parts with windows. The windows already have transparency. I was thinking this would combine with the fade to make them more transparent so they still look like windows when surrounded by other faded parts. But if you have color redefines with ALPHA 128 then everything looks like a window. Maybe you could add an extra tag after the ALPHA 128 to let me know the original color so I can use the original color with the FADE command. You've supplied a lot of hints in the new color name, and the new color number, but there's still some guessing involved for me as it stands now.

Meanwhile I also didn't know about 0 !LDRAW_ORG Configuration UPDATE YYYY-MM-DD changing the scope rules. Honestly most of the code in ldglite was written years before the current ldraw spec was devised and I haven't been keeping up. So it isn't fully compliant with the COLOUR scope rules, and probably lots of other bits.

Because there's no code for scoping, it would be a bunch of extra work to keep track of local scope for FADE and SILHOUETTE commands.

[deeice]

Sorry if that makes no sense. I blame the early hour and lack of coffee. Most only applies if you plan to mix the fallback method and the meta commands.

[trevorsandy]

What happens if you're mixing the new !0 FADE command with the fallback color redefinitions, but you have parts with windows.

At present I calculate ALPHA using (( * ) + (100 - 1)) / 100. This adjusts the input alpha value by the fade percent so 50% fade of a fully opaque part would yield an alpha value of 128. If the part is already transparent with let's say an input alpha value of 128, then the resulting alpha value would be 65.

I was thinking this would combine with the fade to make them more transparent so they still look like windows when surrounded by other faded parts.

This is also my thinking and I believe my alpha calculation meets this expectation.

But if you have color redefines with ALPHA 128 then everything looks like a window. You've supplied a lot of hints in the new color name, and the new color number, but there's still some guessing involved for me as it stands now.

I'm not sure I'm following your pont here. Indeed, with transparency everything looks like a window to the degree that we can see what is behind. However, unlike a windows where you normally see rear lines (a windows is materially transparent), faded opaque parts will not show rear lines (they are not materially transparent) so the appearance will be unlike a normally transparent object - just like the example digger image at the start of this ticket. So the greater degree of transparency for 'windows' plus the fade characteristics of normally opaque parts, I believe, should visibly preserve the difference between the two types of faded material.

Maybe you could add an extra tag after the ALPHA 128 to let me know the original color so I can use the original color with the FADE command.

I agree with this. Travis' original suggestion for a fade meta 0 !FADE 10071 72 did include both the faded colour code and the original. I felt that was a good definition. However, I use a colour code 'prefix' for the precise reason of determining the original colour code. In the end, it would not hurt to add the original colour code as an additional attribute as you suggest but I believe it would be better to intelligently include the original colour code in the fade colour code.

Because there's no code for scoping, it would be a bunch of extra work to keep track of local scope for FADE and SILHOUETTE commands.

No problem for me here.

I think if you go with meta commands specified as you have described - including an additional attribute for the original colour code if that makes your life easier - this would be quite enough for LPub3D. I imagine the tricky part would be ensuring LDraw files with redefined or newly defined colour lines are ignored.

Cheers,

[deeice]

Maybe this will help me understand. In the picture where you show ldglite or ldview on the left and leocad on the right, are they displaying the exact same files, or do you make completely separate files for the different rendering paths?

[deeice]

I added some support to ldglite for !0 COLOUR definitions in the range 512 to 0x1ffffff. Only tested once though, so it might not actually work yet.

https://github.com/deeice/ldglite/commit/e98742df20c7c905bb015d220bc144ad4b5453f4

[trevorsandy]

Excellent. Many thanks! I'll take a look.

In the picture where you show ldglite or ldview on the left and leocad on the right, are they displaying the exact same files, or do you make completely separate files for the different rendering paths?

No, the files are not the exact same however, colour codes used are.

I show a folder view of all the generated files in text editor snapshot below.

From top to bottom, the folder contents are:

• assem: rendered CSI document images - right of the last row
• parts: rendered PLI document images - not shown
• tmp: generated CSI and PLI model and submodel LDraw content files - first row
• viewer: generated combined (model and submodel) CSI LDraw content files - second row
• custom: generated LDraw part files - third row

The content used to generate the CSI image (row one) is positionally rotated while the viewer's content is not (row 2). The only difference between the 2 sets of files. Also, the viewer's combines any used submodel content into a single file (not shown as the CSI does not contain any subfiles). Both files reference the generated part file (row 3). This file is loaded into the LDraw unofficial archive used by LPub3D and the 3DViewer. The foldered instance shown is used by LDGLite and LDView via additional search directories. Note the 'highlighted' part file in row 3 is not displayed because the current step is the pin.

These generated contents:

Produce this highlighted current step output:

Cheers,

[deeice]

If you're sharing the custom colored subfile in row 3 between renderers and there are ALPHA settings for fallback fade effects in there, I see the potential for different levels of transparency between the renderers if the FADE commands are also used.

Anyhow, maybe a FADE command that turns on the rear edge removal effect, but with no transparency of it's own would be useful for this. Something like FADE -1.

[trevorsandy]

Using 0 !FADE -1 to only remove rear edges is an excellent idea.

[trevorsandy]

Your last commit says it is now possible to define up to 512 extra color codes anywhere in 512 to 0x1ffffff.

Can codes after 512 be submitted in decimal format or only hex ?

If decimal format is supported up to 0x1ffffff, that's a very large number.

[deeice]

It should work with decimal or hex because I didn't change the parsing code, just added an extra (slow) global scope table to search in for numbers from that range that happened to get redefined with a !0 COLOUR command. If you somehow manage to use up all 512 of them you'll get the old default gray again for the 513th color.

[deeice]

I should add that the new color table and the !0 COLOUR support are not particularly well implemented in ldglite and definitely do not follow the official scope rules. It should serve well enough for testing to show if a better implementation is needed.

[deeice]

I roughed in support for a 0 !FADE meta command in ldglite. https://github.com/deeice/ldglite/commit/b8725a23def45031b08e52ba481f79f16258c25b

So far it only takes a fade percent argument, but it should support the value -1 for FADE rear edge removal effect only.

[trevorsandy]

I took a look. It's shaping up nicely.

I did a merge also and the tinyfiledialogs stuff totally broke the build. Is it supported on Windows ?

Not a problem though, I just cherry-picked the fade updates and the build completed without issue.

I'm setting up some more plumbing in LPub3D as well. For LDView, I'll have to do alpha blending so I have to tweak the existing code to ignore sending any custom !COLOUR entries to LDView.

Travis decided to go the route of generating a z map file which I'll use to create a grayscale image for my image matting.

[deeice]

Hmm, tinyfiledialogs is supposed to work on everything. I'll have to dig up a windows PC from the junk pile and make sure. What compiler are you using on Windows? And which version of Windows. Does the auto-build stuff keep a log somewhere?

I was sorta hoping to point to your releases as the "official" ldglite executables since you're building on so many platforms.

[trevorsandy]

I didn't spend a lot of time on it as I was doing a quick compile test. The issues were almost all undefined references - with some coming from the tinyfiledialog class itself. I imagine the issues are fixable.

Anyway I'm using gnu/mingw/Qt on Windows 10. I blew away the log.

If I have some time tomorrow, I'll set up again the full merge and do a build so I can send you the output as you seem to not have a Windows environment at the ready.

[StyletX]

Hi! I submitted this idea) If you make the transparency too difficult, you can still make only the selection of the contour of details in the current step. This is also very good! I know how to create instructions for children to make homemade models from Lego Wedo 2.0 + additional details. And I would very much like to be able to allocate the details of the current step on the assembly. P.S. Sorry for my bad English)))

[trevorsandy]

First phase completed.

Part fade:

Part Highlight:

[StyletX]

Hi! Very good news! when is the release expected?

вт, 7 авг. 2018 г. в 22:32, Trevor SANDY notifications@github.com:

Closed #47 https://github.com/trevorsandy/lpub3d/issues/47.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trevorsandy/lpub3d/issues/47#event-1776004170, or mute the thread https://github.com/notifications/unsubscribe-auth/ARkSomurv_qbElSfjV53EQU5jK-Vhcxeks5uOd06gaJpZM4TJ6rV .

[trevorsandy]

Hi, It should be ready within the next week or so.

I still have to finish up the deployment updates, documentation and fix a few outstanding dev issues.

Cheers,