Colors not correct

[BertVanRaemdonck]

I'm looking at the materials in Cycles. One thing I noticed is that a lot of colors are too bright. This is most notable for black and dark grey: they don't appear dark at all, not in the viewport and not in the render. I think the reason for this lies in gamma correction. When I just go to the peeron color list, copy the rgb hex code and paste it in the color pop-up in the viewport, it gives me a correct color. However, when I taka the rgb hex code and programatically convert it to rgb coordinates, it gives me the same faint color. The only difference lies in the fact that in the second case the color wasn't gamma corrected. To resolve this issue, it should either be figured out how to gamma correct the colors, or all the colors should be implemented manually into a dictionary. The first option seems to be the best one, however, it's very hard to find information on this.

[le717]

Related to #9.

or all the colors should be implemented manually into a dictionary

Will comment on the rest of this issue , but I will say right now that this will never happen. I don't know if you are aware of this fact, but there are multiple Blender 2.3/2.4 LDraw scripts out there is that all are based on each other and/or share a common origin, and all but one store the colors in dictionaries. Previously, I have updated one of those dictionaries with the latest LDraw colors, and that is a major hassle. I will never be storing the LDraw colors internally in the script, as that requires us to keep track of the latest color changes and additions, and in the long run will require someone else to come along and manually update the dictionary with the latest colors, just as I did with the old Blender 2.3 script.

[BertVanRaemdonck]

I'm glad to say I solved the issue by dropping a gamma node with the materials. The downside is that if you want to gamma-correct the render later on, it won't be correct anymore because you would double correct everything. But on the other side, I don't know if a lot of people really do that, and it is very hard to set up a render if what you're looking at doesn't resemble the final result you want to get. I'll post my code later, but now that I'm looking into the materials, I'm starting to notice other issues:

• The metallic colors look horrible: not metallic at all. I searched long to find why this was, and discovered that a single misplaced bracket in the material assignment function getCyclesMaterial made every material a basic one.
• Replacing that bracket resulted in much better metallic materials, however, the pearlescent materials are still off. This just seems to lie in the way these materials were defined. So I'm a bit hesitant to change these, as I know rioforce did quite some work to figure out these materials. So what's the reason then the pearlescent looks off?

[le717]

I'm glad to say I solved the issue by dropping a gamma node with the materials. The downside is that if you want to gamma-correct the render later on, it won't be correct anymore because you would double correct everything.

That can probably be done, as (I guess) a large userbase are beginners. 3D artists would be able to tell a gamma node is applied when working on the colors.

The metallic colors look horrible: not metallic at all. I searched long to find why this was, and discovered that a single misplaced bracket in the material assignment function getCyclesMaterial made every material a basic one.

What bracket is that? Please put up a PR this change, as I had no idea that was happening!

This just seems to lie in the way these materials were defined. So I'm a bit hesitant to change these, as I know rioforce did quite some work to figure out these materials. So what's the reason then the pearlescent looks off?

rioforce did work on defining the colors, but they have never been implemented. The Cycles colors are what was defined by the coder who added them. The node setups and example renders from can be found here. Do they look any better?

[ghost]

I'm not sure if you realized this or not, but according to the offical LDraw Page about colors, it mentions this:

There is also an alternative file with different edgeline colours available: LDCfgalt.ldr. It is primarily intended for rendering and those who prefer their CAD models to look more realistic

Would it help to include this file in the script, and use that?

[ghost]

Never mind, still seems off in about the same way. The saturation is just low, from what I'm seeing.

[le717]

I am quite aware of the LDCfgalt.ldr file. Early on in the script's life I had it use that file by default but backed the change out soon thereafter. I actually have some WIP code that cleans up the color code and adds support for that file but I have never finished it and have too much to do right now to pull it back up.

FWIW, the LDraw colors are not the best anyway. Serious renders will always have manual color corrections. My goal for this aspect is to provide basic but usable colors without getting too complicated/on the realistic side. After it, it is only an importer script.

Did you pull the latest code and try importing with the Cycles engine? I did implement some of the revised colors last year (check the wiki for a list) and they helped out quite a lot.

[ghost]

No, I haven't, but I actually have python now, so I can build it properly. That's why I hadn't before. I will take a look.