kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

Hi Chris,

Thanks for this feedback.
I got very few feedback from this list during the development, so now I expect that there maybe things that need to be changed. That is another reason that I do not want to advance much more on any possible direction that may not be well accepted and I would like to hear more from you all.

> You could also add a "raytrace" button to the toolbar to raytrace an individual view, and revert to GL when the view is moved again.

This is already implemented:
Set the target mode in OpenGL, then there is a blue cube icon "Render current view using Raytracing" (below the "Preferences")
If you move again it will back in OpenGL mode, you then can press the icon again to render another view.


> 2) The raytracer is REALLY slow on clang builds. Takes about 10-20secs to
> render with gcc, and about 20 MINUTES with clang.

Raytracing is a natural slow algorithm.
On a proper render engine with all kind of physical features, it can take minutes ..to hours to finish to render a single image.

However, I developed a basic features and hacked raytracing, on the computers I tested, I can get almost 20 fps on Raytracing mode (preview, while moving the mouse) and it took 3.. 4 seconds to perform the final render.
However, that 10..20s I expect it on complex scenes on few cores CPU.

If you experienced that long times, I can suspect 3 possible things:
- Incredible complex board with lots of 3d models, or
- For some reason the compiler is not build using OpenMP, or
- You have one or very few cores available on your CPU :/

You can also try to play with the render options see how much difference it makes for you.


On relation to my Raytracing implementation, it is using two "state of art" algorithms for tracing the rays.
I am myself amazed with the performance improve of this algorithms. (You may find the references and credits on my source code where I got this algorithms or based my implementation).

There is one big room for optimization that would be to implement it using SIMD instructions (SSE) but I am not capable of that. It will need some huge refactor on the raytracing and I think it will be too much.


I believe your suggestions on 3A can be evaluated. Some of that similar ideas I thought about it before, but it may need some one more experienced on wxWidgets as it will need to deal with parallel stuff, the openMP it self and widget updates.
On that subject, my current implementation was the quickest route I found to get something work, it may be easier now to transform it on something else.

Would be possible to you to build it / test on different systems?

.. I will look on your patch latter and commit.
Thanks!
Mario

________________________________________
From: Chris Pavlina [pavlina.chris@xxxxxxxxx]
Sent: 14 June 2016 20:15
To: Mário Luzeiro
Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx; stambaughw@xxxxxxxxx
Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

Few comments from a quick initial test:

1) The attached patch is required to build on at least clang+Linux. Probably
other platforms as well. Also tested on gcc+Linux to verify fixing clang
doesn't break gcc.

2) The raytracer is REALLY slow on clang builds. Takes about 10-20secs to
render with gcc, and about 20 MINUTES with clang. At least OSX depends on
clang, so this should probably be investigated. (Still haven't tested on OSX
though, I'll do that later).

3) Even at the faster speed, the raytracer is too slow and unresponsive. This
doesn't stop a merge for me, I'd be okay with merging it as long as this will
be fixed in the future. But I'd like to see one of the following changes made:

3A) Raytracer UI responsiveness improvements. Allow the user to start dragging
the PCB around even after the render has started, rather than going completely
frozen during the render. Also, continue responding to redraw events even if
you don't have anything to draw yet - just redrawing the old image would work -
as without that, the window displays graphical garbage if anything has been
dragged over the top, giving the impression that it's broken/stalled.

3B) Raytracer becomes an noninteractive output engine only. Use OpenGL for the
interactive view, and have an export option to use the raytracer to generate a
high-quality view. You could also add a "raytrace" button to the toolbar to
raytrace an individual view, and revert to GL when the view is moved again.

I haven't had a segfault yet.