Tips on improving techdraw performance

[freedman]

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]

You multiply with 10^6*10^6, so you should divide by that too.

[wandererfan]

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.

[yorik]

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 (160.48 KiB) Viewed 937 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...

[wandererfan]

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.

[yorik]

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...

[vanuan]

Maybe this should be split into 2 properties:

Display: Wireframe / Solid
SVG engine: Coin / Open Cascade

Also, some properties are not supported in both engines.
An example: https://forum.freecadweb.org/viewtopic.php?f=35&t=48263

I'm wondering, how can we disable properties that are not used by Coin.

Also, for smaller models, Coin seems to be slower, as it opens a new window and closes it immediately. Is there a way to get Coin SVG offscreen?