Sketcher grid : fundamental change
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
Sketcher grid : fundamental change
Current grid is drawn as a static 3D object centered on the sketch origin.
This brings a lot of issues which has been handled by complex code and gives suboptimal behaviours :
- The area covered by the grid is defined by default at 100 x 100.
- So the grid does not cover the whole view.
- So if you want to use a small grid size, it will create a LOT of lines.
- So there is a 'Maximum line' property of 10 000 that some users have to increase in some cases. So in some case people end up drawing 10 000+ lines. Which is more than the number of pixel lines of a 4k display.
- The grid needs to be resized when user draw geometry outside of the current grid.
On top of that we have several weird properties :
- 'Tight Grid' property which wiki doesn't explain correctly. It kind of just resize grid area. I guess this is an attempt to mitigate the 10k line issue.
- 'Auto Grid Size' property, which is a hidden property that you probably never heard of. It's resizing the grid area (not grid size) around current geometries. I guess that this is also an attempt to fix the 10k lines issue and the fact that grid area does not cover the whole view. But it's half cooked (it requires restart of sketch to update), which explain why it's hidden I guess.
All of those problems come from a basic architecture issue: the grid should not be a 3D object with fixed dimensions. It should be a visual object drawn dynamically to cover the camera view.
This would solve all problem and simplify the code at the same time:
- Grid would cover the whole viewer area all the time.
- Any grid size would be usable.
- There wouldn't be more than 1000 lines in the most extrem cases.
- No grid resizing required depending on sketch content.
The 'downsides' are that we would delete (and I know people don't like that word) :
- 'tight grid' 'auto grid resize' as they would become useless.
- 'view grid outside edit mode'. As the grid would be generated based on camera, keeping this option means that the grid that would be shown would be the last grid shown by camera. So most likely weird. Anyway this property sounds like a workaround way of creating a grid object. But this is wrong to keep a bad static grid for a edge case where someone want to create a grid object. If we really need that let's just create a 'grid object' tool in the appropriate workbench...
Please let me know your thoughts @abdullah, @uwestoehr, @wmayer (who's already reviewing the grid PR, I'm not just pinging all mergers ) and all other people interested of course.
This brings a lot of issues which has been handled by complex code and gives suboptimal behaviours :
- The area covered by the grid is defined by default at 100 x 100.
- So the grid does not cover the whole view.
- So if you want to use a small grid size, it will create a LOT of lines.
- So there is a 'Maximum line' property of 10 000 that some users have to increase in some cases. So in some case people end up drawing 10 000+ lines. Which is more than the number of pixel lines of a 4k display.
- The grid needs to be resized when user draw geometry outside of the current grid.
On top of that we have several weird properties :
- 'Tight Grid' property which wiki doesn't explain correctly. It kind of just resize grid area. I guess this is an attempt to mitigate the 10k line issue.
- 'Auto Grid Size' property, which is a hidden property that you probably never heard of. It's resizing the grid area (not grid size) around current geometries. I guess that this is also an attempt to fix the 10k lines issue and the fact that grid area does not cover the whole view. But it's half cooked (it requires restart of sketch to update), which explain why it's hidden I guess.
All of those problems come from a basic architecture issue: the grid should not be a 3D object with fixed dimensions. It should be a visual object drawn dynamically to cover the camera view.
This would solve all problem and simplify the code at the same time:
- Grid would cover the whole viewer area all the time.
- Any grid size would be usable.
- There wouldn't be more than 1000 lines in the most extrem cases.
- No grid resizing required depending on sketch content.
The 'downsides' are that we would delete (and I know people don't like that word) :
- 'tight grid' 'auto grid resize' as they would become useless.
- 'view grid outside edit mode'. As the grid would be generated based on camera, keeping this option means that the grid that would be shown would be the last grid shown by camera. So most likely weird. Anyway this property sounds like a workaround way of creating a grid object. But this is wrong to keep a bad static grid for a edge case where someone want to create a grid object. If we really need that let's just create a 'grid object' tool in the appropriate workbench...
Please let me know your thoughts @abdullah, @uwestoehr, @wmayer (who's already reviewing the grid PR, I'm not just pinging all mergers ) and all other people interested of course.
Last edited by paddle on Mon Nov 14, 2022 7:20 pm, edited 2 times in total.
Support me on Patreon: https://www.patreon.com/FreeCadDevDiary
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
Re: Sketcher grid : fundamental change
Does this mean that the grid is always normal to the viewing direction? That would be a very serious change of its meaning.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Sketcher grid : fundamental change
No that would be weird.
The grid would always be on the sketch plane as it is. It's just that we would draw only the lines that falls on the camera view.
Technically it would work by projecting the 4 corners of the camera on the sketch plane. Then get those 4 points coordinates. Get the minX minY, maxX maxY of those points, and draw lines falling between those values.
The grid would have to be redrawn when user moves the camera. In order to avoid too many redraw, only on zoom and on panning when user release click.
Support me on Patreon: https://www.patreon.com/FreeCadDevDiary
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
Re: Sketcher grid : fundamental change
I'm roughly OK with the problem description, but I don't really share solution/conclusion.
To me, the root cause (following your rationale) is that "the current grid, brought by VP2DObjectGrid, as part of the object in not well suited to Sketcher needs".
So my conclusion/solution would be "drop the current use of the grid made by the Sketcher, and let's code a new appropriate one dedicated to this (into VPSketch)".
To me, the root cause (following your rationale) is that "the current grid, brought by VP2DObjectGrid, as part of the object in not well suited to Sketcher needs".
So my conclusion/solution would be "drop the current use of the grid made by the Sketcher, and let's code a new appropriate one dedicated to this (into VPSketch)".
Re: Sketcher grid : fundamental change
I doubt these 2 statements can be true at the same time. Just imagine when you look at your sketch from a very skewed view, especially in perspective mode.
Re: Sketcher grid : fundamental change
Just to be sure I got what you meant: We create a new class grid that we put in VPSketch and leave the old one untouched in Part.
This is even better imo.
You are right. I thought cover the full area when camera is not too skewed. Finding a good middle ground between number of line and covering the viewer when camera is rotated a little.
Last edited by paddle on Mon Nov 14, 2022 3:32 pm, edited 1 time in total.
Support me on Patreon: https://www.patreon.com/FreeCadDevDiary
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
Re: Sketcher grid : fundamental change
Correct except you don't (necessarily) need a new class. You can if it helps of course.
But yes, push everything about (Sketcher) grid to VPSketch, and make it the ultimate sketching grid ever.
Re: Sketcher grid : fundamental change
Hello, not a technical discussion from my side as this surpass my knowledge.
Some reflections, from an user perspective.
If grid is only an aid, I think that the risk of breaking something is related maybe to the "UI experience".
If the new grid will behave more "correct" than before, I could immagine why one "old user" even "used to" the old behaviour would regret if something better is made.
Probably thinking of "making things better" speaking of "UI experience" is not a "big sin", there are no harm of "breaking compatibility" with "old files" or "old scripts an macro" (apart for some Macro or script that use grid).
The point is making some "constructive discussion" focused on "goals" before coding, so the result should be discussed among people that "know about the matter", if you foresee a change there will be always people that are against "changes" even if the change will lead to a "better thing".
Good work to all coders.
Regards
Carlo D.
Some reflections, from an user perspective.
If grid is only an aid, I think that the risk of breaking something is related maybe to the "UI experience".
If the new grid will behave more "correct" than before, I could immagine why one "old user" even "used to" the old behaviour would regret if something better is made.
Probably thinking of "making things better" speaking of "UI experience" is not a "big sin", there are no harm of "breaking compatibility" with "old files" or "old scripts an macro" (apart for some Macro or script that use grid).
The point is making some "constructive discussion" focused on "goals" before coding, so the result should be discussed among people that "know about the matter", if you foresee a change there will be always people that are against "changes" even if the change will lead to a "better thing".
Good work to all coders.
Regards
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Sketcher grid : fundamental change
For me the current grid is a workaround and the dynamic grid of your PR is that what I always wanted to have. See also issue #7223
Re: Sketcher grid : fundamental change
Great. I'll get that started then.wmayer wrote: ↑Mon Nov 14, 2022 4:36 pm For me the current grid is a workaround and the dynamic grid of your PR is that what I always wanted to have. See also issue #7223
One thing regarding your tip on github:
I wanted to ask some details :View3DInventorViewer::getDimensions() gives you the dimensions. Furthermore you need the position of the camera and project it onto the focal plane along its view direction. This projection point is the center of a rectangle with the above dimensions.
https://github.com/FreeCAD/FreeCAD/blob ... e.cpp#L356
- The focal plane is the same as sketch plane ? My question is, if camera is rotated, will the center be projected on the sketch plane?
From the code you linked, does that sounds correct to you to get the projected point? :
Code: Select all
SbVec3f direction;
cam->orientation.getValue().multVec(SbVec3f(0, 0, -1), direction);
SbVec3f camProjectionOnSketch = cam->position.getValue() + cam->focalDistance.getValue() * direction;
Support me on Patreon: https://www.patreon.com/FreeCadDevDiary
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA
FreeCad Dev Diary channel:[/b] https://www.youtube.com/channel/UCGMTmJ ... NiPSSEhBHA