L3P 1.4 beta 20080930 - transparent parts not transparent enough?

[Michael Horvath]

I rendered the attached file using POV-Ray 3.7 and L3P 1.4 beta. Does anyone else also think the transparent glass is not transparent enough? Has anyone noticed this and made alterations to L3P's materials?

[Steffen]

As far as I know, L3P does not know of (and, therefore, use) LDConfig.ldr containing "our" color definitions,
but instead uses its own hardcoded ones.
I remember when using the tool (a lot) in the past, I was always tinkering with the colors.
However, nowadays I switched to use LDView's POVRay export, which I like a lot,
and I found myself no longer feeling the need to tinker with the colors.
I think that when using L3P many people have done many different tries to modify the colors to their taste.
I would love to hear from these results maybe here in this thread?

[Michael Horvath]

I have to use POV-Ray though I think because I need to re-use the same camera and lighting data in every render, and I use parallel camera and lights which are not supported by LDView.

I hope development of L3P hasn't ceased!

[Travis Cobbs]

You can use LDView's "top include" setting in its POV export settings to specify an include file, and define your camera and lights in that file. That would allow you to use your parallel camera and custom lights. If you look at the camera and light definitions inside a POV file generated by LDView, you will see that they are inclosed in #ifndef statements. Define LDXSkipCamera, LDXSkipLight1, LDXSkipLight2, and LDXSkipLight3 in your top include to have LDView not use its own.

I'm not saying that LDView's color definitions will necessarily be better than L3P's, but if your camera and lights are the same in every frame, you should be able to simply copy them from your L3P-generated file into a file all by themselves, then use them as your top include in LDView, then add the defines above.

[Michael Horvath]

I didn't realize LDView was so configurable. I will give it a try later on tomorrow tonight.

[edit]

Where do I find "lg_defs.inc" and "lg_color.inc"? I looked in the main LDraw directory, as well as the LDView installation directory.

Disregard. I found them.

[edit]

It would be great if some of the other variables used the #ifndef statement such as the following:

#declare LDXQual = 2;
#declare LDXSW = 0.5;
#declare LDXStuds = 1;
#declare LDXRefls = 1;
#declare LDXShads = 1;
#declare LDXFloor = 0;

[edit]

Lastly, I forgot we had this same discussion at the beginning of this year. I fixed some issues I had then as well as now. However I am still getting the following error:

Code:

"D:\Datsville\trunk\datsville_rpgmaker\povsource\datsville_ldview_includes.pov" line 348044: Parse Error: Expected 'object', undeclared identifier 'LDX_48_slash_1_dash_12ri38_dot_dat_in_part' found instead

I don't know what to do about it.

This seems to be fixed in Beta 1.

[edit]

There's no way to turn off the "background" declaration after the fact. Could you make it optional? I need renders with transparent backgrounds.

[edit]

Where do I find the latest versions of LGEO? I think the original author may have abandoned them. Has development been taken over by another person?

[Philippe Hurbain]

C3POwen is maintaining LGEO (see http://www.eurobricks.com/forum/index.ph...try1929218, bottom of post), updated file is here https://dl.dropboxusercontent.com/u/5986...Update.zip

[Travis Cobbs]

It would be great if some of the other variables used the #ifndef statement such as the following:

#declare LDXQual = 2;
#declare LDXSW = 0.5;
#declare LDXStuds = 1;
#declare LDXRefls = 1;
#declare LDXShads = 1;
#declare LDXFloor = 0;

The top include #include is intentionally placed below the large list of declares at the top of the file. This allows people to make use of those declares. (For example, they could have a custom camera auto-position algorithm coded into their include.) If you want to, it's perfectly valid to redefine any of the values to whatever you want (although you probably have to first undefine them to avoid a warning and/or error). Additionally, all of the values you list above are configurable in LDView's POV Export settings dialog.

There's no way to turn off the "background" declaration after the fact. Could you make it optional? I need renders with transparent backgrounds.

I should be able to wrap that in a #ifndef and add another setting. I'll have to get back to you on that.

[Travis Cobbs]

There's no way to turn off the "background" declaration after the fact. Could you make it optional? I need renders with transparent backgrounds.

I should be able to wrap that in a #ifndef and add another setting. I'll have to get back to you on that.

I think I found a workaround for this. Put the following in an include file:

Code:

background { color rgbf <0,0,0,1> }

Set that include file as the "bottom include" in LDView's POV export options. It's not clean, since it's redefining the background with a fully transparent one, instead of skipping the background definition in the first place, but it seems to work.

[Stephen]

If you add +ua to the POV-Ray command line then the LDView background is ignored and you'll get a transparent png.

Note though that even when rendering with a transparent background, the "background" statement will still control the colour reflected by any transparent parts such as windows or windscreens.

[Steffen]

the error you're getting

Code:

"D:\Datsville\trunk\datsville_rpgmaker\povsource\datsville_ldview_includes.pov" line 348044: Parse Error: Expected 'object', undeclared identifier 'LDX_48_slash_1_dash_12ri38_dot_dat_in_part' found instead

also hits me from time to time and is fixed for long time in a beta now,
Travis, even with these small bugfixes, I would really love to finally see a new release of LDView coming out
(even without big new features) containing these fixes.

[Michael Horvath]

Awesome, thanks. I didn't know you could do that.

I already had this parameter set in the INI file to begin with. I'm not sure why it's rendering a background now as opposed to before. Maybe it's a floor plane? Though I had the floor turned off as well.

[edit]

I think in earlier versions of POV-Ray things worked this way. However, in POV-Ray 3.7 a declared background overrides the Output_Alpha parameter.

[Michael Horvath]

Thank you.

[Michael Horvath]

The problem was that I have dozens of files and I have to reset them manually each time.

On a second look however, I see that they can be overridden by the include file, so there really is no issue after all.

[Michael Horvath]

Can LDView convert to POV-Ray format using the DOS command line? That way I can create a batch file to convert files in bulk.

[Michael Horvath]

I've attached a test case of differently colored glass. To me they appear too opaque, except for clear trans, in both the L3P *and* LDView POV-Ray output. However, they look fine in MLCAD and LDView proper. But maybe I am seeing things.

What do you think?

[Travis Cobbs]

Unfortunately, no. I'd like to make it do that, but it's never made it high enough on my priority list to get done. Just getting a 4.2 release out the door has been delayed for years now. :-(

[Travis Cobbs]

I'm not sure about the L3P file (it's missing an include), but the LDView file uses LGEO colors. You may well be able to find a copy of lg_colors.inc somewhere with better (perhaps even great) color definitions.

If you go into LDView's POV export settings and disable the "Use XML mapping file" setting, it will disable LGEO usage inside LDView, which causes it to use LDView's built-in colors for all colors, instead of using LGEO ones where they are found. Having said that, LDView's default transparent color calcs are pretty bad. However, I played around a little and came up with something better. Look in the POV file for LDXSkipTransColorMacro, and you will see a block of code similar (but not identical) to the following one:

Code:

#ifndef (LDXSkipTransColorMacro)
#macro LDXTransColor(r, g, b)
#if (version >= 3.1) material { #end
    texture {
        pigment { #if (LDXQual > 1) rgbft <r,g,b,.5,.5> #else rgbf <0.6,0.6,0.6,0> #end }
#if (LDXQual > 1)
        finish { ambient LDXAmb diffuse LDXDif }
        finish { phong LDXPhong phong_size LDXPhongS reflection LDXTRefl }
        #if (version >= 3.1) #else finish { refraction 1 ior LDXIoR } #end
#end
    }
#if (version >= 3.1) #if (LDXQual > 1)
    interior { ior LDXIoR }
#end #end
#if (version >= 3.1) } #end
#end
#end

The one thing I changed was the pigment line, changing from rgbf to rgbft, and tweaking the values of the f and t parameters (they're both .5 here). To me, the above looks half-way decent, although perhaps not perfect.

If you want to use this generic color definition (based on RGB values from ldconfig.ldr) with LGEO geometry, you can edit your LGEO.xml in the LDView directory, and either comment out or completely delete the entire <Colors> section. You can then tweak the f and t parameters (along with all the other stuff if you really want to) to your heart's content. Once you have something you like, Stick the LDXTransColor macro definition in your top include, then define LDXSkipTransColorMacro so that the file generated by LDView will use yours instead of its own.

[Stephen]

I think in earlier versions of POV-Ray things worked this way. However, in POV-Ray 3.7 a declared background overrides the Output_Alpha parameter.

Could be. I'm still on 3.6.

But, for me I need the POV-Ray "background" statement to still occur even when doing transparent renders (which is the only type of render I do these days). The colour selected by LDView to be used in the background statement (which you can also override from the top-include) controls the colour reflected by reflective parts. It's often useful to use a hint of light blue to simulate sky reflection in windows and windscreens, especially if the intention is to later add a real sky background image to the transparent png render.

I would have thought there would be a way in 3.7 to still specify the background (for the above purpose) but still get a 32-bit png with alpha. But since I haven't used 3.7 I can't help you...