LDraw.org Discussion Forums
[LDView] ldr to pov export error - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: [LDView] ldr to pov export error (/thread-24500.html)

Pages: 1 2 3


RE: ldr to pov export error - Travis Cobbs - 2021-03-29

(2021-03-29, 15:45)Bertrand Lequy Wrote: 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.


RE: ldr to pov export error - Roland Melkert - 2021-03-29

@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 Smile


(2021-03-29, 21:25)Travis Cobbs Wrote: 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.


RE: ldr to pov export error - Bertrand Lequy - 2021-03-30

Travis Cobbs Wrote: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 :

[Image: 3622p06.png]

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)
[Image: 685p05.png]

Roland Melkert Wrote: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.


RE: ldr to pov export error - Bertrand Lequy - 2021-04-05

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>



RE: ldr to pov export error - Travis Cobbs - 2021-04-05

(2021-04-05, 19:51)Bertrand Lequy Wrote: 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?


RE: ldr to pov export error - Bertrand Lequy - 2021-04-06

(2021-04-05, 21:30)Travis Cobbs Wrote: 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.


RE: ldr to pov export error - Travis Cobbs - 2021-04-06

(2021-04-06, 5:25)Bertrand Lequy Wrote: 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.


RE: ldr to pov export error - Bertrand Lequy - 2021-04-06

(2021-04-06, 6:46)Travis Cobbs Wrote: 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>



RE: ldr to pov export error - Travis Cobbs - 2021-04-06

(2021-04-06, 8:08)Bertrand Lequy Wrote: 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.


RE: ldr to pov export error - Travis Cobbs - 2021-04-06

(2021-04-06, 20:23)Travis Cobbs Wrote: 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?