Am 19.11.2016 um 01:20 schrieb Roland Melkert:

>>> http://forums.ldraw.org/thread-21710-post-23886.html#pid23886
>>
>> Looks pretty convincing to me. What bothers you about it specifically?
> Mainly the fact the non transparent part of the image_map isn't transparent on
> transparent part usage. The difference being patterns painted on transparent
> plastic or them being part of the transparent plastic. I think both situations
> can appear in real LEGO though so I'm not sure which one is correct. But for now
> I want them to be the same as much as possible.

I /think/ you may need to try to explain that in a different manner
before I'll be able to grasp that...

Are you talking about the helmet's ornaments looking semi-transparent in
the OpenGL render, but opaque in the POV-Ray render?

To me the opaque ornaments look more convincing, as such features are
usually screen-printed on real-life LEGO parts with quite a good
coverage, rather than being a change in the transparent plastic's tint.

As a matter of fact producing truly multi-coloured plastic parts with a
reasonable degree of control over the distribution of colours is darn
complicated, and would probably be excessively expensive; so wherever
LEGO pieces are multi-coloured, they are either actually assemblies of
multiple parts, or uniformly-coloured parts with screen prints.

If you want a screen print to look imperfect, you can give it a bit of
transparency by blending the image_map (with alpha channel) with a
totally transparent pigment, for example using an average pattern. You
can even use some noisy pattern to model the imperfections and/or wear
typically seen with those screen prints.

Post a reply to this message

On 11/18/2016 4:30 PM, clipka wrote:
> I had hoped that some other user more familiar with LDraw than me would
> chime in; seeing that is not the case, I'll have a look what suggestions
> I can come up with.
>

Thank you!


Mike

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Are you talking about the helmet's ornaments looking semi-transparent in
> the OpenGL render, but opaque in the POV-Ray render?
Yes

> To me the opaque ornaments look more convincing, as such features are
> usually screen-printed on real-life LEGO parts with quite a good
> coverage, rather than being a change in the transparent plastic's tint.
Probably, I think I'm going to leave it for now as textured LDraw parts aren't
wide used anyway (so no real usage info).

> If you want a screen print to look imperfect, you can give it a bit of
> transparency by blending the image_map (with alpha channel) with a
> totally transparent pigment, for example using an average pattern. You
> can even use some noisy pattern to model the imperfections and/or wear
> typically seen with those screen prints.
That might take it a bit far for the initial exporter, but it certainly will be
something to think about for a revision later on :)

Post a reply to this message

Am 19.11.2016 um 01:20 schrieb Roland Melkert:

>> That said, maybe I can add a switch to layered textures in POV-Ray that
>> would cause the alpha channel of a layer to knock out not only that
>> layer's diffuse component, but also highlights and reflection. I guess
>> such a switch might come in handy for non-LDraw users as well.
> That would be very helpful especially when coming from an OpenGL background.

Done. If you like to test-drive the extension, have a look at this version:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-x.knockout.8881807

The syntax isn't finalized yet.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 19.11.2016 um 01:20 schrieb Roland Melkert:
>
> >> That said, maybe I can add a switch to layered textures in POV-Ray that
> >> would cause the alpha channel of a layer to knock out not only that
> >> layer's diffuse component, but also highlights and reflection. I guess
> >> such a switch might come in handy for non-LDraw users as well.
> > That would be very helpful especially when coming from an OpenGL background.
>
> Done. If you like to test-drive the extension, have a look at this version:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-x.knockout.8881807
>
> The syntax isn't finalized yet.
use_alpha on on the 2nd texture's finish seems to work great, no more double
ambient/reflection exposure for the transparent part of the image.

This prevents having to generate different textures for transparent or non
transparent png's. It also improves the overall surface as the non transparent
parts now use the finish block of the image_map pigment while all transparent
pixels use the one from the lower rgb pigment. This results in even surface
behavior.

Will this be added for the normal block too?


Thanks for implementing this test.


I used it like so:

#macro ldrawTexPlastic(ldCode, pngIdx)

 #local doPng=(pngIdx>=0);
 #local idx=getColorIndex(ldCode);
 #local r=ldColor[idx][1];
 #local g=ldColor[idx][2];
 #local b=ldColor[idx][3];
 #local a=ldColor[idx][4];

 #local basePigment=
   pigment {

    #if (a<1.0)
     srgbft <r,g,b, 0.85, 0.2>
    #else
     srgb <r,g,b>
    #end
   }
  ;

 #local baseNormal=
  normal {
   bumps 0.005
   scale 0.5
   turbulence 0
  }
 ;

 #macro fin(ua)
   diffuse 1
   brilliance 1
   conserve_energy

   specular albedo 0.6
   roughness 0.02

   reflection 0.15

   #if (ua)
     use_alpha on
   #end
 #end

 #local baseFinish=finish { fin(false) }

 #if (doPng)
   #local pngPigment=
    pigment {
     uv_mapping
     image_map {
      png getPngName(pngIdx)
      map_type 0
      interpolate 2
     }
    }
  ;

  #local pngFinish=finish { fin(true) }

  #local result=
    texture {
     pigment { basePigment }
     normal { baseNormal }
     finish { baseFinish }
    }
    texture {
     pigment { pngPigment }
     normal { baseNormal }
     finish { pngFinish }
    }
   ;
   result
 #else
   pigment { basePigment }
   normal { baseNormal }
   finish { baseFinish }
 #end
#end

Post a reply to this message

Am 21.11.2016 um 21:54 schrieb Roland Melkert:

> use_alpha on on the 2nd texture's finish seems to work great, no more double
> ambient/reflection exposure for the transparent part of the image.
> 
> This prevents having to generate different textures for transparent or non
> transparent png's. It also improves the overall surface as the non transparent
> parts now use the finish block of the image_map pigment while all transparent
> pixels use the one from the lower rgb pigment. This results in even surface
> behavior.
> 
> Will this be added for the normal block too?

With the diffuse, highlights and reflection all knocked out, how could
normals still be bothering you?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> With the diffuse, highlights and reflection all knocked out, how could
> normals still be bothering you?
I was thinking e.g. dents could still be applied twice on the transparent
portions?

Post a reply to this message

Am 21.11.2016 um 23:43 schrieb Roland Melkert:
> clipka <ano### [at] anonymousorg> wrote:
>> With the diffuse, highlights and reflection all knocked out, how could
>> normals still be bothering you?
> I was thinking e.g. dents could still be applied twice on the transparent
> portions?

No; surface normal perturbations only affect the corresponding layer;
and they only become visible by how they affect diffuse, highlights and
reflections of that layer.

Post a reply to this message

On 11/21/2016 03:54 PM, Roland Melkert wrote:
> srgbft <r,g,b, 0.85, 0.2>

I confess to not following this thread too closely, but the above line 
of code caught my eye because the F & T components add to more than 1.0.

I believe this results in the introduction of negative/complement 
<r,g,b> color which I'm guessing you'd not want.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/21/2016 03:54 PM, Roland Melkert wrote:
> > srgbft <r,g,b, 0.85, 0.2>
>
> I confess to not following this thread too closely, but the above line
> of code caught my eye because the F & T components add to more than 1.0.
>
> I believe this results in the introduction of negative/complement
> <r,g,b> color which I'm guessing you'd not want.
Thanks William

I missed that, the result of endless tweaking :)

Post a reply to this message