Detect complete ray tracing 3D render

[TadeasPilar]

The new 3D render feature uses timeout to ensure ray tracing is done before saving the image. While this works, it is not very reliable.

Since there is apparently no way to tell when the render will be done, I figured monitoring cpu usage of the pcbnew process would work. I have tested this code, and it works really well:

    if cfg.ray_tracing:

        logger.info('Waiting for the final render')
        sleep(1)    #Give some time for render to start. Might not actually be needed.

        for process in  psutil.process_iter():
            if process.name() == "pcbnew":
                pcbnew_process = process
                break

        while pcbnew_process.cpu_percent(1) > 10:
            None

        logger.info('Done rendering')

I wouldn't call this "nice solution", but imho way better than just blindly waiting for a while and hoping for the best.

[TadeasPilar]

Update: Sometimes this doesn't work. I don't know why. I have tried running my project(22 renders) twice, and got total of 4 unfinished images(random).

[set-soft]

Hi @TadeasPilar !

Thanks for the idea!

I added an experimental command line option (-d) to do it. I tried it with a board and it works quite well. I was able to render the board in 4K resolution (took much more than 5 seconds).

Note that when using -d the value for -w is the time-out, so you can try -d -w 600.

I also added some debug information (try with -vvv) about the CPU usage and reduced the samplig period to 300 ms.

Things to try: may be you can skip 1 (or n) samples that show low usage. May be we should wait for 3 consecutive periods without CPU usage. As I didn't get a fail (yet) I can't try it.

[scottbez1]

Oh, nice, I just stumbled across the new 3d rendering support in KiAuto/KiBot - very excited! FWIW, I've been running a similar CPU-based raytracing completion detector for a while (https://github.com/scottbez1/splitflap/blob/1cfcab7fe7956f014bbae7bf124e8f598ea6750a/electronics/scripts/export_3d.py#L44-L55) and while I can't say I've looked at every single output image, I haven't noticed any early terminations or bad images in the several months I've had it in place, so I definitely think it's a worthwhile approach!

[set-soft]

I added a filter to the detection. I was able to reproduce the problem for complex boards with small zooms. In this case KiCad uses only 1 CPU for most of the render process, taking "10" (really 5, but with SMT) for small periods. In this case I see some periods of idle, in my machine they can be sampled upto too times with 300 ms intervals. The filter waits for 5 periods, so I think will solve the problems ... well at least most of the time. I'm closing this, if anyone sees a fail please open a new issue.