You got that right!
Making Grid Useful
Forum rules
and Helpful information
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!
Also, be nice to others! Read the FreeCAD code of conduct!
Re: Making Grid Useful
"It is much harder to simplify than to complicate."
Joseph Kimble
Joseph Kimble
Re: Making Grid Useful
Indeed. The algorithm didn't have a bug, but the grid (global) size was overwritten just after by some automatic mechanism.
I made a fix proposal in PR 3783.
BTW @wmayer, I think there is a bug in the algorithm that compute the projected boundbox to determine the grid size.wmayer wrote:
See below how the values (real boundbox vs. projected one) are different (roughly half) for a sketch (while they should basically be same). I didn't investigate in the eventuality it could be a matter of seconds for you to fix that. But I can try to further help if needed.
Re: Making Grid Useful
I have briefly looked at the code but not yet tested. Is it right that GridAutoSize is a hidden property, the default value is true but then the ViewProviderSketch constructor overrides and sets it to false.
So by default the automatic grid computation is always off for every new sketch. Wouldn't it be better to add a parameter value so that the user can change it? The point is if the grid (cell) size is too small it can easily become a bottleneck for the rendering.
Re: Making Grid Useful
Btw, is this a screenshot of ddd? How does it behave performance-wise? Most of the time I was using the debugger of QtCreator but it can become very slow when trying to step through the code because (I think) it takes a lot of time to get the current values of the local variables.
I have found a little pure text-based debugger cgdb which basically is gdb plus a second window that shows the code. This works as good as the integrated debugger but is blazing fast.
I have found a little pure text-based debugger cgdb which basically is gdb plus a second window that shows the code. This works as good as the integrated debugger but is blazing fast.
Re: Making Grid Useful
Looks like I have been unclear.wmayer wrote: ↑Thu Aug 06, 2020 6:32 pm I have briefly looked at the code but not yet tested. Is it right that GridAutoSize is a hidden property, the default value is true but then the ViewProviderSketch constructor overrides and sets it to false.
So by default the automatic grid computation is always off for every new sketch. Wouldn't it be better to add a parameter value so that the user can change it? The point is if the grid (cell) size is too small it can easily become a bottleneck for the rendering.
No problem about the PR itself. I know there are a lot pending and just feel free to review it whenever you want. I think somebody as abdullah can also do it.
I'll however explain it a bit.
Currently (before PR), Sketcher already has a mechanism to compute its wanted global grid size. It basically displays a grid that is twice larger the boundbox of the existing elements, which seems sensible wrt sketcher usage. It is roughly located here.
It works well by itself. The problem is that after the sketch is updated (elements moved/added/removed), immediately after the Sketcher ViewProvider computed the wanted grid size, the base class 2DObject ViewProvider receives an updateData call of 'Shape' type, and thus computes a new grid size (based on boundbox) that overrides the one computed by Sketcher.
I could have overloaded 'updateData' in ViewProviderSketch, but I found it better to introduce a new property 'GridAutoSize' in ViewProvider2DObject. It defaults to True so native behavior is unchanged (this will be transparent for derived classes), but a subclass can set it to False to indicate that it manages the grid size by itself. What I have done in Sketcher. The property is indeed hidden because IMO, this is more an application property than a user one. The behavior you describes in the one I expect. Sorry for long text.
Now what I want to catch your attention on (and was the purpose of the ping). While investigating on the above behavior, I found that there is maybe a flaw in the existing implementation of the existing mechanism in ViewProvider2DObject that tailors the global grid size according the bounding box of the shape. With a sketch (basically a 2D object whose placement is normal to itself), the projected boundbox should be the same as the natural boundbox. In the screenshot above, you can see it's definitely not the case. the natural bounding box 'bbox' is correct, but the projected one 'bbox2d' is totally wrong -- and weird --(almost half but not really). As told, I didn't investigate further ATM but can do it if needed (without any warranty of success).
Re: Making Grid Useful
Yep, this is DDD. About performance, I'll be carefull because :wmayer wrote: ↑Thu Aug 06, 2020 6:39 pm Btw, is this a screenshot of ddd? How does it behave performance-wise? Most of the time I was using the debugger of QtCreator but it can become very slow when trying to step through the code because (I think) it takes a lot of time to get the current values of the local variables.
I have found a little pure text-based debugger cgdb which basically is gdb plus a second window that shows the code. This works as good as the integrated debugger but is blazing fast.
- I don't think I use it in a same complex way as you can do
- My computer runs on an old tired P6100 processor with only 2GB shared memory (I hardly can open FC project in KDevelop without anything else running, and full compiling of FC takes between 6.5 and 7 hours with the 2 cores...)
- I never tried to display a very big amount of variables
What I like in DDD is that it's reliable, brings a layer of usability when you're not a daily gdb user, and I really like the scriptable breakpoints.
You can see an example of where this latter ability is really cool in this post. It was about debugging a problem that reveals on mouse movements. With scriptable BP, you can automatically breakpoint a line, update the display of a/some variable(s) and continue running. So you can move the mouse over FC window till you get the event you want, which won't be doable if you have to leave the window and set focus on another one to continue after breakpoint.
Back to your question, I'm happy with DDD performance.
Re: Making Grid Useful
This is not related directly to this discussion, but since you are touching the viewprovider of the Part Part2DObject, I ask anyway.
How hard would it be to move this 2D grid to a new viewprovider class?
The ViewProvider2DObject is not only used by Sketches but also by Draft objects; since this grid is defined here, Draft objects also have this internal grid although it is not used at all. We think this grid should be defined in the ViewProviderSketch, or in an intermediate viewprovider (or as an extension).
See this thread, Draft objects View Grid Properties.
Essentially, we could have an inheritance diagram like this.
Code: Select all
ViewProvider2DObject --> ViewProvider2DObjectGrid --> ViewProviderSketch
(Draft objects) (adds grid) (Sketches)
It's not urgent, and I was hoping to try my hand at the C++ code if I had time, but I don't have time to spare currently.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: Making Grid Useful
It once worked correctly in this context but now not anymore because the semantic of the class ViewProjMatrix has changed. With git commit 04faa8f4975 it also supports perspective projections and therefore the implementation has been changed to be compatible with the Coin3d implementation. The focus of ViewProjMatrix is to be used for projection onto a 2d viewport.
I will add a new class which behaves like ViewProjMatrix in the past.
Re: Making Grid Useful
The debugger in QtCreator does this automatically and I haven't found a way to avoid or limit them. If you want to debug a function with many variables it considerably slows-down the procedure.I never tried to display a very big amount of variables
I didn't know about this. Usually I do this with some logging statements.and I really like the scriptable breakpoints.
Re: Making Grid Useful
Thx fo information. It's a bit complex to understand the ViewProjMatrix class at a glance, but this is really interesting.wmayer wrote: ↑Fri Aug 07, 2020 11:02 am It once worked correctly in this context but now not anymore because the semantic of the class ViewProjMatrix has changed. With git commit 04faa8f4975 it also supports perspective projections and therefore the implementation has been changed to be compatible with the Coin3d implementation. The focus of ViewProjMatrix is to be used for projection onto a 2d viewport.
Saw you already added the new class & merged my PR. Many thanks.
Oppositely looks to me as if DDD absolutely don't care about variables that aren't displayed. It just get the value if needed so stays speedy.
Wahou. I guess logging variables updated on mouse move events can quickly generate a massive file.I didn't know about this. Usually I do this with some logging statements.
Actually the ViewProvider2DObject does nothing else that adding a grid (and its management) on top of ViewProviderPart.vocx wrote: ↑Fri Aug 07, 2020 12:44 am This is not related directly to this discussion, but since you are touching the viewprovider of the Part Part2DObject, I ask anyway.
How hard would it be to move this 2D grid to a new viewprovider class?
[...]
The internal grid doesn't cause any problems, it's just that to have a cleaner property editor, we would prefer if these grid properties aren't shown for Draft objects. We could manually hide these properties, but ideally they shouldn't be there in the first place.
So couldn't be a solution that Draft objects inherit ViewProviderPart instead of ViewProvider2DObject ?