Pov-Ray rendering transparent bricks slowly (LDD to POV-Ray)

[ziebelje]

So I'm starting to play with rendering with POV-Ray. It's working really great, but I just tried to render a model with a transparent brick (87081 Brick 4x4 Round) and it took FOREVER. I can do things to help speed it up like turn off radiosity, crank the resolution down, etc but with those features off I can't get the effect I want.

I'm comfortable editing the .pov file manually but I'm having a tough time figuring out what might help. Has anyone dealt with this before?

I attached an example render (radiosity off, 960x540) to give you an idea. That render took 10 minutes. I can render the exact same model with the exact same settings with the transparent part replaced in 2 minutes. With the quality settings I want it takes hours to run and then just seems to get stuck on the transparent part.

Thanks!

[Darats]

Nothing wrong.

 

It is much longer to render transparent parts on PovRay due to more complicated calculations needed.

[ziebelje]

Yeah, the more I researched the more I came to that conclusion. I found some helpful tricks to speed up the rendering but my goal is to render a 300 frame rotation. No matter what shortcuts I use, the render is still going to take weeks at best. I'll just have to admit defeat on this one until I have time to explore some other options.

[roland]

10 minutes for non radiosity at that resolution is extremely slow indeed, I've done renderings at UHD in that time of much larger scenes (LDraw source though).

I expect the geometry is defined inefficient and or at a very high quality level which in turn makes the parsing stage (which is single threaded) the biggest time consumer.

If so you might decrease the overall rendering time of all 300 frames by using a single .pov with an animation for the rotation.

You could also play around with settings like max_trace_level and such.

[ziebelje]

Changing some of the settings like max_trace_level helped but at the point when it got fast enough the quality was too low.

I think I am already doing what you're suggesting for the 300 frames, although maybe there are other optimizations I can make? In order to do my render, I'm using LDD to POV-Ray to export the geometry. Then I edit the INI file to include a clock and the POV file to move the camera around the object. POV-Ray then exports each frame as it's own file.

The only thing I couldn't figure out how to do is rotate the actual geometry...it's all sort of encapsulated so the only way I could figure out how to get rotation was to move the camera around.

Besides that, are there any other optimizations I can make that would "cache" render data between frames? I don't know enough about the math behind this to have any educated guess here.

Edited January 27, 2017 by ziebelje

[roland]

As far I know moving the camera is the preferred method for whole scene rotations.

Have you tried the predefined radiosity setting macros defined in rad_def.inc?

[ziebelje]

I've just been using the different radiosity settings defined in LDD to POV-Ray. Those all spit out a bunch of custom settings so I don't think they're using any POV-Ray defaults. I can try to see if I can figure that out.

Side-note: I see that you wrote your own LEGO CAD program. I only have experience with LDD but given the lack of official support do you have any recommendations? I understand you'll be a bit biased but I also expect you know better than anyone what's out there. I enjoy building LEGO in a CAD application somewhat, but I mostly enjoy the satisfaction of photo-realistic renders.

[roland]

4 hours ago, ziebelje said:

Side-note: I see that you wrote your own LEGO CAD program. I only have experience with LDD but given the lack of official support do you have any recommendations? I understand you'll be a bit biased but I also expect you know better than anyone what's out there. I enjoy building LEGO in a CAD application somewhat, but I mostly enjoy the satisfaction of photo-realistic renders.

It basiclly boils down to 3 camps:

LDD:  easy to use but limited.

LDraw: Open platform, very big part library, multiple editors/tools to choose from.

mecabricks: easy to use webapp

 

As for rendering LDD POV-Export is very HQ (hence the slow rendering), but you can get similar results with LDraw and mecabricks given you take the time to learn all the tools/libraries (e.g. LDraw's LGEO) involved.

And the editor, I might be bias indeed but in the end it comes down to a personal preference as no single editor could ever please everyone (I gave up on that along time ago :) ). My LDCad, for example, is aimed at the more advanced/experianced LDraw user looking to make instructions or very large models. The results in a steep learning curve which is the complete opposite of LDD. But there are other LDraw editors like Leocad, SR3DBuilder, MLCad and the new stud.io all have their own pros and cons.

my 2cts

Edited January 28, 2017 by roland

[ziebelje]

Thanks, that helps!

[Wojtasz78]

Look in this topic:

 

[ziebelje]

Thanks! I did actually see that. The only problem is that I would have to write a script to do that work since I want to render 300 frames and then combine them into a gif. I was hoping I had missed something obvious and that there would be some alternative without requiring all that effort. :)

[JGuy]

On 1/28/2017 at 8:28 PM, ziebelje said:

Thanks! I did actually see that. The only problem is that I would have to write a script to do that work since I want to render 300 frames and then combine them into a gif. I was hoping I had missed something obvious and that there would be some alternative without requiring all that effort. :)

I don't mean to answer a question that has already been answered, but have you considered using Bluerender instead of POV-RAY?  Bluerender takes no time at all and usually has about the same quality, if not better than POV-RAY.  It does not have as many options as POVRAY but it will render much faster!