Tips on improving techdraw performance

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
freedman
Posts: 1023
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Tips on improving techdraw performance

Postby freedman » Sat Aug 24, 2019 2:22 am

After you get a correct scale could you build ( in math only)an SVG page (x*1million) x (y*1million), apply points then scale the SVG back down. I had to do that with a limited resource micro-controller. I read in float, remove the decimal point ( keep track where it was) and make the entire number Longs, do the math and then put the decimal point back in and transmit the data. In essence multiply 10^6 to get whole numbers, do the math, divide 10^6.
chrisb
Posts: 19540
Joined: Tue Mar 17, 2015 9:14 am

Re: Tips on improving techdraw performance

Postby chrisb » Sat Aug 24, 2019 6:41 am

You multiply with 10^6*10^6, so you should divide by that too.
User avatar
wandererfan
Posts: 3145
Joined: Tue Nov 06, 2012 5:42 pm

Re: Tips on improving techdraw performance

Postby wandererfan » Sat Aug 24, 2019 6:26 pm

yorik wrote:
Fri Aug 23, 2019 10:09 pm
What do you think would be needed to have such cosmetic points system on a TD ArchView @wandererfan? Also there would likely be many for a single view. Maybe all TD views could gain a property that holds such points? (CosmeticPoints?)
TD ArchView would have to gain a "layer" or "overlay" to hold the cosmetics. The layer would mostly reuse the drawing code in DrawViewPart, etc to display the cosmetics.

The overlay concept has been on the todo list for a while, but until recently (with the cosmetic stuff) there was nothing to put on the overlay so it didn't get worked on.

The thought was that any View could have an overlay applied to it.

Don't have an ETA.
User avatar
yorik
Site Admin
Posts: 11574
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Tips on improving techdraw performance

Postby yorik » Sat Aug 24, 2019 10:53 pm

wandererfan wrote:
Sat Aug 24, 2019 6:26 pm
Don't have an ETA.
No worries, it's done when it's done :) We already have stuff to play with regardless...

In git commit ed0eff0248 I added another mode called "Coin mono" that is essentially the same, but changes all the face colors to white:
Screenshot from 2019-08-24 19-40-23.png
Screenshot from 2019-08-24 19-40-23.png (160.48 KiB) Viewed 198 times
The main problem I still have is that coin spits out triangles and lines in "more or less" the same order as they appear on screen, which produces a more or less good SVG, but not completely. Some faces go above some lines, which hides them partially. In the section view above you can see that some lines are thinner than they should, which is an effect of that. I'm not sure how or if it's even possible to solve...

There are still some crashes too that I must investigate further...
User avatar
wandererfan
Posts: 3145
Joined: Tue Nov 06, 2012 5:42 pm

Re: Tips on improving techdraw performance

Postby wandererfan » Mon Aug 26, 2019 1:41 pm

yorik wrote:
Sat Aug 24, 2019 10:53 pm
PR2455 might be of interest. It doesn't do much on its own, but now we can change the callers to specify output size, background y/n, and line width.
User avatar
yorik
Site Admin
Posts: 11574
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Tips on improving techdraw performance

Postby yorik » Mon Aug 26, 2019 2:04 pm

great! That will simplify already the code in Arch. Thanks!
I really think this can become a powerful feature...

Two features I feel are missing, but will be hard to get: 1) transparency, but it's not supported by coin's vectorize action... So only if we implement that ourselves. Or find a workaround somehow. and 2) display cut lines. Unfortunately there too it depends on coin's clip plane, which just cuts through lines and triangles, with no calculation of new lines where the triangles are clipped. Calculating that ourselves with booleans would slow everything down, so we definitely don't want that. No idea at the moment...

I had a better look at simvoleon too, but unfortunately its volumetric rendering capabilities depend on voxels. It would be of no use in this case, as it wouldn't calculate cut lines between the clip plane and the triangles.

But once we are working with triangles only, maybe we have some much faster algorithms than OCC booleans to calculate intersections? There migth be something there...