LDraw.org Discussion Forums
LDView povray export - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw File Processing and Conversion (https://forums.ldraw.org/forum-22.html)
+--- Thread: LDView povray export (/thread-23502.html)

Pages: 1 2


RE: LDView povray export - Michael Horvath - 2019-06-22

(2019-06-21, 3:46)Travis Cobbs Wrote: 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?


RE: LDView povray export - Michael Horvath - 2019-06-22

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/thread/%3C5a76af4b%241%40news.povray.org%3E/?mtop=420381

He also talks about blurred reflections in this thread:

http://news.povray.org/povray.binaries.images/thread/%3C54f750ca@news.povray.org%3E/?ttop=402742&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:

[Image: bricks_2015-03-04-1654.jpg]

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


RE: LDView povray export - Travis Cobbs - 2019-06-22

(2019-06-22, 2:48)Michael Horvath Wrote: 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.


RE: LDView povray export - Steffen - 2019-06-23

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


RE: LDView povray export - Travis Cobbs - 2019-06-23

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).


RE: LDView povray export - Michael Horvath - 2019-06-25

(2019-06-22, 19:48)Travis Cobbs Wrote: 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.


RE: LDView povray export - Michael Horvath - 2019-06-25

(2019-06-21, 3:46)Travis Cobbs Wrote: 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`.)


RE: LDView povray export - Travis Cobbs - 2019-06-26

(2019-06-25, 23:35)Michael Horvath Wrote: 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.


RE: LDView povray export - Michael Horvath - 2019-06-26

(2019-06-26, 1:42)Travis Cobbs Wrote: 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.