LDView POV Export again

[Tore Eriksson]

How come 3024.dat is exported as LDX_3024_dot_dat,
while 3008.dat becomes LDX_3008_dot_dat_sub_part?

This makes it impossible to create generic Datshine Attribute files compatible with LDView POV export.

And yes, I use unmodified, official versions:
3024.dat - !LDRAW_ORG Part UPDATE 2002-03
3028.dat - !LDRAW_ORG Part UPDATE 2004-03

/Tore

[Tim Gould]

When I convert 3008 I get LDX_3008_dot_dat and LDX_3008_dot_dat_sub_part

Did you actually check that both weren't there?

im

[Tore Eriksson]

I think POV-Ray would have found it, even if I failed...

I found out it has nothing to do with 3008. My first guess was that 3008 was sub-parted and 3024 not, but that was wrong.
It appears it has to do with when or if LDX_3008_dot_dat is declared.

Linked is a zip archive with three different outcomes, one success and two fails.
http://dl.dropbox.com/u/15954981/ldraw/newtest.zip (14kb)

test1 - fail - LDX_3024_dot_dat does not exist
test2 - success - LDX_3024_dot_dat defined before 3024L34
test3 - fail - LDX_3024_dot_dat defined after 3024L34

/Tore

[Tim Gould]

Hi Tore,

I suspect that LDview won't know that it needs to generate 3024 before generating your POV part. My suggestion is to embed the entire 3024 part in the ifpov surrounded by the #ifndef (_3024_dat_dat).

Or even better embed a simplified POV version as a difference of two cuboids with a stud on top.

Tim

[Tore Eriksson]

Looks like L3P "knows" - or just happens to do it.

Thanks again, but it looks like I found another workaround that at least works:

#ifndef (_3024_dot_dat)
#ifdef (LDX_3024_dot_dat_sub_part) #declare _3024_dot_dat = LDX_3024_dot_dat_sub_part #end
#ifdef (LDX_3024_dot_dat) #declare _3024_dot_dat = LDX_3024_dot_dat #end
#end

But I can't say I like it.

[Tim Gould]

Hi Tore,

The best solution in LDView is to make your own custom 3024L34.inc file in POVray and use part substitution.

The below should work as 3024L34.inc and (possibly) as an IFPOV

Code:

#local _3024_raw_part_col_34 = object { union {
   object { difference { box { <-10,0,-10> <10,8,10> } box { <-6,4,-6> <6,9,6> } } }
   object { cylinder { <0,-4,0> <0,0,0> 6 } }
   #if (version >= 3.1) material #else texture #end { LDXColor34 }
} }

#declare LDX_3024L34_dot_dat = light_source {
     <0, 0, 0>
     color rgb 0.15*<0.0234,0.391,0.195>
     fade_distance 60.0
     fade_power 1.6
     looks_like {_3024_raw_part_col_34 texture {
         pigment { rgbf <0.0234,0.391,0.195,0.90> }
         finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
             reflection 0.9
             refraction 1 ior 1.25
             }
         }
}    }

Tim

[Travis Cobbs]

Sorry for the delay in my reply, but I was unaware that the forum didn't give new notifications on the main page for forums that I had never read. After the first few days using the forum, I never bothered to look at any sub-forums that didn't have the new text next to them in the main list.

The root cause of the problem is that LDView appends _sub_part to the generated POV name of a part that is used from inside another part. However, LDView has a map from the LDraw filename to the POV name, and once an entry in the map exists, it gets used for all subsequent uses of that same part. So if you have a part that itself includes 3008.dat inside it, then the POV name for 3008.dat will be 3008_dot_dat_in_part if that part is in your file prior to a direct reference to 3008.dat. If 3008.dat comes first in the file, then you'll get 3008_dot_dat.

Having said all this, none of the parts in my library reference 3008.dat, so it seems a bit strange that you would see this for 3008.dat.