kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Yeah, I'll test on a bunch of different systems. It'll take me a couple days,
but I'm sure Wayne won't be finished evaluating it by then either. ^_^

Don't commit my patch, it's broken. I'll send in another one, the one I sent
before only works on Linux.

On Tue, Jun 14, 2016 at 11:00:08PM +0000, Mário Luzeiro wrote:
> 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.