POV-Ray export questions


POV-Ray export questions
#1
Hi all,

I've been working on a POV-Ray export for LDCad 1.6

I'm not seeking to replace LDView's export I mainly want to do animation exports.

I would be very interested what the more experienced POV-Ray users have to say about the generated file I've got so far.

Attached is a zip with some test output, It renders like so:
   

I think it's not bad but it could be better, probably by tweaking the global settings / light (currently it exports the OpenGL light position) / sky sphere stuff.

One thing I don't really understand is the small black square at the bottom left, I have no idea where that's coming from.

Any help / pointers / thoughts would be highly appreciated.


Attached Files
.zip   povTest.zip (Size: 317.48 KB / Downloads: 7)
Reply
RE: POV-Ray export questions
#2
The square looks like the shadow of something.

Does it appear if you remove all the parts ?
Reply
RE: POV-Ray export questions
#3
(2016-08-13, 21:08)Damien Roux Wrote: The square looks like the shadow of something.

Does it appear if you remove all the parts ?

Yes, but it gets bigger the more you re-add it's very strange.
Reply
RE: POV-Ray export questions
#4
Could it be the shadow of the baseplate if it's very high in the air for some reason?
Just thinking out loud, I don't use POV-Ray very often...
Reply
RE: POV-Ray export questions
#5
(2016-08-14, 18:18)Merlijn Wissink Wrote: Could it be the shadow of the baseplate if it's very high in the air for some reason?
Just thinking out loud, I don't use POV-Ray very often...

I think Merlijn is right. Instead of having a "floor", it looks like you render the model inside a great big hollow sphere. So that's probably the shadow of the model itself on the inside wall of the sphere. LDView uses a plane placed at the model's maximum Y location (in the original LDraw coordinate system, where positive Y is "down", by most people's description).

I think there is a POV material setting that can declare a surface as not receiving shadows. If so, you could turn this setting on for your sphere.
Reply
RE: POV-Ray export questions
#6
(2016-08-15, 6:04)Travis Cobbs Wrote: I think Merlijn is right. Instead of having a "floor", it looks like you render the model inside a great big hollow sphere. So that's probably the shadow of the model itself on the inside wall of the sphere. LDView uses a plane placed at the model's maximum Y location (in the original LDraw coordinate system, where positive Y is "down", by most people's description).

I think there is a POV material setting that can declare a surface as not receiving shadows. If so, you could turn this setting on for your sphere.

Thanks Merlijn/Travis, you are right.

I was using a sphere in the hopes to improve global lighting but that isn't working as I hoped anyway.
Reply
RE: POV-Ray export questions
#7
Made some improvements

It now exports animations and I discovered the proper use of 'emission' Smile

   
   

Radiosity does seem to cause some noise though


Attached is the scene (use the ini to render all frames)

I'm still looking for some expert help on setting up generic global lighting (some stuff is still very dark at certain angles)


Attached Files
.zip   povTest2.zip (Size: 159.88 KB / Downloads: 2)
Reply
RE: POV-Ray export questions
#8
Maybe this guide is of use to you?
Reply
RE: POV-Ray export questions
#9
Hi all,

I've almost finished the POVRay export feature for LDCad 1.6 but I'm having problems with the default material definitions.

Below is a zipped export of the 5571 model which renders nice using normal lighting, but acts very weird when using radiosity. It's caused by the chrome material but I have no clue on the why.

Anyone has some pointers or alternative chrome material definitions  (or any of the other material kinds rubber/metal/mattemetal/plainplastic/pearl)

normal render:
   

radiosity:
   


pov files
http://www.melkert.net/action/download/pov5571.zip

Any help / pointers are welcome
Reply
RE: POV-Ray export questions
#10
(2016-10-08, 23:01)Roland Melkert Wrote: Hi all,

I've almost finished the POVRay export feature for LDCad 1.6 but I'm having problems with the default material definitions.

Below is a zipped export of the 5571 model which renders nice using normal lighting, but acts very weird when using radiosity. It's caused by the chrome material but I have no clue on the why.

Anyone has some pointers or alternative chrome material definitions  (or any of the other material kinds rubber/metal/mattemetal/plainplastic/pearl)

normal render:


radiosity:



pov files
http://www.melkert.net/action/download/pov5571.zip

Any help / pointers are welcome

Is "max_trace_level" set too low maybe? Radiosity is very finicky. You may have better luck posting to the POV-Ray newsgroup.
Reply
RE: POV-Ray export questions
#13
(2016-10-08, 23:01)Roland Melkert Wrote: Hi all,

I've almost finished the POVRay export feature for LDCad 1.6 but I'm having problems with the default material definitions.

Below is a zipped export of the 5571 model which renders nice using normal lighting, but acts very weird when using radiosity. It's caused by the chrome material but I have no clue on the why.

Anyone has some pointers or alternative chrome material definitions  (or any of the other material kinds rubber/metal/mattemetal/plainplastic/pearl)

normal render:


radiosity:



pov files
http://www.melkert.net/action/download/pov5571.zip

Any help / pointers are welcome

There is something seriously wrong with your radiosity definitions, though I'm not quite sure yet what exactly.

What you should do is use the built-in radiosity defintions (rad_def.inc) and work with them, this got rid of all the problems for me:

   

The zipped .pov file was too large for attachment, so I included a .txt file with the relevant bits.

The max_trace_level was set to 20, that's pretty high and can slow rendering down. I routinely use 8 and never ran into any problems.


Attached Files
.txt   test.txt (Size: 5.48 KB / Downloads: 9)
----------
my flickr
Reply
RE: POV-Ray export questions
#14
(2016-10-10, 19:32)Niklas Buchmann Wrote: There is something seriously wrong with your radiosity definitions, though I'm not quite sure yet what exactly.

What you should do is use the built-in radiosity defintions (rad_def.inc) and work from there, this got rid of all the problems for me:

Thanks this looks much better indeed.

I noticed the 'srgb' for color 0 change, should I use that for all colors ?
Reply
RE: POV-Ray export questions
#15
(2016-10-10, 20:32)Roland Melkert Wrote:
(2016-10-10, 19:32)Niklas Buchmann Wrote: There is something seriously wrong with your radiosity definitions, though I'm not quite sure yet what exactly.

What you should do is use the built-in radiosity defintions (rad_def.inc) and work from there, this got rid of all the problems for me:

Thanks this looks much better indeed.

I noticed the 'srgb' for color 0 change, should I use that for all colors ?

Yes, you should.

With POV-Ray 3.7, the 'right' way of rendering is using an assumed_gamma value of 1.0 and specifying all colors using srgb (or srgbft). This will avoid all kinds of problems surrounding the gamma correction of the rendered image.

   

This is your scene rendered with the correct assumed_gamma value of 1.0 and updated srgb definitions for red and black. All other colors appear washed out because they are defined in rgb format and POV-Ray does not adjust for gamma.
----------
my flickr
Reply
RE: POV-Ray export questions
#17
(2016-10-10, 20:32)Roland Melkert Wrote:
(2016-10-10, 19:32)Niklas Buchmann Wrote: There is something seriously wrong with your radiosity definitions, though I'm not quite sure yet what exactly.

What you should do is use the built-in radiosity defintions (rad_def.inc) and work from there, this got rid of all the problems for me:

Thanks this looks much better indeed.

I noticed the 'srgb' for color 0 change, should I use that for all colors ?

One more thing about color definitions:

You defined the textures in the model using texture{} directly inside each object{} statement. Instead, it should have a material{} statement at that level, like this:

Code:
object{
 ...
 material{
   texture{}
   other material definitions
 }
}

Other material definitions include the interior{} statement for transparent objects, using a good interior makes all the difference in making transparent objects look good.
----------
my flickr
Reply
RE: POV-Ray export questions
#18
(2016-10-11, 19:55)Niklas Buchmann Wrote: You defined the textures in the model using texture{} directly inside each object{} statement. Instead, it should have a material{} statement at that level, like this:
Other material definitions include the interior{} statement for transparent objects, using a good interior makes all the difference in making transparent objects look good.

the reason for that was the texture_list property of mesh2, but I think I'm going to split it into texture and material defs so both can be used.

edit, made some changes to the generator it now renders this 'out of the box' (which I'm very happy with).
   

Colors are now generated like so:
Code:
#macro ldrawTexPlastic(r, g, b, a)
pigment {
 #if (a<1.0)
  srgbt <r,g,b,0.9>
 #else
  srgb <r,g,b>
 #end
}

normal {
 bumps 0.005
 scale 0.5
 turbulence 0
}

finish {
 emission rgb colorEmission
 diffuse 1
 brilliance 1
 conserve_energy

 phong 0.5
 phong_size 40
 metallic 0
 
 reflection {
  rgb <0.08, 0.08, 0.08>
  falloff 1
  exponent 1
  metallic 0
 }
}

#end

#macro ldrawTexRubber(r, g, b, a)
pigment {
 srgb <r,g,b>
}

normal {
 dents 0.01
 scale 0.25
 turbulence 0
}

finish {
 emission rgb colorEmission
 diffuse 1
 brilliance 0.1
 conserve_energy
}


#end

#macro ldrawTexChrome(r, g, b, a)
pigment {
 srgb <r,g,b>
}

normal {
 bumps 0.01
 scale 0.1
 turbulence 0
}

finish {
 emission rgb colorEmission*0.1
 brilliance 6
 diffuse 0.7
 metallic
 specular 0.80
 roughness 1/120
 reflection 0.8
}
#end

#declare ldTex0=texture {
ldrawTexPlastic(0.019608,0.07451,0.113725,1)
}

#declare ldMat0=material {
texture { ldTex0 }
}

#declare ldTex1=texture {
ldrawTexPlastic(0,0.333333,0.74902,1)
}

#declare ldMat1=material {
texture { ldTex1 }
}

#declare ldTex4=texture {
ldrawTexPlastic(0.788235,0.101961,0.035294,1)
}

#declare ldMat4=material {
texture { ldTex4 }
}

#declare ldTex7=texture {
ldrawTexPlastic(0.607843,0.631373,0.615686,1)
}

#declare ldMat7=material {
texture { ldTex7 }
}

#declare ldTex8=texture {
ldrawTexPlastic(0.427451,0.431373,0.360784,1)
}

#declare ldMat8=material {
texture { ldTex8 }
}

#declare ldTex9=texture {
ldrawTexPlastic(0.705882,0.823529,0.890196,1)
}

#declare ldMat9=material {
texture { ldTex9 }
}

#declare ldTex14=texture {
ldrawTexPlastic(0.94902,0.803922,0.215686,1)
}

#declare ldMat14=material {
texture { ldTex14 }
}

#declare ldTex15=texture {
ldrawTexPlastic(1,1,1,1)
}

#declare ldMat15=material {
texture { ldTex15 }
}

#declare ldTex36=texture {
ldrawTexPlastic(0.788235,0.101961,0.035294,0.501961)
}

#declare ldMat36=material {
texture { ldTex36 }
}

#declare ldTex43=texture {
ldrawTexPlastic(0.682353,0.913725,0.937255,0.501961)
}

#declare ldMat43=material {
texture { ldTex43 }
}

#declare ldTex46=texture {
ldrawTexPlastic(0.960784,0.803922,0.184314,0.501961)
}

#declare ldMat46=material {
texture { ldTex46 }
}

#declare ldTex47=texture {
ldrawTexPlastic(0.988235,0.988235,0.988235,0.501961)
}

#declare ldMat47=material {
texture { ldTex47 }
}

#declare ldTex256=texture {
ldrawTexRubber(0.129412,0.129412,0.129412,1)
}

#declare ldMat256=material {
texture { ldTex256 }
}

#declare ldTex383=texture {
ldrawTexChrome(0.878431,0.878431,0.878431,1)
}

#declare ldMat383=material {
texture { ldTex383 }
}

The contents of ldrawTex* macros are read from a config file so you could always tweak them, I'll probably also going to surround most stuff with 'if defined' conditions.

Transparent part improvements (using material) still pending though.
Reply
RE: POV-Ray export questions
#19
(2016-10-11, 20:54)Roland Melkert Wrote:
(2016-10-11, 19:55)Niklas Buchmann Wrote: You defined the textures in the model using texture{} directly inside each object{} statement. Instead, it should have a material{} statement at that level, like this:
Other material definitions include the interior{} statement for transparent objects, using a good interior makes all the difference in making transparent objects look good.

the reason for that was the texture_list property of mesh2, but I think I'm going to split it into texture and material defs so both can be used.

edit, made some changes to the generator it now renders this 'out of the box' (which I'm very happy with).


Colors are now generated like so:
Code:
#macro ldrawTexPlastic(r, g, b, a)
pigment {
 #if (a<1.0)
  srgbt <r,g,b,0.9>
 #else
  srgb <r,g,b>
 #end
}

normal {
 bumps 0.005
 scale 0.5
 turbulence 0
}

finish {
 emission rgb colorEmission
 diffuse 1
 brilliance 1
 conserve_energy

 phong 0.5
 phong_size 40
 metallic 0
 
 reflection {
  rgb <0.08, 0.08, 0.08>
  falloff 1
  exponent 1
  metallic 0
 }
}

#end

#macro ldrawTexRubber(r, g, b, a)
pigment {
 srgb <r,g,b>
}

normal {
 dents 0.01
 scale 0.25
 turbulence 0
}

finish {
 emission rgb colorEmission
 diffuse 1
 brilliance 0.1
 conserve_energy
}


#end

#macro ldrawTexChrome(r, g, b, a)
pigment {
 srgb <r,g,b>
}

normal {
 bumps 0.01
 scale 0.1
 turbulence 0
}

finish {
 emission rgb colorEmission*0.1
 brilliance 6
 diffuse 0.7
 metallic
 specular 0.80
 roughness 1/120
 reflection 0.8
}
#end

#declare ldTex0=texture {
ldrawTexPlastic(0.019608,0.07451,0.113725,1)
}

#declare ldMat0=material {
texture { ldTex0 }
}

#declare ldTex1=texture {
ldrawTexPlastic(0,0.333333,0.74902,1)
}

#declare ldMat1=material {
texture { ldTex1 }
}

#declare ldTex4=texture {
ldrawTexPlastic(0.788235,0.101961,0.035294,1)
}

#declare ldMat4=material {
texture { ldTex4 }
}

#declare ldTex7=texture {
ldrawTexPlastic(0.607843,0.631373,0.615686,1)
}

#declare ldMat7=material {
texture { ldTex7 }
}

#declare ldTex8=texture {
ldrawTexPlastic(0.427451,0.431373,0.360784,1)
}

#declare ldMat8=material {
texture { ldTex8 }
}

#declare ldTex9=texture {
ldrawTexPlastic(0.705882,0.823529,0.890196,1)
}

#declare ldMat9=material {
texture { ldTex9 }
}

#declare ldTex14=texture {
ldrawTexPlastic(0.94902,0.803922,0.215686,1)
}

#declare ldMat14=material {
texture { ldTex14 }
}

#declare ldTex15=texture {
ldrawTexPlastic(1,1,1,1)
}

#declare ldMat15=material {
texture { ldTex15 }
}

#declare ldTex36=texture {
ldrawTexPlastic(0.788235,0.101961,0.035294,0.501961)
}

#declare ldMat36=material {
texture { ldTex36 }
}

#declare ldTex43=texture {
ldrawTexPlastic(0.682353,0.913725,0.937255,0.501961)
}

#declare ldMat43=material {
texture { ldTex43 }
}

#declare ldTex46=texture {
ldrawTexPlastic(0.960784,0.803922,0.184314,0.501961)
}

#declare ldMat46=material {
texture { ldTex46 }
}

#declare ldTex47=texture {
ldrawTexPlastic(0.988235,0.988235,0.988235,0.501961)
}

#declare ldMat47=material {
texture { ldTex47 }
}

#declare ldTex256=texture {
ldrawTexRubber(0.129412,0.129412,0.129412,1)
}

#declare ldMat256=material {
texture { ldTex256 }
}

#declare ldTex383=texture {
ldrawTexChrome(0.878431,0.878431,0.878431,1)
}

#declare ldMat383=material {
texture { ldTex383 }
}

The contents of ldrawTex* macros are read from a config file so you could always tweak them, I'll probably also going to surround most stuff with 'if defined' conditions.

Transparent part improvements (using material) still pending though.

Looks very nice, though I still think that the black color looks too blue.

Have you looked into using interior{}? I think having refraction on transparent parts makes a huge difference:

[Image: 29727799574_a4e09ed234_b.jpg]LEGO 5571'Black Cat' by Niklas-B, auf Flickr
----------
my flickr
Reply
RE: POV-Ray export questions
#20
(2016-10-16, 11:36)Niklas Buchmann Wrote: Looks very nice, though I still think that the black color looks too blue.

Have you looked into using interior{}? I think having refraction on transparent parts makes a huge difference:

Yes I'm now using:
Code:
#macro ldrawTexPlastic(r, g, b, a)
pigment {
 #if (a<1.0)
  srgbt <r,g,b,0.75>
 #else
  srgb <r,g,b>
 #end
}
 
normal {
 bumps 0.005
 scale 0.5
 turbulence 0
}
 
finish {
 emission rgb colorEmission
 diffuse 1
 brilliance 1
 conserve_energy
 
 phong 0.5
 phong_size 40
 metallic 0
 
 reflection 0.1
}
#end

#macro ldrawMatPlastic(r, g, b, a, tex)
texture { tex }

#if (a<1.0)
 interior { ior 3 }
#end
#end

#declare ldTex4=texture {
ldrawTexPlastic(0.788235,0.101961,0.035294,1)
}

#declare ldMat4=material {
ldrawMatPlastic(0.788235,0.101961,0.035294,1,ldTex4)
}

Still tweaking the rubber and metals though.

I think the tint in black is caused by the skysphere.
Reply
RE: POV-Ray export questions
#16
(2016-10-10, 19:32)Niklas Buchmann Wrote:
(2016-10-08, 23:01)Roland Melkert Wrote: Hi all,

I've almost finished the POVRay export feature for LDCad 1.6 but I'm having problems with the default material definitions.

Below is a zipped export of the 5571 model which renders nice using normal lighting, but acts very weird when using radiosity. It's caused by the chrome material but I have no clue on the why.

Anyone has some pointers or alternative chrome material definitions  (or any of the other material kinds rubber/metal/mattemetal/plainplastic/pearl)

normal render:


radiosity:



pov files
http://www.melkert.net/action/download/pov5571.zip

Any help / pointers are welcome

There is something seriously wrong with your radiosity definitions, though I'm not quite sure yet what exactly.

What you should do is use the built-in radiosity defintions (rad_def.inc) and work from there, this got rid of all the problems for me:



The zipped .pov file was too large for attachment, so I included a .txt file with the relevant bits.

The max_trace_level was set to 20, that's pretty high and can slow rendering down. I routinely use 8 and never ran into any problems.

I think you should just include rad_def.inc as a default include. The POV maintainers have tweaked it pretty well.
Reply
RE: POV-Ray export questions
#22
I didn't know you were working on an Pov-Ray exporter. Sounds great!
Will it be a basic exporter, or will it include more features like LDD-to-povray (I recommend installing it to see what I mean)?

Nevertheless, great work  Smile
Reply
RE: POV-Ray export questions
#11
If you could please make it easy to disable the following using a few flags or switches:

1. camera
2. lights
3. floor
4. background
5. global_settings
6. colors/pigments/finishes/materials

LDView does all this, except for the last three. This is because I like to use INC files to store custom materials, camera settings, etc. that are used in multiple scenes.

Also, I notice you are using "rgb" or "rgbft" for pigments. You should be using "srgb" or "srgbft" instead. This is the new POV-Ray 3.7 standard.

Lastly, you should add support for LGEO parts as these often look better.

Thanks!
Reply
RE: POV-Ray export questions
#12
The final version will be highly configurable (allows for include files before and or after the main script blocks, changeable color prefixes etc).

Support for LGEO is something I want to add but it probably be in the second beta version as I was kinda waiting on a unified package with darat's work etc.

The main goal for these exports is animation support so I'm aiming the 'out of the box' exports on speed as I for one don't want animations to render for months :Smile

For example your datsville (369) renders in less then 20 seconds whit a <1.5 GB memory print.

   
   

Thanks for the hints, I'll look into the trace level options.
Reply
RE: POV-Ray export questions
#21
LOL

I don't think creating Datsville animations is feasible using current home computers. I've considered setting up an Microsoft Azure account. But the time consuming part right now for me is *parsing* the model, not *rendering* it. And parsing is a single core process.

OTOH, if I turn on radiosity, then having multiple cores during the render phase becomes important.
Reply
pov-ray > png > video = weird colors
#23
Been playing around with the (near) final exporter when I noticed this:

   

Yellow is completely wrong in the resulting (h264) video.

Anyone know what is causing this, is it a POV-Ray problem or a video conversion issue?
Reply
RE: pov-ray > png > video = weird colors
#24
I's say that if the pngs look good, then it's a video conversion issue?
Reply
RE: pov-ray > png > video = weird colors
#25
(2016-11-10, 20:32)Philippe Hurbain Wrote: I's say that if the pngs look good, then it's a video conversion issue?

I was thinking about the assumed gamma (2.2) messing with things later on or something.
Reply
RE: pov-ray > png > video = weird colors
#27
(2016-11-10, 22:44)Roland Melkert Wrote:
(2016-11-10, 20:32)Philippe Hurbain Wrote: I's say that if the pngs look good, then it's a video conversion issue?

I was thinking about the assumed gamma (2.2) messing with things later on or something.

You shouldn't really ever change assumed_gamma from 1.0.
Reply
RE: pov-ray > png > video = weird colors
#26
(2016-11-10, 20:18)Roland Melkert Wrote: Been playing around with the (near) final exporter when I noticed this:



Yellow is completely wrong in the resulting (h264) video.

Anyone know what is causing this, is it a POV-Ray problem or a video conversion issue?

It could be a gamma issue. You might want to ask on the povray newsgroup.

http://news.povray.org/groups/
Reply
POV-Ray textured parts export
#28
Final thing to do for the pov export of LDCad 1.6 is getting those pesky textured parts into povray.

I managed to setup a rudimentary export of them but I'm running into all kinds of problems which will spoil things in many cases.

   

As you can see the textured minifig heads are ok but the earth is way to dark. I'm not sure why though as the whole 'layered textures' concept of POV-Ray isn't very clear to me to start with.

Second problem is in order to use the textured parts in multiple colors I had to generate macro's instead of declares for those parts. Because you basically need a different one for each used color. This means the model object using them need to know what color they'll be which in turn means you can't place a textured part using color 16 in a submodel unless I convert the whole model tree leading to it into macro's which will make things more complicated for the animation depend color changes etc.

So with the !TEXMAP meta hardly used in the wild I'm wondering of this is worth all the problems I'm facing.

Attached is the generated pov script, any ideas on improvements or an alternative way of handling the textures altogether are highly welcome.


Attached Files
.zip   texTest-povExport.zip (Size: 780.99 KB / Downloads: 3)
Reply
RE: POV-Ray textured parts export
#29
(2016-11-16, 23:53)Roland Melkert Wrote: Final thing to do for the pov export of LDCad 1.6 is getting those pesky textured parts into povray.

I managed to setup a rudimentary export of them but I'm running into all kinds of problems which will spoil things in many cases.



As you can see the textured minifig heads are ok but the earth is way to dark. I'm not sure why though as the whole 'layered textures' concept of POV-Ray isn't very clear to me to start with.

Second problem is in order to use the textured parts in multiple colors I had to generate macro's instead of declares for those parts. Because you basically need a different one for each used color. This means the model object using them need to know what color they'll be which in turn means you can't place a textured part using color 16 in a submodel unless I convert the whole model tree leading to it into macro's which will make things more complicated for the animation depend color changes etc.

So with the !TEXMAP meta hardly used in the wild I'm wondering of this is worth all the problems I'm facing.

Attached is the generated pov script, any ideas on improvements or an alternative way of handling the textures altogether are highly welcome.

1. Setting assumed_gamma to 1.0 will brighten up the Earth model.
2. Also, why are you using emission in your pigments?
3. Light sources should use rgb not srgb.
4. I don't have a lot of experience with meshes, but from looking at your code it doesn't appear you can avoid using macros in this case.
Reply
RE: POV-Ray textured parts export
#30
(2016-11-17, 2:43)Michael Horvath Wrote: 1. Setting assumed_gamma to 1.0 will brighten up the Earth model.
2. Also, why are you using emission in your pigments?
3. Light sources should use rgb not srgb.
4. I don't have a lot of experience with meshes, but from looking at your code it doesn't appear you can avoid using macros in this case.
1: yes but it  will make everything else very bleek.
2: Emission is the 3.7 way of doing ambient lighting (this way radiosity on/off won't make a huge difference in brightness like it did in 3.6)
3: srgb does some fancy things with the gamma value.
4: I'm afraid so, I wish Povray had some more options for mesh property inheritance.

In the meantime i have found the reason for it being dark (you mentioning emission triggerd that Smile  )
It turns out the 2nd texture also overwrites the 'finish' part of the first texture (the normal plastic one in this case).

Solving it in the generator is a big pain though as it needs different declarations for transparent (minifigs) or non transparent (earth) texture images.

I think I have to set up a macro that can generate a texture or material based on the color number instead of the loose color declarations for this so I can merge a texture better.

This would be so much easier if POV-Ray allowed inheritance Sad
Reply
RE: POV-Ray textured parts export
#31
(2016-11-17, 18:22)Roland Melkert Wrote:
(2016-11-17, 2:43)Michael Horvath Wrote: 1. Setting assumed_gamma to 1.0 will brighten up the Earth model.
2. Also, why are you using emission in your pigments?
3. Light sources should use rgb not srgb.
4. I don't have a lot of experience with meshes, but from looking at your code it doesn't appear you can avoid using macros in this case.
1: yes but it  will make everything else very bleek.
2: Emission is the 3.7 way of doing ambient lighting (this way radiosity on/off won't make a huge difference in brightness like it did in 3.6)
3: srgb does some fancy things with the gamma value.
4: I'm afraid so, I wish Povray had some more options for mesh property inheritance.

In the meantime i have found the reason for it being dark (you mentioning emission triggerd that Smile  )
It turns out the 2nd texture also overwrites the 'finish' part of the first texture (the normal plastic one in this case).

Solving it in the generator is a big pain though as it needs different declarations for transparent (minifigs) or non transparent (earth) texture images.

I think I have to set up a macro that can generate a texture or material based on the color number instead of the loose color declarations for this so I can merge a texture better.

This would be so much easier if POV-Ray allowed inheritance Sad

1. assumed_gamma 1.0 is what POVray 3.7 was designed to use. If the colors are bleak, then the problem is with your colors, not the gamma setting.
2. Emission has nothing to do with ambient lighting. Emission is for objects that are supposed to emit light like a bulb versus reflecting it.
3. I have asked again on the POV newsgroup. We shall see.

Mike
Reply
RE: POV-Ray textured parts export
#33
(2016-11-18, 3:04)Michael Horvath Wrote: 1. assumed_gamma 1.0 is what POVray 3.7 was designed to use. If the colors are bleak, then the problem is with your colors, not the gamma setting.
2. Emission has nothing to do with ambient lighting. Emission is for objects that are supposed to emit light like a bulb versus reflecting it.
3. I have asked again on the POV newsgroup. We shall see.

2: from the manual:

3.4.6.3.2 Emission Wrote:As of version 3.7, you can now add the emission keyword to the finish block. The intention is to simplify the use of materials designed for non-radiosity scenes in scenes with radiosity, or the design of scenes that can be rendered with or without radiosity.

The syntax and effect are virtually identical to ambient, except that emission is unaffected by the global ambient_light parameter. An objects ambient term is now effectively set to 0 if radiosity is active, the exception being, in legacy scenes where the #version is set to less than 3.7
Reply
RE: POV-Ray textured parts export
#34
(2016-11-18, 17:59)Roland Melkert Wrote:
(2016-11-18, 3:04)Michael Horvath Wrote: 1. assumed_gamma 1.0 is what POVray 3.7 was designed to use. If the colors are bleak, then the problem is with your colors, not the gamma setting.
2. Emission has nothing to do with ambient lighting. Emission is for objects that are supposed to emit light like a bulb versus reflecting it.
3. I have asked again on the POV newsgroup. We shall see.

2: from the manual:

3.4.6.3.2 Emission Wrote:As of version 3.7, you can now add the emission keyword to the finish block. The intention is to simplify the use of materials designed for non-radiosity scenes in scenes with radiosity, or the design of scenes that can be rendered with or without radiosity.

The syntax and effect are virtually identical to ambient, except that emission is unaffected by the global ambient_light parameter. An objects ambient term is now effectively set to 0 if radiosity is active, the exception being, in legacy scenes where the #version is set to less than 3.7

I still don't think it's preferable. If you turn on radiosity, then the emission will light up neighboring objects. This is not realistic. You can get perfectly good looking results without using emission.
Reply
RE: POV-Ray textured parts export
#35
(2016-11-18, 18:28)Michael Horvath Wrote: I still don't think it's preferable. If you turn on radiosity, then the emission will light up neighboring objects. This is not realistic. You can get perfectly good looking results without using emission.

That is exactly what it suposed to do as far I understand it. It simulates the global scattering of lights you have in the real world whose lights seemingly come from all directions (== global or ambient lighting).

If you don't like it in the LDCad export you can always set it colorEmission to 0.0 or rewrite the material generation macro's (e.g. ldrawTexPlastic in above pov file) as those are read from external files.
Reply
RE: POV-Ray textured parts export
#37
(2016-11-18, 19:01)Roland Melkert Wrote:
(2016-11-18, 18:28)Michael Horvath Wrote: I still don't think it's preferable. If you turn on radiosity, then the emission will light up neighboring objects. This is not realistic. You can get perfectly good looking results without using emission.

That is exactly what it suposed to do as far I understand it. It simulates the global scattering of lights you have in the real world whose lights seemingly come from all directions (== global or ambient lighting).

If you don't like it in the LDCad export you can always set it colorEmission to 0.0 or rewrite the material generation macro's (e.g. ldrawTexPlastic in above pov file)  as those are read from external files.

If I, as the designer of both POV-Ray's current gamma handling framework and the "emission" mechanism, may chime in:
  • The "emission" mechanism was introduced specifically to allow for the "ambient" mechanism to be turned off in radiosity scenes, while still allowing to define materials that emit light all by themselves. You see, radiosity and "ambient" were essentially designed to model one and the same thing: Illumination due to light scattered off other diffuse objects, lighting up even areas that are in total shadow. "Ambient" is a quick but dirty approach adding a constant term, while radiosity is a more precise but costly approach essentialy computing this type of illumination for each point on the surface. Having two mechanisms enabled at the same time to model this effect is pointless, and hence "ambient" is now automatically suppressed if radiosity is switched on. The "emission" mechanism was added as a replacement for the cases where "ambient" was co-opted to model something entirely different, namely materials glowing all by themselves.
    If the "colorEmission" parameter is supposed to model global scattering of lights, then you should use "ambient". If instead it is supposed to model glow-in-the-dark materials, then "emission" is the mechanism to use.
  • For realistic results (and who wouldn't want LDraw models rendered as realistically as possible!) "assumed_gamma 1.0" is a must, and this may also fix the issues you see with image-based textures appearing too dark. It is a known fact that using this mode increases the overall brightness in a scene and also reduces colour saturation, unless parameters are adjusted to compensate. You're already doing the most important thing: Using "srgb" instead of "rgb" in pigment definitions. However, it has recently been brought to attention that the finish parameters also needs some care: In general, any "ambient", "emission", "diffuse", "phong", "specular" or "reflection" setting lower than 1.0 should be set to an even lower values, with x^2.2 being a good starting point. It is impossible to give an exact formula, as the colour math in "assumed_gamma 2.2" mode is physically wrong, and thus the results in the physically accurate "assumed_gamma 1.0" mode will inevitably differ in one place or another.
I hope this helps. If you need more information or assistance, let me know.

As a side note, I'd like to point out that for optimal realism the index of refraction should be around 1.6, and that realism may benefit from fresnel-based variable reflection. Also, personally I'd recommend "specular" instead of "phong" for highlights, but that may just be personal preference.
Reply
RE: POV-Ray textured parts export
#38
(2016-11-18, 22:37)Christoph Lipka Wrote: If I, as the designer of both POV-Ray's current gamma handling framework and the "emission" mechanism, may chime in:
......
I hope this helps. If you need more information or assistance, let me know.

As a side note, I'd like to point out that for optimal realism the index of refraction should be around 1.6, and that realism may benefit from fresnel-based variable reflection. Also, personally I'd recommend "specular" instead of "phong" for highlights, but that may just be personal preference.
Thanks Christoph,

It seems I completely misunderstood the emission so Mike was right about me misusing that as global lighting.
I'll change things back to ambient in the generator

I indeed need to fine tune the LEGO like plastic etc especially chrome and metal. But those arn't hardcoded in the generator anyway.

The gamma issue is also more clear to me now (I'vealso read the gamma thread on new.povray.org Mike pointed at).
I'll switch to the 1.0 approach for default settings. I was mostly 'fooled' by the nicer colors I was getting (especially red) while it sits on 2.2 but those were probably unrealistic anyway as real LEGO red is more of a brownish anyway.

The current version using gamma 1.0 and no emission generates this for a  simple scene (pov source attached).

   

Thanks for your insight.


Attached Files
.zip   texTest-povExport.zip (Size: 75.4 KB / Downloads: 1)
Reply
RE: POV-Ray textured parts export
#39
(2016-11-19, 0:07)Roland Melkert Wrote: The current version using gamma 1.0 and no emission generates this for a  simple scene (pov source attached).

It looks to me like you're using a pigment colour with a filter component to give colour to the transparent pieces; I'd suggest using the interior fade_color mechanism instead, as it gives more realistic results.
Reply
RE: POV-Ray textured parts export
#40
(2016-11-19, 1:49)Christoph Lipka Wrote: It looks to me like you're using a pigment colour with a filter component to give colour to the transparent pieces; I'd suggest using the interior fade_color mechanism instead, as it gives more realistic results.

I've been tweaking the texture / materials. Combinations are endless you can easily get obsessed with it. I think I'll finish Beta 1 first before tweaking it some more  Smile

   

Thanks again.

edit: some more tweaking just need to improve rubber at bit more I think
   
Reply
RE: POV-Ray textured parts export
#32
Here are some tips from when I asked about gamma last year:

http://news.povray.org/povray.advanced-u...ay.org%3E/
Reply
RE: POV-Ray textured parts export
#36
(2016-11-16, 23:53)Roland Melkert Wrote: Final thing to do for the pov export of LDCad 1.6 is getting those pesky textured parts into povray.

Latest output:

   

And its original OpenGL rendering:

   

Transparent isn't the same for the patterned parts but I think I can live with this for now.
Reply
RE: POV-Ray export questions
#41
Hello all,

Below is the (for now) default output for 1.6 Beta 1 I think.

   

I feel I could spend ages on fine tuning this stuff so I'm deciding to leave it for now in order to finish Beta 1 Smile

Once the beta is out I'll probably resume finetuing the default output. And the main material properties are controlled by an inlined .pov file so I would highly appreciate anyone willing to help with that. Just let me know.

If someone likes to play around with the materials right now, just mail me some (small) LDraw scene/model and I'll send you back a Pov file which you can use to fine tune materials. I can then later copy those values if needed back into the default template.

Thanks for all the advise / insights.
Reply
RE: POV-Ray export questions
#42
(2016-11-24, 22:31)Roland Melkert Wrote: Hello all,

Below is the (for now) default output for 1.6 Beta 1 I think.



I feel I could spend ages on fine tuning this stuff so I'm deciding to leave it for now in order to finish Beta 1 Smile

Once the beta is out I'll probably resume finetuing the default output. And the main material properties are controlled by an inlined .pov file so I would highly appreciate anyone willing to help with that. Just let me know.

If someone likes to play around with the materials right now, just mail me some (small) LDraw scene/model and I'll send you back a Pov file which you can use to fine tune materials. I can then later copy those values if needed back into the default template.

Thanks for all the advise / insights.

Will future versions support LGEO parts?

Also, you might consider supporting alternate renderers such as SunFlow. It's a bit quicker than POV-Ray, and produces decent results.

http://lego.queryen.com/php/_sfmod.php
Reply
RE: POV-Ray export questions
#43
(2016-11-25, 2:07)Michael Horvath Wrote: Also, you might consider supporting alternate renderers such as SunFlow. It's a bit quicker than POV-Ray, and produces decent results.

I hate to say it, but I don't really trust anyone who feels the need to use adfly for all their links. Adfly does everything they can to deceive people into clicking on crap. Not to mention, it appears that the latest release of Sunflow was released in 2007, and the project is now dead. It seems like an odd choice for msx80 to have used for their rendering engine for LDD, unless there's something I don't know about.
Reply
RE: POV-Ray export questions
#45
(2016-11-25, 4:10)Travis Cobbs Wrote:
(2016-11-25, 2:07)Michael Horvath Wrote: Also, you might consider supporting alternate renderers such as SunFlow. It's a bit quicker than POV-Ray, and produces decent results.

I hate to say it, but I don't really trust anyone who feels the need to use adfly for all their links. Adfly does everything they can to deceive people into clicking on crap. Not to mention, it appears that the latest release of Sunflow was released in 2007, and the project is now dead. It seems like an odd choice for msx80 to have used for their rendering engine for LDD, unless there's something I don't know about.

The webpage linked by Michael is not he 'official' bluerender website though. That guy just creates 'mods' and guides for Bluerender, Bluerender itself can be found here (without adfly links):
http://www.eurobricks.com/forum/index.ph...e-for-ldd/
Reply
RE: POV-Ray export questions
#46
(2016-11-26, 8:39)Merlijn Wissink Wrote:
(2016-11-25, 4:10)Travis Cobbs Wrote: I hate to say it, but I don't really trust anyone who feels the need to use adfly for all their links. Adfly does everything they can to deceive people into clicking on crap. Not to mention, it appears that the latest release of Sunflow was released in 2007, and the project is now dead. It seems like an odd choice for msx80 to have used for their rendering engine for LDD, unless there's something I don't know about.

The webpage linked by Michael is not he 'official' bluerender website though. That guy just creates 'mods' and guides for Bluerender, Bluerender itself can be found here (without adfly links):
http://www.eurobricks.com/forum/index.ph...e-for-ldd/

Sorry, I thought the 'mods' were a necessary part.
Reply
RE: POV-Ray export questions
#44
(2016-11-25, 2:07)Michael Horvath Wrote: Will future versions support LGEO parts?
Maybe, if so I probably want to make it possible by using an alternative configuration template which means its basically done through macros.

(2016-11-25, 2:07)Michael Horvath Wrote: Also, you might consider supporting alternate renderers such as SunFlow. It's a bit quicker than POV-Ray, and produces decent results.
The main reason I started the POV-Ray export is to support HQ animation export, does SunFlow has animation capabilities or would you have to generate separate scripts for each frame?

(2016-11-25, 4:10)Travis Cobbs Wrote: I hate to say it, but I don't really trust anyone who feels the need to use adfly for all their links. Adfly does everything they can to deceive people into clicking on crap. Not to mention, it appears that the latest release of Sunflow was released in 2007, and the project is now dead. It seems like an odd choice for msx80 to have used for their rendering engine for LDD, unless there's something I don't know about.
Sounds like someone hijacked the project. If so I will never support it.
Reply
RE: POV-Ray export questions
#47
(2016-11-25, 18:44)Roland Melkert Wrote:
(2016-11-25, 2:07)Michael Horvath Wrote: Will future versions support LGEO parts?
Maybe, if so I probably want to make it possible by using an alternative configuration template which means its basically done through macros.

(2016-11-25, 2:07)Michael Horvath Wrote: Also, you might consider supporting alternate renderers such as SunFlow. It's a bit quicker than POV-Ray, and produces decent results.
The main reason I started the POV-Ray export is to support HQ animation export, does SunFlow has animation capabilities or would you have to generate separate scripts for each frame?

(2016-11-25, 4:10)Travis Cobbs Wrote: I hate to say it, but I don't really trust anyone who feels the need to use adfly for all their links. Adfly does everything they can to deceive people into clicking on crap. Not to mention, it appears that the latest release of Sunflow was released in 2007, and the project is now dead. It seems like an odd choice for msx80 to have used for their rendering engine for LDD, unless there's something I don't know about.
Sounds like someone hijacked the project. If so I will never support it.

Sorry, here is the real SunFlow website. No AdFly.

http://sunflow.sourceforge.net/

I don't know anything about it, really, except for doing some test renders. The 'Features' page doesn't list animations anywhere.

It's too bad if the project is dead. The quality of the renders was decent, and the speed much better than POV-Ray.
Reply
RE: POV-Ray export questions
#48
POV-Ray export is finished Smile

Small test animation of Philo's 42042 MPD.

https://youtu.be/34Ypp7HF1Dc
Reply
RE: POV-Ray export questions
#49
Brilliant !
Reply
RE: POV-Ray export questions
#50
(2016-11-30, 22:20)Roland Melkert Wrote: POV-Ray export is finished Smile

Small test animation of Philo's 42042 MPD.

https://youtu.be/34Ypp7HF1Dc

Could you remind me which menu is the export command located in? It has been a while, and I forgot where it is.

LDCad 1.6b
Reply
RE: POV-Ray export questions
#51
(2019-06-14, 1:48)Michael Horvath Wrote: Could you remind me which menu is the export command located in? It has been a while, and I forgot where it is.
View ->editing views->export (alt+e)
Reply
RE: POV-Ray export questions
#52
(2019-06-14, 7:45)Philippe Hurbain Wrote: View ->editing views->export (alt+e)

Thanks! That's not an obvious location to look for the command IMO. (Or at least not obvious to me.)
Reply
RE: POV-Ray export questions
#53
(2019-06-16, 4:44)Michael Horvath Wrote: Thanks! That's not an obvious location to look for the command IMO. (Or at least not obvious to me.)
I must say it is not obvious for me either...
Reply
RE: POV-Ray export questions
#54
(2019-06-16, 7:28)Philippe Hurbain Wrote: I must say it is not obvious for me either...

I agree the menu structure could use some improvement, but in my mind this one was logical as you want to export the editing view content.

I'll try to do better in 2.0 Big Grin
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)