LDCad POVray export

[Michael Horvath]

A couple of observations.

1. slope bricks are not bumpy/grainy like they should be

2. at the POV-Ray newsgroups we came up with some code to add blurred reflections to models:

Code:

// this methoid is slower
#macro BlurredReflectionMicroNormals(InPigment, InFinish, InNormal, BlurAmount, BlurSamples)
//    texture
//    {
        average
        texture_map
        {
            #declare iCount = 0;
            #declare S = seed(0);
            #while (iCount < BlurSamples)
                [
                    1 // The pigment of the object:
                    pigment { InPigment }
                    // The surface finish:
                    finish { InFinish }
                    // This is the actual trick:
                    normal
                    {
                        average
                        normal_map
                        {
                            [1 bumps BlurAmount translate <rand(S),rand(S),rand(S)>*100 scale 0.001]
                            [1 InNormal]
                        }
                    }
                ]
                #declare iCount = iCount + 1;
            #end
        }
//    }
#end



// this method is faster, but requires a focal blur and/or extra antialiasing to smooth out the pixelation
#macro BlurredReflectionSingleNormals(InPigment, InFinish, InNormal, BlurAmount)
//    texture
//    {
        pigment { InPigment }
        finish { InFinish }
        normal { InNormal }
        normal {bumps BlurAmount scale 0.001}
//    }
#end



#if (Use_BlurRef = true)
    #ifndef (Use_BlurAmt) #declare Use_BlurAmt = 0.05; #end                // amount of surface reflection blurring
    #macro ldrawBuildTex(basePigment, baseNormal, baseFinish, pngIdx)
        #if (pngIdx<0)
            BlurredReflectionSingleNormals(basePigment, baseFinish, baseNormal, Use_BlurAmt)
        #else
            texture
            {
                pigment
                {
                    uv_mapping
                    image_map
                    {
                        png getPngName(pngIdx)
                        getPngMapType(pngIdx)
                        interpolate 2
                    }
                    getPngWarp(pngIdx)
                }
            }
            texture
            {
                BlurredReflectionSingleNormals(basePigment, baseFinish, baseNormal, Use_BlurAmt)
            }
        #end
    #end
#else
    #macro ldrawBuildTex(basePigment, baseNormal, baseFinish, pngIdx)
        #if (pngIdx<0)
            pigment { basePigment }
            normal { baseNormal }
            finish { baseFinish }
        #else
            #local texPigment= pigment
            {
                uv_mapping
                image_map
                {
                    png getPngName(pngIdx)
                    getPngMapType(pngIdx)
                    interpolate 2
                }
                getPngWarp(pngIdx)
            }
            #local result = texture
            {
                pigment { basePigment }
                normal { baseNormal }
                finish { baseFinish }
            }
            texture
            {
                pigment { texPigment }
            }
            result
        #end
    #end
#end

Unfortunately, there's no way to differentiate between ABS (solid) and Polycarbonate (clear) plastics. Could you add another column to the `ldColor` array for the `BlurAmount` value, in addition to `ior`? It would be great.

See also:

https://www.eurobricks.com/forum/index.p...e-realism/
http://news.povray.org/povray.binaries.i...ay.org%3E/


Thanks!

[Roland Melkert]

A couple of observations.

1. slope bricks are not bumpy/grainy like they should be

2. at the POV-Ray newsgroups we came up with some code to add blurred reflections to models:

Unfortunately, there's no way to differentiate between ABS (solid) and Polycarbonate (clear) plastics. Could you add another column to the `ldColor` array for the `BlurAmount` value, in addition to `ior`? It would be great.

1:
Those would require .dat changes and an extension to the texture map spec to allow for bump maps or something like that.

2:
You could check on alpha being <1.0  ( ldColor[getColorIndex(ldCode)][4]<1.0 ) for transparent ones.

If you need an extra parameter you could declare an array for mapping the odd ones, e.g.

Code:

#declare ldColorBlurCount=3;        
#declare ldColorBlur=array[ldColorBlurCount][2] {
{2, 0.25},
{7, 0.4},
{256, 0.7}
}      

#macro getColorBlur(ldCode)
#local result=-1
#local i=0;
#while (result=-1 & i<ldColorBlurCount)
 #if (ldColorBlur[i][0]=ldCode)
   #local result=i
 #else
   #local i=i+1;
 #end
#end

#if (result>=0)
  ldColorBlur[i][1];
else //def
  1.0
#end
#end

FYI: did you notice you can apply your modifications to material definitions in the %appdata%/LDCad/povray/default/colors.pov  file to avoid to have to post process each export. Or copy the default map so you can choose which set of scripts to use during export.

[Michael Horvath]

1:
Those would require .dat changes and an extension to the texture map spec to allow for bump maps or something like that.

For some reason I recalled L3P supporting parts with bumps, but this apparently is only true for LGEO parts. My mistake.

2:
You could check on alpha being <1.0  ( ldColor[getColorIndex(ldCode)][4]<1.0 ) for transparent ones.

If you need an extra parameter you could declare an array for mapping the odd ones, e.g.

Code:

#declare ldColorBlurCount=3;        
#declare ldColorBlur=array[ldColorBlurCount][2] {
{2, 0.25},
{7, 0.4},
{256, 0.7}
}      

#macro getColorBlur(ldCode)
#local result=-1
#local i=0;
#while (result=-1 & i<ldColorBlurCount)
 #if (ldColorBlur[i][0]=ldCode)
   #local result=i
 #else
   #local i=i+1;
 #end
#end

#if (result>=0)
  ldColorBlur[i][1];
else //def
  1.0
#end
#end

Yes, I can make my own array. But I was hoping for official support within LDCad.

FYI: did you notice you can apply your modifications to material definitions in the %appdata%/LDCad/povray/default/colors.pov  file to avoid to have to post process each export. Or copy the default map so you can choose which set of scripts to use during export.

I already delete all colors from each POV file and simply link to an external INC file with colors in it. I do this for L3P and LDView, as well, so now I can swap between all three whenever I want to in any model.

[Roland Melkert]

Yes, I can make my own array. But I was hoping for official support within LDCad.

I wouldn't know where to get the values from unless they are added to !COLOUR meta's or something.

[Michael Horvath]

Yes, I can make my own array. But I was hoping for official support within LDCad.

I wouldn't know where to get the values from unless they are added to !COLOUR meta's or something.

"LDConfig.ldr" does not specify anything other than color, so you must have come up with your own values for `ior`, `reflection`, `diffuse`, `specular`, etc. etc. `BlurAmount` is just one added value. Maybe instead of storing `ior` in the array, you should instead store the material type? E.g. ABS = 1, polycarbonate = 2, rubber = 3, chrome = 4, pearl = 6, metal = 7, etc. etc.

Regardless, you use the `ldrawTexPlastic` macro for both regular plastic bricks and transparent plastic bricks. Since they are two different types of plastics (ABS versus polycarbonate) they should probably use different textures/materials. The POV-Ray newsgroup may be able to offer tips on what values you should use for materials.

[Orion Pobursky]

I wouldn't know where to get the values from unless they are added to !COLOUR meta's or something.

"LDConfig.ldr" does not specify anything other than color, so you must have come up with your own values for `ior`, `reflection`, `diffuse`, `specular`, etc. etc. `BlurAmount` is just one added value. Maybe instead of storing `ior` in the array, you should instead store the material type? E.g. ABS = 1, polycarbonate = 2, rubber = 3, chrome = 4, pearl = 6, metal = 7, etc. etc.

Regardless, you use the `ldrawTexPlastic` macro for both regular plastic bricks and transparent plastic bricks. Since they are two different types of plastics (ABS versus polycarbonate) they should probably use different textures/materials. The POV-Ray newsgroup may be able to offer tips on what values you should use for materials.

Even if you differentiate between plastics, the refraction still won’t be quite right since the converter makes meshes and not solid geometry.

[Michael Horvath]

"LDConfig.ldr" does not specify anything other than color, so you must have come up with your own values for `ior`, `reflection`, `diffuse`, `specular`, etc. etc. `BlurAmount` is just one added value. Maybe instead of storing `ior` in the array, you should instead store the material type? E.g. ABS = 1, polycarbonate = 2, rubber = 3, chrome = 4, pearl = 6, metal = 7, etc. etc.

Regardless, you use the `ldrawTexPlastic` macro for both regular plastic bricks and transparent plastic bricks. Since they are two different types of plastics (ABS versus polycarbonate) they should probably use different textures/materials. The POV-Ray newsgroup may be able to offer tips on what values you should use for materials.

Even if you differentiate between plastics, the refraction still won’t be quite right since the converter makes meshes and not solid geometry.

I'm talking about blurred reflections, not blurred refractions.

Also, why do you store `ior` info if your geometry is not solid?

[Orion Pobursky]

Even if you differentiate between plastics, the refraction still won’t be quite right since the converter makes meshes and not solid geometry.

I'm talking about blurred reflections, not blurred refractions.

Light transmittal through the material affects the reflection. Also, reflection should be more of a function of material smoothness and not plastic type.

[Michael Horvath]

I'm talking about blurred reflections, not blurred refractions.

Light transmittal through the material affects the reflection. Also, reflection should be more of a function of material smoothness and not plastic type.

Sorry, I got you and Roland mixed up earlier. I think LDCad output meshes *are* solid, which is why `ior` (index of refraction) is specified for transparent parts. (Otherwise there would generally not be a point in specifying `ior`.) Also, Roland *already* does differentiate between types of plastic by specifying different `ior` values for transparent and non-transparent parts. He just doesn't do this for finishes as well.

[ed. correction: there is no `ior` specified for non-transparent parts.]

Anyway, blurred reflections don't look realistic on transparent parts. Something has to be done about this.

[Orion Pobursky]

Sorry, I got you and Roland mixed up earlier. I think LDCad output meshes *are* solid, which is why `ior` (index of refraction) is specified for transparent parts.

No they aren’t. Nothing that is a mesh is. This is why I started the LDraw POV project. Admittedly, I have no idea if it makes a huge difference and, if there is a noticeable difference, if it is worth the trouble for non-high res renders.

[Michael Horvath]

Sorry, I got you and Roland mixed up earlier. I think LDCad output meshes *are* solid, which is why `ior` (index of refraction) is specified for transparent parts.

No they aren’t. Nothing that is a mesh is. This is why I started the LDraw POV project. Admittedly, I have no idea if it makes a huge difference and, if there is a noticeable difference, if it is worth the trouble for non-high res renders.

Well, the blurred reflections *are* noticeable in non-high res renders, and they require a blur value as well as ior.

[Michael Horvath]

Is seam width the total distance between two bricks, or just half the distance?

[Roland Melkert]

Is seam width the total distance between two bricks, or just half the distance?

Total space in between bricks.

A brick gets scaled by (size-seamWidth)/size. So it has half the seamWidth per side left over.

[Michael Horvath]

Sorry, I got you and Roland mixed up earlier. I think LDCad output meshes *are* solid, which is why `ior` (index of refraction) is specified for transparent parts.

No they aren’t. Nothing that is a mesh is. This is why I started the LDraw POV project. Admittedly, I have no idea if it makes a huge difference and, if there is a noticeable difference, if it is worth the trouble for non-high res renders.

It seems solid meshes are possible in POV-Ray if you define an "inside_vector". But I have seen gaps between LDraw sub-parts, for instance where a low-res cylinder meets a high-res hole, or something similar. So maybe these are not "well-behaved".

http://wiki.povray.org/content/Reference:Mesh

Code:

Solid Mesh
The triangle mesh objects mesh (and mesh2) can be used in CSG objects such as difference and intersect. Adding the inside_vector they do have a defined inside. This will only work for well-behaved meshes, which are completely closed volumes. If meshes have any holes in them, this might work, but the results are not guaranteed.

To determine if a point is inside a triangle mesh, POV-Ray shoots a ray from the point in some arbitrary direction. If this vector intersects an odd number of triangles, the point is inside the mesh. If it intersects an even number of triangles, the point is outside of the mesh. You can specify the direction of this vector. For example, to use +z as the direction, you would add the following line to the triangle mesh description (following all other mesh data, but before the object modifiers).

inside_vector <0, 0, 1>
This change does not have any effect on unions of triangles, these will still be always hollow.

[Philippe Hurbain]

It seems solid meshes are possible in POV-Ray if you define an "inside_vector". But I have seen gaps between LDraw sub-parts, for instance where a low-res cylinder meets a high-res hole, or something similar. So maybe these are not "well-behaved"

There is definitely no clearly defined inside in most LDraw parts...

[Roland Melkert]

It seems solid meshes are possible in POV-Ray if you define an "inside_vector". But I have seen gaps between LDraw sub-parts, for instance where a low-res cylinder meets a high-res hole, or something similar. So maybe these are not "well-behaved"

There is definitely no clearly defined inside in most LDraw parts...

Having normals in mesh2 should do the trickp too, I already define an "interior" in LDCad's pov export. This controls transparency without the use of alpha.