Idea: Highlighting new parts in a step

[Jaco van der Molen]

Maybe I am asking too much at a time, but I really want to share this thought...

Reading the review of the Ghostbusters Firehouse on Eurobricks (http://www.eurobricks.com/forum/index.ph...pic=118783) I saw something interesting I've been wondering about before.

LEGO uses highlighting to show what parts a new in a step.
Like this


They've done this occasionally before (in the long past and I think with some monthly minibuilds) and I think it would be nice to be able to do this too?

Would something like this be possible to implement in LPub3D?
Or use some other software to pre-process an LDraw file that creates lines around the parts of a step?

I've done this in some instructions by hand (not every step) where it was really hard to see where parts went in a certain step. This is often the case with a monochrome model or when one uses many black for instance.

[Trevor Sandy]

For me, this is comparable to changing all but the model's current step to a 'fade' colour - which is already available in LPub3D.

It would be particularly difficult to implement this functionality because I'd have to find a way to signal the render (LDView, ldglite, Pov-ray) to produce an image where the additive parts were highlighted. I'm not even sure either of the renderers I use have the ability to accept a command/signal as such.

Because LPub3D uses static images (produced by the renderer), any highlight not visible would be useless, so the entire functionality would be questionable in achieving it's intent.

However, it would be possible to signal the 3D Viewer but showing highlighted additive parts to the editor does not strike me as the intent of your idea ?

Cheers,

[Jaco van der Molen]

For me, this is comparable to changing all but the model's current step to a 'fade' colour - which is already available in LPub3D.

True, great feature! But not always practical.

It would be particularly difficult to implement this functionality because I'd have to find a way to signal the render (LDView, ldglite, Pov-ray) to produce an image where the additive parts were highlighted. I'm not even sure either of the renderers I use have the ability to accept a command/signal as such.

Because LPub3D uses static images (produced by the renderer), any highlight not visible would be useless, so the entire functionality would be questionable in achieving it's intent.

However, it would be possible to signal the 3D Viewer but showing highlighted additive parts to the editor does not strike me as the intent of your idea ?

Cheers,

I imagined this would be difficult to implement.

However, I thought LPub made a temporary LDraw file for every step and render that accordingly as assembly image?
You could compare that to the previous step or create a file with only the parts from every step.
Then process each step file to draw outlines (line types) around visible edges (is that possible?).
And add those parts as as a kind of layer to the previous step and thus creating the new step with new parts with lines and draw that step as assembly image?
Isn't this the way color fade works too?

[Trevor Sandy]

...I thought LPub made a temporary LDraw file for every step and render that accordingly as assembly image?

Yes it does.

Isn't this the way color fade works too?

I only change the csi content colour code for previous step's parts.

...process each step file to draw outlines (line types) around visible edges (is that possible?).

The fade colour feature does distinguish between previous steps and current but preparation of the additive parts are much more simple than what I understand from reading your suggestion. For fade colour I just change the colour of the step's additive parts. The cis is then fed to the renderer and a faded image is produced.

It sounds like 'drawing outlines' will require significantly more processing to determine which edge lines will need to have it's colour manipulated.

Cheers,

[Gerald Lasser]

...process each step file to draw outlines (line types) around visible edges (is that possible?).

The fade colour feature does distinguish between previous steps and current but preparation of the additive parts are much more simple than what I understand from reading your suggestion. For fade colour I just change the colour of the step's additive parts. The cis is then fed to the renderer and a faded image is produced.

It sounds like 'drawing outlines' will require significantly more processing to determine which edge lines will need to have it's colour manipulated.

What about this way? I think there is a pretty easy solution to that that does not require a lot of finding edges etc. let the renderer do it :-)

Render the first Step:
- LDView: All normal
   

Render the second Step:
- LDView: All normal
   

Render the second Step ONLY the additional parts:
- LDView: EDGES ONLY, THICKNESS = MAX
- change the color BLACK to a Highlight, e.g. YELLOW or ORANGE
   

Now merge the original STEP 2 and the Outlines of STEP 2
et voila! :-)
   


That should be fairly easily to do, the current "fade" feature detects the parts of a step in a similar way. As the control of LDView via the command line is pretty extensive this should be doable.

[Grayson]

Hi I am new here and don't know much. How do you update the library?

[Trevor Sandy]

Did you produce your mockup using LDView command line?

[Travis Cobbs]

No, he merged the two images. For this to work, both need to be the same size (in pixels), and also both have the same camera settings. Then, drawing the second image over the top of the first yields the merged image. If you look at the second image in an alpha-aware image program, you'll see that everything except the lines is fully transparent (alpha value of 0).

[Gerald Lasser]

I did use the GUI of LDView to get the pictures and merged them in GIMP.

What I can find in the LDView manual are the following command line parameters for the "edge-highlight" render:

EdgeThickness (Integer, 1-5) -> 5
EdgesOnly (Boolean) -> YES
SaveAlpha (Boolean) -> YES

The rest, camera position, image size, anti-aliasing etc. can stay the same.

[Trevor Sandy]

Ok, so far so good but it looks like we'll need yet another third-party application to perform the merge. Is this correct ?

I like this approach and I could use the same scheme to improve the quality of the fade part functionality also. In fact, I see a whole range of rendering improvements with this sort of 'multi-image' manipulation.

Does anyone know if there is or I can package GIMP as a distributable - e.g. like I've done with ldglite ?

Cheers,

[Jaco van der Molen]

Cool. Too bad I am not a real programmer, but I understand what you guys are saying.
And that looks good!

[Jaco van der Molen]

Hi I am new here and don't know much. How do you update the library?

Hi Grayson,

Welcome.
I think you meant to ask a new question, not replying to this thread.
Do I understand correct that what you are asking is how to update the parts library for LDraw?

You can do that by downloading either the update or complete files from LDraw.org here:
http://www.ldraw.org/parts/latest-parts.html

Else I'd recommend to use the AIOI (All In One Installer) to run a fresh installation:
http://www.ldraw.org/article/104.html

[Gerald Lasser]

I think you do not need an external SW package. The routine should be fairly simple in my view.

How I would do it (not knowing how the Alpha Channel is represented in a PNG)
- Go through the file pixel by pixel
- if the pixel of the highlight is transparent -> use the original image pixel
- if the pixel is colored -> use this pixel (or do an ADD/Multiply or use opacity that may be makes the color below shine through a bit)
- Save the modified pixel.

For sure there must be a ready-made function somewhere out there. QT should have something on board.


Just found this code here including an example:

Code:

QImage createImageWithOverlay(const QImage& baseImage, const QImage& overlayImage)
{
    QImage imageWithOverlay = QImage(baseImage.size(), QImage::Format_ARGB32_Premultiplied);
    QPainter painter(&imageWithOverlay);

    painter.setCompositionMode(QPainter::CompositionMode_Source);
    painter.fillRect(imageWithOverlay.rect(), Qt::transparent);

    painter.setCompositionMode(QPainter::CompositionMode_SourceOver);
    painter.drawImage(0, 0, baseImage);

    painter.setCompositionMode(QPainter::CompositionMode_SourceOver);
    painter.drawImage(0, 0, overlayImage);

    painter.end();

    return imageWithOverlay;
}

Some php code looks amazingly simple...

Code:

$image1 = imagecreatefrompng('a.png'); //300 x 300
$image2 = imagecreatefrompng('b.png'); //150 x 150
imagecopymerge($image1, $image2, 0, 0, 75, 75, 150, 150, 50);

EDIT:

The original code uses "QPixMap" to e.g. find the pointer location for the call out (see line 2316 in metaitem.cpp) or searcch form "blue" in the code.

This digs quite deep into the actual image, which is not necessary to achieve the quick solution with the edge lines.

Here is something on the QT pages.

[Milan Vančura]

Unfortunately, this simple approach cannot work in generic case. For example, imagine some part of the last step partially hidden by some part from previous steps. This way you described we'll see ghost edges of invisible (part of) part.

This is still a 3D scene and so any attempt to merge two 2D images together (like in gimp) cannot work in generic case (that's math). The only way is to render the 3D scene with this additional information. It means we need to have a way how to tell LDView or other renderer about that. For example if there was an ldraw special command "0 !EDGE_COLOR yellow" affecting all following "1" lines.
EDIT: And even after that you get something different than LEGO does. Same as in your example: ALL edges of the last step are highlighted, including edges of studs etc. Original LEGO instructions are much nicer: only the edge of "the block of last step parts" is highlighted there.

So the problem is even more complex.

[Gerald Lasser]

You are right, if a brick is partially covered it will not give a nice result. But in general the view in the instructions shall be such that parts are not covered.

Of course i get something different that Lego does in the example above. That is a draft and a very simple approach. To avoid the interior lines, so you just want to have the outside, you need to find the edges, you can do this with a 2D algorithm, and delete all the color that lies within.

Now we are left with existing bricks covering the added bricks. We know the camera position and we know the position of the added bricks. We would need to find the bricks between camera and the added ones. now for a 2D approach to mask the highlighted line the renderer is given the "front" bricks. The resulting image is then added to the alpha layer of the highlight, i.e. where there was color before, there is now transparency.

So three layers might do the job.
a) Render of the CSI
b) Render of the Highlighted Edges
c) Render of the bricks Covering the Highlight

So the result would be a + (b - c)

The ideal result would be if you can tell this the renderer to do, i.e. show me only the visible lines of the parts in this step.

Mmmh: I might just have found another easy way to do it (needs some more proof but basically it worked), see below, LDView and LDConfig.ldr are my friends :-)
Starting image, completed CSI Image of the step (correct colors)
   

Now render the highlight:
It gets a bit more action here, but no problem
- Make the new parts, e.g. YELLOW
- Make the old old parts WHITE
- CHANGE LDconfig.ldr
-> set WHITE to #FFFFFF and the edge also to #FFFFFF
-> set YELLOW to #FFFFFF (this coudl be skipped as well) and the edge to bright yellow #FFFF00

Code:

0 !COLOUR Yellow                                                CODE  14   VALUE #FFFFFF   EDGE #FFFF00
0 !COLOUR White                                                 CODE  15   VALUE #FFFFFF   EDGE #FFFFFF

- Render the Step as the step before, just aks LDView to use LDConfig.ldr and EdgesOnly=YES and EdgeThickness=5
-> We get a image of this highlights and white edges of the rest
   
(I should have used red to highlight...)

Add a bit of postprocessing:
- The resulting image need to have the color WHITE set to complete TRANSPACENY
- And merge it with the initial CSI
- don't forget to use the proper LDConfig.ldr again!
   

Still we have the studs, but progress as the hidden lines are no more there... :-)

[Milan Vančura]

Your trick with white parts looks pretty. It's definitely a step in the right way because it uses real 3D engine. However, (again ) I cannot recommend using any 2D software for any enhancement like deleting unwanted edges. You need to find another trick how to force the 3D renderer to do it for you.
An idea (I did not test it): make parts have the same color as their edges; old parts white, new parts yellow. Then you should get a silhouette of last step parts - and that you can filter in 2D software to get an edge of the block. Shouldn't this work?

[Gerald Lasser]

This is a good conversation :-)

To achieve this result there is an even simpler, one step, solution.

- Basically you need to double the colors in LDConfig.
- Whatever is in a previous step has the normal colors
- New parts have colors that have set the Edge Color to yellow.
- Render in one step...
- Done.

Only disadvantage, the edge lines do not "glow" as they are all the same width...
This sample is done with a thickness of "2"

   

[Jaco van der Molen]

I am again amazed by you insights, Gerald! And Travis and Trevor and Milan ;-)

[Jaco van der Molen]

[attachment=1959]

Absolutely love this one!

[Trevor Sandy]

Excellent - this looks promising.

[Trevor Sandy]

It sounds like 'drawing outlines' will require significantly more processing to determine which edge lines will need to have it's colour manipulated.

Ok, so we are back to where I was with only difference is Milan and Gerald have demonstrated that it will not require significantly more processing to determine which edge lines to manipulate. Thanks guys. I think I can put this request on the TODO list.

Cheers,

[Milan Vančura]

I believe I've found an algorithm working in generic case, including partially hidden parts etc. And the result is close to what TLG prints, see below.

The algorithm:

1. add two special colors to ldconfig.ldr: HLwhite and HLyellow - with edge colors white, resp. yellow
2. make older parts HLwhite and parts of the last step HLyellow, make a picture of this "HL model"
3. in your 2D graphics editor (like gimp):
3a. separate (select) yellow colors - ldgview always uses many shades according to model lighting, you need to select all of them together
3b. fill this selected area with (one) yellow and the rest with white
3c. run "Edge detect" filter
3d. make white area 100% transparent
4. use this picture as an overlay of the original model picture
5. thank people in this thread for great conversation and for their enthusiasm

[Jaco van der Molen]

I must say I like both Milans and Geralds versions.
Milan showed exactly what LEGO does: the entire outline.
Gerald shows all new bricks outlined includings studs.
Which of these is doable? Both?

[Jaco van der Molen]

5. thank people in this thread for great conversation and for their enthusiasm

LOL
If all you programmers make it happen, let me be the first to thank you all... again.

[Milan Vančura]

I forgot to mention one limitation of my algorithm: the described modification of ldconfig.ldr does not solve the problem of parts with their own colors (printed parts, stickers etc.). To solve even this, one would have to call the renderer with another ldconfig.ldr modification: redefine all colors as HLwhite I described above (white color with white edges) and add HLyellow. Then, do not modify colors of older parts in the model, they become white-white automatically, including their prints etc. Only you need to change is to set a color of last step parts to HLyellow.

And, of course, it is fair to say that this is the generic algorithm only (as all the others in this thread as well) - one needs to solve more problems in the practical usage cases. For example: the last step containing a submodel used in previous steps, too.

[Philippe Hurbain]

There is still a few patterned parts that would fail with this algorithm: those that "bypass" ldconfig.ldr by using direct true colors. But there are few of them...