[LDView] ldr to pov export error

[Bertrand Lequy]

Hi,

thanks to Travis' help my batch pov generation script works fine.

But, I encountered several issues when rendering some parts.

for exemple :

Code:

"d:\lego\python\data\renders\0\14639p01.pov" line 1117: Parse Error: Expected 'object', undeclared identifier 'LDX_1_dash_16ring9_dot_dat_in_part' found instead

Render failed

So I investigate a bit about 1-16ring9.dat.

First of all, and obviously, the primitive is in my "ldraw\p\" directory, andthe 14639p01dat part opens without errors in LDview.

Then, I thought that some config file like LGEO.xml or LGDefs.inc were involved, but they do not have anything to do with that (if I'm right).

So I took a look at the buggy files and the integration of primitives in pov files.

If I understand the error message correctly, LDX_1_dash_16ring9_dot_dat_in_part has not been defined before, not like the other primitives involved in that part.

So, at some point, some lines like those for 1-16ri60.dat :

Code:

#declare LDX_48_slash_1_dash_16ri60_dot_dat_in_part = disc // Ring 0.0625
{
    <0,0,0>,<0,1,0>,61,60
    clipped_by
    {
        plane
        {
            <0,0,-1>,0
        }
        plane
        {
            <-0.38268343236508972627,0,0.92387953251128673848>,0
        }
    }
}

#declare LDX_48_slash_1_dash_16ri60_dot_dat = disc // Ring 0.0625
{
    <0,0,0>,<0,1,0>,61,60
    clipped_by
    {
        plane
        {
            <0,0,-1>,0
        }
        plane
        {
            <-0.38268343236508972627,0,0.92387953251128673848>,0
        }
    }
}

should have been written in the pov file but aren't. And I suppose that I can't choose randoms coordinates to solve the problem.

So my question is : do the problem come from a config file I didn't think about, or is it a export bug ?

I've the problem with other primitives on other parts.

[Travis Cobbs]

Can you test with LDView 4.4 Beta 3 and let me know if the problem still occurs?

Note: I know I made fixes that are related, I just don't know if those fixes fix this specific issue.

[Bertrand Lequy]

Can you test with LDView 4.4 Beta 3 and let me know if the problem still occurs?

Note: I know I made fixes that are related, I just don't know if those fixes fix this specific issue.

I'm allready using it.

But, I tried ldview64(4.3) and no problem occured with the part I gave as an exemple.

[Travis Cobbs]

I'm allready using it.

But, I tried ldview64(4.3) and no problem occured with the part I gave as an exemple.

Thanks. I'll investigate.

[Bertrand Lequy]

Hello again,

this part makes LDView freeze/crash when exporting  : 41671p01.dat

[Travis Cobbs]

Hello again,

this part makes LDView freeze/crash when exporting  : 41671p01.dat

Thanks. For some reason, LDView's smoothing algorithm used for POV exports is not happy with some of the geometry in that part. I'm not sure why, but I discovered that my error handling that was supposed to handle that wasn't doing what it was supposed to, and it was triggering a divide by 0 error. I'll PM you a test build with a fix.

[Bertrand Lequy]

it was triggering a divide by 0 error

Oh, could have wait a long time.

So that's why I had to kill the process in task manager.

[Bertrand Lequy]

Hello again,

the parts 685p03.dat and 685p05.dat

don't render properly, the printed color doesn't show, the part is plain.

edit : same for 3622p06

[Magnus Forsberg]

All three parts have the pattern created using texmap images.

[Bertrand Lequy]

All three parts have the pattern created using texmap images.

Erf.... thanks.

[Travis Cobbs]

Erf.... thanks.

FYI, I put quite a bit of effort into trying to get TEXMAP support in POV exports, and what I had at the end (which didn't work) was so bad that I just abandoned the effort entirely instead of trying to get things working. It's possible I'll try again in the future, but don't hold your breath.

[Roland Melkert]

@Bertrand Lequy
LDCad has texture support in its pov-ray export. But the overall quality of the povray generated meshes is only a LDraw geometry (after smoothing) dump.
You might be able to transplant the textured parts by doing some creative pov script editing

FYI, I put quite a bit of effort into trying to get TEXMAP support in POV exports, and what I had at the end (which didn't work) was so bad that I just abandoned the effort entirely instead of trying to get things working. It's possible I'll try again in the future, but don't hold your breath.

In LDCad I solved it by creating material variants for colors used on textured parts.
So if a textured part is used in blue it will have it own special 'blue' material instead of the generic ldcolor #1 one.

[Bertrand Lequy]

FYI, I put quite a bit of effort into trying to get TEXMAP support in POV exports, and what I had at the end (which didn't work) was so bad that I just abandoned the effort entirely instead of trying to get things working. It's possible I'll try again in the future, but don't hold your breath.

Don't worry,there's no criticism toward you, I'm gratefull you coded LDView and keep it up to date (and for the time you spent to help me)

I've browse some websites and pov-ray's help and found a way to managed it.

here's what I did with 3622p06.dat, if it may help you (it's not a clean code) :
I created a texture{} with the png file as you do with lgcolors :

Code:

#ifndef (LDXColortex) // TEXMAP texture
#declare LDXColortex = #if (version >= 3.1) material { #end

    texture {

        pigment {
            image_map {png "D:\LEGO\LDRAW\Unofficial\Parts\textures\3622p06.png"
            map_type 0
            once}
         // following parameters could be set according to TEXMAP START PLANAR I guess    
         scale <-60,-24,0>
         rotate <0, 90, 0>
         translate <0, 24, -30>
                 
                }

    }
    
#if (version >= 3.1) } #end //I didn' modify this, I didn't need it
#declare LDXColortex_slope = #if (version >= 3.1) material { #end
    texture {
        lg_blue
        #if (LDXQual > 1) normal { bumps 0.3 scale 25*0.02 } #end
    }
#if (version >= 3.1) } #end
#end

then I doubled the projection surface and applied the texture on it  (before the floor definition):

Code:

box {
   
    <-30,0,10>,<30,23.9,10>// I set 23.9 instead of 24 because the texture seem to overlap the part about 1-2 pixels at the bottom during rendering
    rotate <0, 90, 0>// I must have set my box directly on the right plane
    #if (version >= 3.1) material #else texture #end { LDXColortex }
}

here's the result :



I made something alike with 685p05.dat :

Code:

#ifndef (LDXColortex) // TEXMAP
#declare LDXColortex = #if (version >= 3.1) material { #end

    texture {

        pigment {
            image_map {png "D:\LEGO\LDRAW\Parts\textures\685p05.png"
            map_type 0
            once}
             
         scale <-20,-30,0>
         rotate <0, 90, 0>
        translate <0, -20, -20>
 
    }


    }
    
#if (version >= 3.1) } #end
#declare LDXColortex_slope = #if (version >= 3.1) material { #end
    texture {
        lg_black
    }
#if (version >= 3.1) } #end
#end

and the second part (the texture is half the pattern, used 2 times):

Code:

#declare texmap = 
object {
        LDX_48_slash_2_dash_8sphe_dot_dat_sub_part
        matrix <0,-24,0,0,0,-24,24,0,0,0,-32,0>
        #if (version >= 3.1) material #else texture #end { LDXColortex }
        }
        
        
object {
texmap //original
}
object {
texmap
matrix <1,0,0,0,1,0,0,0,-1,0,0,0>//symetrical
}

here's the result (I'm less satisfied with this one)

LDCad has texture support in its pov-ray export. But the overall quality of the povray generated meshes is only a LDraw geometry (after smoothing) dump.

You might be able to transplant the textured parts by doing some creative pov script editing

I didn't know that, it may have saved me some times, thanks. I guess I'll have to update my LDCad install.

[Bertrand Lequy]

It seems, because the error is in both my LDView and LDview64 install, that something get wrong with parts 42445 and 42446, the mapping is mixed up and should be (if I'm not wrong) :

Code:

<Element>
            <LDrawFilename>42445.dat</LDrawFilename>
            <POVName>lg_42445</POVName>
            <POVName Alternate="Clear">lg_42445_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_42445.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>
        <Element>
            <LDrawFilename>42446.dat</LDrawFilename>
            <POVName>lg_42446</POVName>
            <POVName Alternate="Clear">lg_42446_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_42446.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

instead of

Code:

<Element>
            <LDrawFilename>42445.dat</LDrawFilename>
            <POVName>lg_42446</POVName>
            <POVName Alternate="Clear">lg_42446_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_42446.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

[Travis Cobbs]

It seems, because the error is in both my LDView and LDview64 install, that something get wrong with parts 42445 and 42446, the mapping is mixed up and should be (if I'm not wrong) :

Code:

<Element>
            <LDrawFilename>42445.dat</LDrawFilename>
            <POVName>lg_42445</POVName>
            <POVName Alternate="Clear">lg_42445_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_42445.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>
        <Element>
            <LDrawFilename>42446.dat</LDrawFilename>
            <POVName>lg_42446</POVName>
            <POVName Alternate="Clear">lg_42446_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_42446.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

instead of

Code:

<Element>
            <LDrawFilename>42445.dat</LDrawFilename>
            <POVName>lg_42446</POVName>
            <POVName Alternate="Clear">lg_42446_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_42446.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

Just to clarify, are you saying that lg_42446 is actually LDraw part 42445, and that there is no LGEO version of LDraw part 42446?

[Bertrand Lequy]

Just to clarify, are you saying that lg_42446 is actually LDraw part 42445, and that there is no LGEO version of LDraw part 42446?

No, there are lg_42445.inc and lg_42446.inc.

But in LGEO.xml, 42445.dat is exported as lg_42446.inc and 42446.dat is not exported using LGEO library. 

I modified my LGEO.xml file as stated before and everything went well.

[Travis Cobbs]

No, there are lg_42445.inc and lg_42446.inc.

But in LGEO.xml, 42445.dat is exported as lg_42446.inc and 42446.dat is not exported using LGEO library. 

I modified my LGEO.xml file as stated before and everything went well.

OK, thanks. I see that there is an error in the official LGEO lg_elements.lst file (which I used to create LGEO.xml). It maps 42445.dat to both lg_42445 and lg_42446. Since a single LDraw dat can only be mapped to one LGEO part, my LGEO.xml generator simply replaced the 42445 mapping with the 42446 one. I'll update LGEO.xml.

[Bertrand Lequy]

OK, thanks. I see that there is an error in the official LGEO lg_elements.lst file (which I used to create LGEO.xml). It maps 42445.dat to both lg_42445 and lg_42446. Since a single LDraw dat can only be mapped to one LGEO part, my LGEO.xml generator simply replaced the 42445 mapping with the 42446 one. I'll update LGEO.xml.

Yes, that's what i thought. An other thing, since some parts of the LDraw library are moved, they're not allways replaced by LGEO parts, depending of the dat file used. I encountered the problem with minifig parts for exemple.
You could add  these lines too for minifig arms and hands (they're only aliases for existing LGEO parts), I did it and it woerked fine :

Code:

<Element>
            <LDrawFilename>3818.dat</LDrawFilename>
            <POVName>lg_0982</POVName>
            <POVName Alternate="Clear">lg_0982_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_0982.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
       </Element>
<Element>
            <LDrawFilename>3819.dat</LDrawFilename>
            <POVName>lg_0981</POVName>
            <POVName Alternate="Clear">lg_0981_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_0981.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>
<Element>
            <LDrawFilename>3820.dat</LDrawFilename>
            <POVName>lg_0983</POVName>
            <POVName Alternate="Clear">lg_0983_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_0983.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

EDIT :

it's true for the hips too

Code:

        <Element>
            <LDrawFilename>3815.dat</LDrawFilename>
            <POVName>lg_0970</POVName>
            <POVName Alternate="Clear">lg_0970_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_0970.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

EDIT 2 : and for the legs too :

Code:

        <Element>
            <LDrawFilename>3816.dat</LDrawFilename>
            <POVName>lg_0971</POVName>
            <POVName Alternate="Clear">lg_0971_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_0971.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>
        <Element>
            <LDrawFilename>3817.dat</LDrawFilename>
            <POVName>lg_0972</POVName>
            <POVName Alternate="Clear">lg_0972_clear</POVName>
            <Dependency>LGDefs</Dependency>
            <POVFilename>lg_0972.inc</POVFilename>
            <MatrixRef>LGEOTransform</MatrixRef>
        </Element>

[Travis Cobbs]

Yes, that's what i thought. An other thing, since some parts of the LDraw library are moved, they're not allways replaced by LGEO parts, depending of the dat file used. I encountered the problem with minifig parts for exemple.
You could add  these lines too for minifig arms and hands (they're only aliases for existing LGEO parts), I did it and it woerked fine :

Thanks.

What you have should work, but I'm not sure it's a good solution, long term. I think it would be better for me to add support for a MovedTo section in LGEO.xml, and have entries in there that include the old LDraw name, new LDraw name, and optionally the transformation matrix. I could then have a program that anyone could run to could generate that section. For brevity, it wouldn't include any entries where both the old and new LDraw part names are already supported.

[Travis Cobbs]

Thanks.

What you have should work, but I'm not sure it's a good solution, long term. I think it would be better for me to add support for a MovedTo section in LGEO.xml, and have entries in there that include the old LDraw name, new LDraw name, and optionally the transformation matrix. I could then have a program that anyone could run to could generate that section. For brevity, it wouldn't include any entries where both the old and new LDraw part names are already supported.

Actually, if !HISTORY lines like the following are always present, LDView could be updated to automatically look for alternate names for a part to do this without any changes to LGEO.xml.

Code:

0 !HISTORY 2008-07-08 [PTadmin] Renamed from 193a (2006-04-13)

Chris Dee, are history lines like the one above auto-generated? And are they consistently present (with the exact "Renamed from x" text) in all parts updated within the last (say) 10 years?

[Chris Dee]

Actually, if !HISTORY lines like the following are always present, LDView could be updated to automatically look for alternate names for a part to do this without any changes to LGEO.xml.

Code:

0 !HISTORY 2008-07-08 [PTadmin] Renamed from 193a (2006-04-13)

Chris Dee, are history lines like the one above auto-generated? And are they consistently present (with the exact "Renamed from x" text) in all parts updated within the last (say) 10 years?

Sorry, but no these HISTORY lines are not auto-generated, because it is not always that straightforward. Frankly it would be a poor design to rely on free-text comments for such relationships. The only foolproof way is to use the target of the type 1 line in the ~Moved to file (including any transformation matrix). Admittedly this provides a forward reference, rather than the backward reference you appear to be seelking.

[Travis Cobbs]

Sorry, but no these HISTORY lines are not auto-generated, because it is not always that straightforward. Frankly it would be a poor design to rely on free-text comments for such relationships. The only foolproof way is to use the target of the type 1 line in the ~Moved to file (including any transformation matrix). Admittedly this provides a forward reference, rather than the backward reference you appear to be seelking.

Thanks. I actually wanted to have references in both directions, so that I could automatically pick an LGEO part if it used either the old name or the new name. And I would have used the matrix in the type 1 line of the original ~Moved To file. Because there is no reliable backwards reference, I'm going to need to generate an actual list, and I think the best way to do that would be by me writing a program to do that.