455 replies to this topic

[hrontos]

Judah Nielsen, on 24 July 2012 - 08:44 PM, said:

My math suggests this number is a factor of 2 too high (i'm looking at a triangle with camera distance as the "adjacent" but only half the model length as the "opposite", which is where we differ by 2), and my test render does have a lot of whitespace. You need some whitespace, especially if you're rendering a shadow on the baseplane, but I'm going to see if replacing the denominator with 1.5*tan(...) gives me a better result.

This related to the projection and perspective. Perfect fit strongly depends on them, but you can scale it as you proposed.

Judah Nielsen, on 24 July 2012 - 08:44 PM, said:

I also suspect, but haven't done the renders to prove it, that this would be even worse if you had the smallest dimension facing the camera (in this case the front), since the distance is always calculated from the largest dimension, which might be going into the screen.

Yes, you are right, max should be calculated only from the other two dimensions. I already corrected the example.

[Smartiac]

Thought I'd chip in again with a successful render of my mini-brickley model.  It looks absolutely amazing except for the strange reflections going on around the 2x dishes around the eyes.  Any explanation for that?


brickley by Proudlove, on Flickr

[hrontos]

Smartiac, on 24 July 2012 - 09:24 PM, said:

Thought I'd chip in again with a successful render of my mini-brickley model.  It looks absolutely amazing except for the strange reflections going on around the 2x dishes around the eyes.  Any explanation for that?

Image

I have seen this picture on your Flickr. Nice model, my kids would love it. And a nice render.

What is the material for the eyes? Is it some mettalic? What radiosity settings did you used?

[C3POwen]

Smartiac, on 24 July 2012 - 09:24 PM, said:

It looks absolutely amazing except for the strange reflections going on around the 2x dishes around the eyes.  Any explanation for that?

They look like radiosity artifacts, which show up more on the dishes than anywhere else, although they can be seen (albeit subtly) elsewhere in the model.

@hrontos: Not having installed LDD2POVRay myself, does it take advantage of POV-Ray's built-in radiosity macro ("Radiosity_Final", etc.) when rendering models?

[hrontos]

C3POwen, on 24 July 2012 - 09:39 PM, said:

They look like radiosity artifacts, which show up more on the dishes than anywhere else, although they can be seen (albeit subtly) elsewhere in the model.

I also think that it is due to radiosity settings, that's why I asked which were used and what is the material.

C3POwen, on 24 July 2012 - 09:39 PM, said:

@hrontos: Not having installed LDD2POVRay myself, does it take advantage of POV-Ray's built-in radiosity macro ("Radiosity_Final", etc.) when rendering models?

Yes, there is a possibility to use those POV-Ray's built in settings. User can select it from a combo, but the default option is "custom" which generates complete radiosity block into POV file. This radiosity block contain settings which perform quite well for most of the models and are much faster than built in Radiosity_Final settings.

[C3POwen]

hrontos, on 24 July 2012 - 09:52 PM, said:

This radiosity block contain settings which perform quite well for most of the models and are much faster than built in Radiosity_Final settings.

Since using POV-Ray to render Lego models, I've found the setting that best suits the geometrical shapes of Lego is based on a setting shared by whitew0lf:

global_settings {
		max_trace_level 10
		radiosity {
				pretrace_start 0.08
				pretrace_end   0.005
				count 1600
				nearest_count 20
				error_bound 0.02
				recursion_limit 1
				low_error_factor 0.25
				gray_threshold 0
				minimum_reuse 0.015
				brightness 1.0
				adc_bailout 0.01/2
				normal on
				media off
		}
}

It's a bit slower than the default "Radiosity_Final" setting, but gives much smoother results, especially on large images.

[hrontos]

C3POwen, on 24 July 2012 - 10:34 PM, said:

Since using POV-Ray to render Lego models, I've found the setting that best suits the geometrical shapes of Lego is based on a setting shared by whitew0lf:

It's a bit slower than the default "Radiosity_Final" setting, but gives much smoother results, especially on large images.

Thank you for sharing, I will try them.

The "Custom" block used by LDD2POVRay looks like this. As I said, it is faster than Final and not that bad for most cases. I tried to find a settings which will not make an average user loose his patience.  

radiosity {
	pretrace_start 0.08
	pretrace_end   0.005
	count 450
	nearest_count 4
	error_bound 0.05
	recursion_limit 1
	low_error_factor 0.3
	gray_threshold 0.0
	minimum_reuse 0.005
	//maximum_reuse 0.2
	brightness 1
	adc_bailout 0.005
	normal on
	media on
  }

@Smartiac: if you want to give it a try, replace the radiosity block in the POV file by the one proposed by C3POwen and render the brickley once again. It possible to render only a portion of an image, if you want

Edited by hrontos, 24 July 2012 - 10:54 PM.

[Superkalle]

@Smartiac: I'm curious what the yellowish color is on the 1x2 and 1x3 plates on the belly of the dragon. Is it standard yellow? If so, it doesn't come out too good in the rendering (so nothing wrong with your MOC:classic:). BTW: great looking model. The nose with the nostrels is a genius NPU  

@Hrontos. Idea for future versions: the pins on the underside of some bricks and plates could have small holes in them to make it look more realistic. It's the 1 x X bricks and plates I'm referring too (sorry about the humongous pic, but I couldn't find any other right now):

[hrontos]

Superkalle, on 25 July 2012 - 10:11 AM, said:

@Hrontos. Idea for future versions: the pins on the underside of some bricks and plates could have small holes in them to make it look more realistic. It's the 1 x X bricks and plates I'm referring too (sorry about the humongous pic, but I couldn't find any other right now):

Yes, this shouldn't be a problem since there is a direct relation between a stud and a hole - all studs with logo have that hole (I think not only 1xX bricks and plates).

[Superkalle]

hrontos, on 25 July 2012 - 10:45 AM, said:

Yes, this shouldn't be a problem since there is a direct relation between a stud and a hole - all studs with logo have that hole (I think not only 1xX bricks and plates).

I'm talking about that very small hole (about 1 mm diameter) that is in the pin. Is that what you mean too? I'm not referring to the indent exactly opposite a stud, but that is a possibility too  

[hrontos]

Superkalle, on 25 July 2012 - 11:04 AM, said:

I'm talking about that very small hole (about 1 mm diameter) that is in the pin. Is that what you mean too? I'm not referring to the indent exactly opposite a stud, but that is a possibility too  

OK, now I understand which one. Yes, it should be possible to add also that one. It is just less automatic, because it is necessary to specify exactly which bricks have it, since LDD categorization won't be sufficient. Once it is know, that some brick should have it, exact location of that hole can be determined automatically.

[Calabar]

Note that TLG produces bricks with and without the micro-holes.
For example in my House 4956 I found 1x6 bricks white with the oles and other without that. And probably other bricks/plates too.

[hrontos]

Calabar, on 25 July 2012 - 12:00 PM, said:

Note that TLG produces bricks with and without the micro-holes.
For example in my House 4956 I found 1x6 bricks white with the oles and other without that. And probably other bricks/plates too.

Haha, may be we should move to higher level and add another field into the LDD2POVRay screen where user can specify a production year. Like make my render look like from 1980. Just kidding.
Seriously, it is no problem to take care of these differences when two versions of the same looking brick have two different design IDs. When there is only one, it is possible, but probably too complicated and too much detailed for a standard LDD user.

Edited by hrontos, 25 July 2012 - 12:17 PM.

[hrontos]

Superkalle, on 25 July 2012 - 10:11 AM, said:

@Hrontos. Idea for future versions: the pins on the underside of some bricks and plates could have small holes in them to make it look more realistic. It's the 1 x X bricks and plates I'm referring too (sorry about the humongous pic, but I couldn't find any other right now):

Is this what you expected?

[Superkalle]

hrontos, on 25 July 2012 - 09:44 PM, said:

Is this what you expected?

Yes  

(and looking at it now I must say it makes a huge difference to the realism!)

And please note that the indents should not be on the underside of technic studs but only on "normal" ones (with the LEGO logo)  

[hrontos]

Superkalle, on 26 July 2012 - 03:32 PM, said:

Yes  

(and looking at it now I must say it makes a huge difference to the realism!)

And please note that the indents should not be on the underside of technic studs but only on "normal" ones (with the LEGO logo)  

Yes, it looks better with those small holes. I have found 355 bricks, that have that "pin" you mentioned (and asked for a hole in that pin), but I am pretty sure, not all of them should have the pin with hole. Some of them should have the pin without the hole. To be honest, I did not tried to sort them out, because it probably means to look at each physical brick. I am not sure if Bricklink can help, since images there are usually from the top and not from the bottom.

The other added holes are only under standard studs and not technic studs.

[Superkalle]

hrontos, on 26 July 2012 - 04:02 PM, said:

Yes, it looks better with those small holes. I have found 355 bricks, that have that "pin" you mentioned (and asked for a hole in that pin), but I am pretty sure, not all of them should have the pin with hole. Some of them should have the pin without the hole. To be honest, I did not tried to sort them out, because it probably means to look at each physical brick. I am not sure if Bricklink can help, since images there are usually from the top and not from the bottom.

The general trend seems to be that new molds (not designID's, but physcial molds) have the hole, and older does not. Also, plates have them more often then bricks.

I suppose you can make into a choice in LDD2PovRay. To keep it simple, I propose you make it so that either you add to the hole to all pins/bricks, or to none.

[hrontos]

Superkalle, on 26 July 2012 - 04:39 PM, said:

I suppose you can make into a choice in LDD2PovRay. To keep it simple, I propose you make it so that either you add to the hole to all pins/bricks, or to none.

Yes, this is possible without problems, just how to name that checkbox.  
Everybody knows what is a stud, but I am not sure how to name that pin so that everybody knows what are we talking about. May be a small preview image of some default standard brick featuring all these details would be helpful for the user. As the user will change level of detail or activates this and similar checkboxes, preview image would change.

[hrontos]

This one already contains those holes (only on three bricks, but they are there).



1366x768, 1803x1014, 2732x1536

This is one of my favorite models. I think that for 7 years old boy this is a very nice toy, because it is a dinosaur, walking dinosaur, remote controled walking dinosaur and best of all it is a remote controled walking dinosaur made of LEGO so kids can build it themself. It not that much creator, may be more technic, but at least it shows, that technic does not necessarily means machine.

Edited by hrontos, 26 July 2012 - 06:20 PM.

[hrontos]

Version 1.2 released.

Change list:

• added new holes to the backside of some bricks as proposed by Superkalle - pin hole not configurable through gui yet
  
• corrected wrong shading of flex bricks as reported by bbqqq
  
• corrected bug in the reading of the default settings - output resolution was not read

[bbqqq]

Thanks for make this nice update so quick. The flex elements look much better now.
Version 1.2 the bevels of flex elements base still shown black? (middle one)

Edited by bbqqq, 02 September 2012 - 12:51 AM.

[hrontos]

bbqqq, on 28 July 2012 - 05:54 AM, said:

Version 1.2 the bevels of flex elements base still shown black? (middle one)

This problem actually appears also on the other parts and is related to the fact that some parts are modeled in LDD as not completely closed volumes. To illustrate what does it means imagine a new part that looks like three cubes joined together - middle cube is smaller. In the LDD such part is modeled as 2 bigger cubes and the middle cube is not modeled as a cube, because it has only 4 wall visible. In LDD geometry those 2 invisble walls are omitted and the middle cube has only 4 walls. POV-Ray treats this cube as empty (as having only "paper" walls) and not as solid (filled) object. When such part is beveled and sharp edge is removed, what you get is exactly the same as in case of paper cube - a hole into empty cube. Technic 2M Axle Notched is modeled this way.

One some parts this issue can be elminated by specifying different inside vector. Inside vector is used by POV-Ray to check what is inside of a shape and what is outside - for a given point within shape it calculates number of walls crossed by this vector - even number of crossed walls means outside, odd number means inside (like shooting a bullet - when bullet goes through first wall, it is inside, when second, it is outside). In case of those 3 cubes, when inside vector goes in direction from first to third cube it obviously returns to POV-Ray that when reaching second cube, even number of walls was crossed (only the 2 walls of the first cube) so inside of the second cube is outside from the POV-Ray point of view. If the inside vector was perpendicular to the previously mentioned one, number of walls crossed (intersected) by this vector would be correct and whole shape, all cubes would be treated as completelly closed volume.

I will try to specify manually inside vector for most commonly used bricks having this problem. As far as I know, from commonly used bricks the technic beams have this problem.

If you want to test this POV-Ray behavior modify ldd_inside_vector. #declare ldd_inside_vector = <0,0,1>; is the current declaration.

For some parts disabled beveling or manual modelling will be the only solution.

Edited by hrontos, 28 July 2012 - 09:55 AM.

[Phoxtane]

Wow! I actually got this working with a little trouble. It helps if you have the latest PovRay beta...

I'm experiencing a case of "The little 2.4 gHz quad-core that could", so this will take a little while.

EDIT: Darn. I'm not going to be able to run it, not with my motherboard temperatures hitting 75.5 C (168 deg. F)!

Edited by Phoxtane, 29 July 2012 - 02:52 AM.

[hrontos]

Phoxtane, on 29 July 2012 - 02:27 AM, said:

Wow! I actually got this working with a little trouble. It helps if you have the latest PovRay beta...

I'm experiencing a case of "The little 2.4 gHz quad-core that could", so this will take a little while.

EDIT: Darn. I'm not going to be able to run it, not with my motherboard temperatures hitting 75.5 C (168 deg. F)!

I had similar problem with rendering on a notebook. During hot days CPU was more than 85 degC (185degF) and I started experiencing sudden shutdowns.

There are some ways how to resolve it:

1. Limit number of parallel rendering threads in POV-Ray. This can be done by adding line "Work_Threads=n" to the generated INI file or +WTn switch to the command line textbox (it is located in POV-Ray's main screen right bellow Queue toolbar button, next to the resolution selection combo box). "n" is the maximum number of parallel threads. Try number of cores detected by windows - 1.

2. Second option in Windows 7 is to go to the Power Management. In the Advanced settings of the power plan there is a section dedicated to CPU. And there is one value named "Maximum CPU State" (or similar, I do not have English version of Win7). This one contains some percentage value - usually 100%. Decrease it to 90% or 85%. This value decreases maximum CPU frequency. 90% worked fine for me and saved me 10 degC (from 85C to 75C).

This second approach seems to provide more "finer" settings, but has an influence also on other applications, not only POV-Ray.

[Phoxtane]

hrontos, on 29 July 2012 - 10:34 AM, said:

There are some ways how to resolve it:

1. Limit number of parallel rendering threads in POV-Ray. This can be done by adding line "Work_Threads=n" to the generated INI file or +WTn switch to the command line textbox (it is located in POV-Ray's main screen right bellow Queue toolbar button, next to the resolution selection combo box). "n" is the maximum number of parallel threads. Try number of cores detected by windows - 1.

That'd be another line added to the .INI file, underneath the one that's had to be added to get LDD to work with POV-Ray, yes? "N" would also equal the amount of threads that POV-Ray is actually using as well? In that case, I'm probably going to limit it to one thread - one core, no hyperthreading - and have it work in the background.

Thanks!