LDView povray export

[Michael Horvath]

Here are some things I suggest for LDView's povray export. They all make things easier when using an external file to set variables, which I do often. I.e. I will create a "wrapper" file that is used in common by several scenes.

1. Precede all variable declarations with #IFNDEF. For instance:

Change this

Code:

#declare LDXQual = 3;

To this

Code:

#ifndef (LDXQual) #declare LDXQual = 3; #end

2. Check the variable's value when disabling lights and camera. For instance:

Change this

Code:

// Camera
#ifndef (LDXSkipCamera)
camera {
    #declare LDXCamAspect = image_width/image_height;
    location LDXCameraLoc
    sky LDXCameraSky
    right LDXCamAspect * < -1,0,0 >
    look_at LDXCameraLookAt
    angle 77.011589
}
#end

To this

Code:

// Camera
#ifndef (LDXSkipCamera) #declare LDXSkipCamera = false; #end

#if (LDXSkipCamera = false)
camera {
    #declare LDXCamAspect = image_width/image_height;
    location LDXCameraLoc
    sky LDXCameraSky
    right LDXCamAspect * < -1,0,0 >
    look_at LDXCameraLookAt
    angle 77.011589
}
#end

3. Create a variable to enable/disable the background. For instance:

Code:

#if (LDXShowBackground = true) background { color rgb <LDXBgR,LDXBgG,LDXBgB> } #end

4. Lastly, if you could do the camera calculations inside the POV file instead of "hardcoding" the values, that would be great. For instance, start with latitude, longitude and radius to generate the camera location; then translate the camera based on the center of the bounding box. (I'm not 100% sure exactly what LDView does to output the camera.)


Thank you!!

[Travis Cobbs]

Here are some things I suggest for LDView's povray export. They all make things easier when using an external file to set variables, which I do often. I.e. I will create a "wrapper" file that is used in common by several scenes.

1. Precede all variable declarations with #IFNDEF. For instance:

Change this

Code:

#declare LDXQual = 3;

To this

Code:

#ifndef (LDXQual) #declare LDXQual = 3; #end

The above should be unnecessary. The intent is for you to redefine all of these values in whatever file you tell LDView to use as its "Top include". This filename (if set) gets #included immediately following all of the declares, so you can redefine (or undefine) any of them there.

2. Check the variable's value when disabling lights and camera. For instance:

Change this

Code:

// Camera
#ifndef (LDXSkipCamera)
camera {
    #declare LDXCamAspect = image_width/image_height;
    location LDXCameraLoc
    sky LDXCameraSky
    right LDXCamAspect * < -1,0,0 >
    look_at LDXCameraLookAt
    angle 77.011589
}
#end

To this

Code:

// Camera
#ifndef (LDXSkipCamera) #declare LDXSkipCamera = false; #end

#if (LDXSkipCamera = false)
camera {
    #declare LDXCamAspect = image_width/image_height;
    location LDXCameraLoc
    sky LDXCameraSky
    right LDXCamAspect * < -1,0,0 >
    look_at LDXCameraLookAt
    angle 77.011589
}
#end

Once again, the expectation is that you would use "#undef LDXSkipCamera" in your top include to force LDXSkipCamera to not be defined (if that is your goal).

3. Create a variable to enable/disable the background. For instance:

Code:

#if (LDXShowBackground = true) background { color rgb <LDXBgR,LDXBgG,LDXBgB> } #end

This makes sense (although I would probably use "#ifndef (LDXSkipBackground) ..." for consistency.

4. Lastly, if you could do the camera calculations inside the POV file instead of "hardcoding" the values, that would be great. For instance, start with latitude, longitude and radius to generate the camera location; then translate the camera based on the center of the bounding box. (I'm not 100% sure exactly what LDView does to output the camera.)

It's been a long time since I worked on the POV-Ray stuff, so I'm not sure about how difficult this would be. I'll at the very least look into it.

[Michael Horvath]

The above should be unnecessary. The intent is for you to redefine all of these values in whatever file you tell LDView to use as its "Top include". This filename (if set) gets #included immediately following all of the declares, so you can redefine (or undefine) any of them there.

Up until now I have been wrapping the model files (generated using L3P up until this point) inside an outer file with scene settings, camera, etc. This is a lot easier for me since I don't have to edit each model file when a wrapper gets edited, renamed or merged together with other wrappers. I have dozens of models, and a dozen or so wrappers, so this is not trivial. And each time I make a change to a model I have to push each file to GitHub/SourceForge.

Here's an example of one of my wrapper files:

Code:

#version 3.7;


// -------------------------------------------------------------
// LDCad settings with LGEO

#include "settings_common_before.inc"
#include "settings_showcase_normal.inc"
#include "lg_defs.inc"
#include "lg_color.inc"
#include "blurred_reflection.inc"
#include "materials_ldc_shadowno.inc"                // LQ
//#include "materials_ldc_shadowno_mjh.inc"            // MQ
//#include "materials_ldc_shadowno_clipka.inc"        // HQ
#include "materials_ldc_out.inc"
#include "materials_all_missing.inc"
#include "materials_all_convert.inc"


// -------------------------------------------------------------
// LDView models

//#include "ldv_nice_androbot_mech_new.pov"
//#include "ldv_nice_red_devil_racer_new.pov"
#include "ldv_nice_dune_rover_new.pov"                // takes too long to render

The models are at the bottom. And each model may be included in *several* wrappers, depending on if I want a different viewpoint or background, or a scene with multiple models. I don't think this would break your top includes either.

Once again, the expectation is that you would use "#undef LDXSkipCamera" in your top include to force LDXSkipCamera to not be defined (if that is your goal).

I think it would be better to set a variable to equal true or false versus deleting, commenting out, or undeffing a line each time you want to skip or unskip a camera or light source.

Changing this

#declare LDXSkipCamera = true;

to this

#undef LDXSkipCamera;

each time is more error prone and more typing.

[Travis Cobbs]

Up until now I have been wrapping the model files (generated using L3P up until this point) inside an outer file with scene settings, camera, etc. This is a lot easier for me since I don't have to edit each model file when a wrapper gets edited, renamed or merged together with other wrappers. I have dozens of models, and a dozen or so wrappers, so this is not trivial. And each time I make a change to a model I have to push each file to GitHub/SourceForge.

OK, I'll wrap all of the #declare statements in #ifndefs.

I think it would be better to set a variable to equal true or false versus deleting, commenting out, or undeffing a line each time you want to skip or unskip a camera or light source.

Changing this

#declare LDXSkipCamera = true;

to this

#undef LDXSkipCamera;

each time is more error prone and more typing.

I'm not going to change this, because I don't really agree, and your suggested change will change the behavior for everyone else. If you want to define your own camera, #declare LDXSkipCamera to anything, and the generated POV will omit defining a camera. If you want to use the defined camera, don't define LDXSkipCamera (or #undef it instead of setting it to false if you define it in multiple places). Similarly, I will add #ifndef (LDXSkipBackground) around the background definition, so you can define that (to any value) to have LDView's POV omit its background declaration.

[Travis Cobbs]

4. Lastly, if you could do the camera calculations inside the POV file instead of "hardcoding" the values, that would be great. For instance, start with latitude, longitude and radius to generate the camera location; then translate the camera based on the center of the bounding box. (I'm not 100% sure exactly what LDView does to output the camera.)

It's been a long time since I worked on the POV-Ray stuff, so I'm not sure about how difficult this would be. I'll at the very least look into it.

I've come to the conclusion that I'm not conversant enough in POV-Ray syntax to do this. If you can come up with a camera definition that takes the following inputs, I can incorporate your definition into the generated POV code when lat/long camera positioning is used:

• LDXCameraLookAt (The center of the model, and the point at which the camera is looking.)
  
• LDXCamAspect (The aspect ratio of the rendered scene; used in the "right" vector right now.)
  
• LDXCameraDistance (The distance from the camera to the center of the model.)
  
• LDXCameraLatitude
  
• LDXCameraLongitude
  
• LDXCameraAngle
  

If you need more input parameters, let me know; I can probably provide them, but I think the above is all that should be needed.

[Michael Horvath]

I'm not going to change this, because I don't really agree, and your suggested change will change the behavior for everyone else. If you want to define your own camera, #declare LDXSkipCamera to anything, and the generated POV will omit defining a camera. If you want to use the defined camera, don't define LDXSkipCamera (or #undef it instead of setting it to false if you define it in multiple places). Similarly, I will add #ifndef (LDXSkipBackground) around the background definition, so you can define that (to any value) to have LDView's POV omit its background declaration.

 I did a quick test rendering the following scene:

Code:

// -------------------------------------------------------------
// Test code

#undef LDXSkipCamera

// -------------------------------------------------------------
// LDView models

#include "ldv_nice_dune_rover_new.pov"

POV-Ray issues a warning, but thankfully does not halt the render with an error.

line 5: Parse Warning: Attempt to undef unknown identifier

[Orion Pobursky]

 I did a quick test rendering the following scene:

Code:

// -------------------------------------------------------------
// Test code

#undef LDXSkipCamera

// -------------------------------------------------------------
// LDView models

#include "ldv_nice_dune_rover_new.pov"

POV-Ray issues a warning, but thankfully does not halt the render with an error.

Just throw an #ifdef in there.

[Travis Cobbs]

Just throw an #ifdef in there.

Also, LDXSkipCamera will never be defined by LDView, so unless your own code defines it, there's no need for a #undeclare. The same will be true in the future for the new LDXSkipBackground.

[Michael Horvath]

Just throw an #ifdef in there.

I guess I could also do this:

Code:

#declare EnableCamera = true;
#if (EnableCamera = false)
    #declare LDXSkipCamera = true;
#elseif (EnableCamera = true)
  #ifdef (LDXSkipCamera)
    #undef LDXSkipCamera
  #end
#end

This is very convoluted compared to just switching a variable from true to false or the reverse, however. As if my include files didn't already have too much junk in them.

[Michael Horvath]

Also, LDXSkipCamera will never be defined by LDView, so unless your own code defines it, there's no need for a #undeclare. The same will be true in the future for the new LDXSkipBackground.

If you want to be consistent then you may change the LDXFloor true/false flag to LDXSkipFloor since you are just toggling an object on/off versus changing the informational value of data.

[Michael Horvath]

I've come to the conclusion that I'm not conversant enough in POV-Ray syntax to do this. If you can come up with a camera definition that takes the following inputs, I can incorporate your definition into the generated POV code when lat/long camera positioning is used:

• LDXCameraLookAt (The center of the model, and the point at which the camera is looking.)
  
• LDXCamAspect (The aspect ratio of the rendered scene; used in the "right" vector right now.)
  
• LDXCameraDistance (The distance from the camera to the center of the model.)
  
• LDXCameraLatitude
  
• LDXCameraLongitude
  
• LDXCameraAngle
  

If you need more input parameters, let me know; I can probably provide them, but I think the above is all that should be needed.

What direction is the camera looking in by default before latitude and longitude are applied?

Also, when looking along an coordinate axis toward the center of a scene, do latitude and longitude increment clockwise or anticlockwise?

[Michael Horvath]

This is kind of a random comment, but in order for subsurface scattering (a.k.a. subsurface lighting transport) to work in POV-Ray, every material needs to have an "subsurface" block in the material's finish as well as in the global settings.

Further, each material needs to have an "ior". And, each type of material needs to have a different ior, including the different types of plastics such as ABS and polycarbonate.

Christoph Lipka talks about it in this thread:

http://news.povray.org/povray.beta-test/...top=420381

He also talks about blurred reflections in this thread:

http://news.povray.org/povray.binaries.i...42&toff=50

But as of this time the easy-to-use blurred reflection syntax is only an UberPov thing and not in vanilla POV-Ray.

Here is a demo:



That's as much as I know about the topic. I cannot personally suggest appropriate values/settings for these materials properties.

[Travis Cobbs]

If you want to be consistent then you may change the LDXFloor true/false flag to LDXSkipFloor since you are just toggling an object on/off versus changing the informational value of data.

Actually the LDXSkip... checks are all for things that can't be set via the UI, so my using LDXSkipBackround would be consistent for that since I wasn't planning on adding it to the UI. Having said that, disabling the background via the UI is a reasonable thing to do, so I will add an LDXBackground variable, which will be able to be set from the options UI, and I will have its default value be 1. Note that LDXSkipCamera is only useful if you have manually defined the camera yourself somewhere else. So not having that accessible from the UI makes sense.

[Steffen]

Hej Travis,

I again also looked into the POVRay export by LDview and noticed that it always adds a hardcoded line

Code:

background { color rgb <LDXBgR,LDXBgG,LDXBgB> }

Can this be changed to

Code:

#ifdef(LDXBgR)
#ifdef(LDXBgG)
#ifdef(LDXBgB)
background { color rgb <LDXBgR,LDXBgG,LDXBgB> }
#end
#end
#end

please? That would allow me to suppress that background statement in the custom preamble include via #undef LDXBgR

[Travis Cobbs]

No, but as I mentioned above, I will be adding a new LDXBackground variable, which will be available in the options UI (as well as being something you can set to 0 in a top include).

[Michael Horvath]

Actually the LDXSkip... checks are all for things that can't be set via the UI, so my using LDXSkipBackround would be consistent for that since I wasn't planning on adding it to the UI. Having said that, disabling the background via the UI is a reasonable thing to do, so I will add an LDXBackground variable, which will be able to be set from the options UI, and I will have its default value be 1. Note that LDXSkipCamera is only useful if you have manually defined the camera yourself somewhere else. So not having that accessible from the UI makes sense.

This reflects the options you have in LDView, but makes no semantic sense within the context of POV-Ray.

[Michael Horvath]

I've come to the conclusion that I'm not conversant enough in POV-Ray syntax to do this. If you can come up with a camera definition that takes the following inputs, I can incorporate your definition into the generated POV code when lat/long camera positioning is used:

• LDXCameraLookAt (The center of the model, and the point at which the camera is looking.)
  
• LDXCamAspect (The aspect ratio of the rendered scene; used in the "right" vector right now.)
  
• LDXCameraDistance (The distance from the camera to the center of the model.)
  
• LDXCameraLatitude
  
• LDXCameraLongitude
  
• LDXCameraAngle
  

If you need more input parameters, let me know; I can probably provide them, but I think the above is all that should be needed.

It may be enough simply to:

1. Move LDXCamAspect out of the camera block and place it instead next to all the other camera variables so that it can still be accessed if the default camera has been disabled.
2. Create an LDXCameraAngle variable to store the camera angle.
3. Create an LDXCameraTransform variable for any random random translation, scalings or rotations a user might want to do. For instance:

Code:

#declare LDXCameraTransform = transform
{
    // put extra transformations here, or put nothing here by default
}

Then you state the camera like this:

Code:

camera
{
    location LDXCameraLoc
    sky LDXCameraSky
    right LDXCamAspect * < -1,0,0 >
    look_at LDXCameraLookAt
    angle LDXCameraAngle
    transform {LDXCameraTransform}
}

The `distance` parameter is meant to be used in conjunction with `location`, `right` and `up`. If you instead want to specify `location`, `look_at`, `right`, `angle` and `sky`, then don't bother with defining `distance` as they are at cross purposes. (In fact, the `angle` parameter will override anything you do with `distance`.)

[Travis Cobbs]

It may be enough simply to:

1. Move LDXCamAspect out of the camera block and place it instead next to all the other camera variables so that it can still be accessed if the default camera has been disabled.
2. Create an LDXCameraAngle variable to store the camera angle.
3. Create an LDXCameraTransform variable for any random random translation, scalings or rotations a user might want to do. For instance:

Your original request gave the specific example of having latitude, longitude, and radius as input variables, and a desire to have my POV camera code be relative to that information. My response was based solely on that. I don't have a problem making the other suggested changes, but my request for you to come up with POV code that used latitude, longitude, radius, and model center as inputs was based completely on what you originally wrote.

[Michael Horvath]

Your original request gave the specific example of having latitude, longitude, and radius as input variables, and a desire to have my POV camera code be relative to that information. My response was based solely on that. I don't have a problem making the other suggested changes, but my request for you to come up with POV code that used latitude, longitude, radius, and model center as inputs was based completely on what you originally wrote.

Yeah, I asked for clarification in my other post. But this may serve just as well. It's up to you. I'm still wiling to write the code.