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 [[email protected]] > Sent: 14 June 2016 20:15 > To: Mário Luzeiro > Cc: [email protected]; [email protected] > 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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
