USER FORUM
(you are viewing a thread; or go back to list of threads)
group valB valC redudant storage (by cmpxchg)
While reviewing and trying to understand the various forms or extrusion and their properties, I came across this artifact.
In file.cpp line 97 group properties double valB and double valC both map to class member valB, and according to git line history, it is already this way since 2008.
valB should only be used by helixes, and valC does not seem to be in use in current code. However, if the order of write- and readback changes and there are different values, it can lead to problems.
Is there a reason to store it this way, like historical file format usage or group.cpp code ?
In file.cpp line 97 group properties double valB and double valC both map to class member valB, and according to git line history, it is already this way since 2008.
valB should only be used by helixes, and valC does not seem to be in use in current code. However, if the order of write- and readback changes and there are different values, it can lead to problems.
Is there a reason to store it this way, like historical file format usage or group.cpp code ?
(no subject) (by Paul)
@cmpxchg
I see you've found that the entities don't use polymorphism, but just stuff their data in the same generic members. This was handy when I implemented Revolve and Helix groups with new entity copy-types, as there were NO changes needed for the file I/O code. It obviously has some drawbacks as well.
It might be beneficial to make a table indicating which members are used for each thing. Like documentation ;-)
IIRC for Helix I think valB is used for the pitch parameter. I chose valB because I had previously experimented with some other options on extrusions that used valA and thought some day we might want to apply that to Helix, so used valB for the pitch.
The doubling you mention is interesting to me. In rotate groups the angle between instances is stored as 1/4 of the expected value. In other words, when you create a step-rotating group which defaults to 3 copies, the angle is set to 30 degrees which somehow ends up being 120 degrees. The same entity copy-type is used in the Revolve code, so it's also set to 30 degrees (or radian equivalent I don't recall) to get the default 120 degree section. Part of this is because rotate is applied N times, where N is an integer. In a double-sided group we use +/-1 and a single-sided we use 0 and 2 for the times-applied. Or something like that, but it explains why an angle might be 1/2 the value you might think. I never figured out why it's 1/4 though.
Extrusion groups also have times applied set to either (0 and 2) or (1 and -1) depending on that checkbox.
I don't know if any of this comment helps you, I'm just sharing some stuff I found and did in related areas.
AFAICT all older files can be opened in newer versions of solvespace. I'm aware of one exception where some constraints on an old lathe group might fail in later versions because redundant entites were removed / are no longer created. There have been zero complaints about it though.
I see you've found that the entities don't use polymorphism, but just stuff their data in the same generic members. This was handy when I implemented Revolve and Helix groups with new entity copy-types, as there were NO changes needed for the file I/O code. It obviously has some drawbacks as well.
It might be beneficial to make a table indicating which members are used for each thing. Like documentation ;-)
IIRC for Helix I think valB is used for the pitch parameter. I chose valB because I had previously experimented with some other options on extrusions that used valA and thought some day we might want to apply that to Helix, so used valB for the pitch.
The doubling you mention is interesting to me. In rotate groups the angle between instances is stored as 1/4 of the expected value. In other words, when you create a step-rotating group which defaults to 3 copies, the angle is set to 30 degrees which somehow ends up being 120 degrees. The same entity copy-type is used in the Revolve code, so it's also set to 30 degrees (or radian equivalent I don't recall) to get the default 120 degree section. Part of this is because rotate is applied N times, where N is an integer. In a double-sided group we use +/-1 and a single-sided we use 0 and 2 for the times-applied. Or something like that, but it explains why an angle might be 1/2 the value you might think. I never figured out why it's 1/4 though.
Extrusion groups also have times applied set to either (0 and 2) or (1 and -1) depending on that checkbox.
I don't know if any of this comment helps you, I'm just sharing some stuff I found and did in related areas.
AFAICT all older files can be opened in newer versions of solvespace. I'm aware of one exception where some constraints on an old lathe group might fail in later versions because redundant entites were removed / are no longer created. There have been zero complaints about it though.
documentation (by cmpxchg)
Yes, more hi-level sourcecode concept-documentation would be very welcome!
Please avoid peppering docs everywhere in the well-readable sourcecode - nor the doxygen hell...
From my own experience, writing the higher-level documentation can also trigger some source-code self-review (intent and outcome are not always aligned, form follows function) and can provide ideas for new changes or hi-level approaches.
To create 3D objects from a 2D shape, what is theoretically all possible and practical ? What would be the limitations ? (precision, accuracy, speed, editability of subsequent/linked objects etc).
I wonder if there are floating point issues or other numeric limitations in the stacked-group model too.
Right now I am learning by example - I set to want to make a 110 and 70 degree 8-sided object from frustum-extruded triangles and irregular hexagons. I could not find the right mathematical name for the shape - is there one ?
I was able to approach the shape, but I could not make it look perfect, nor do I get a perfect, no-repair required. sliceable STL file out of it. I have to fix the size of the 2nd face first, it is generated but not always aligned.
Please avoid peppering docs everywhere in the well-readable sourcecode - nor the doxygen hell...
From my own experience, writing the higher-level documentation can also trigger some source-code self-review (intent and outcome are not always aligned, form follows function) and can provide ideas for new changes or hi-level approaches.
To create 3D objects from a 2D shape, what is theoretically all possible and practical ? What would be the limitations ? (precision, accuracy, speed, editability of subsequent/linked objects etc).
I wonder if there are floating point issues or other numeric limitations in the stacked-group model too.
Right now I am learning by example - I set to want to make a 110 and 70 degree 8-sided object from frustum-extruded triangles and irregular hexagons. I could not find the right mathematical name for the shape - is there one ?
I was able to approach the shape, but I could not make it look perfect, nor do I get a perfect, no-repair required. sliceable STL file out of it. I have to fix the size of the 2nd face first, it is generated but not always aligned.
Truncated tetrahedron (by cmpxchg)
(no subject) (by cmpxchg)
When drawing the tetrahedron in 3D space as dots and lines, selecting them and constraining them to a new plane, or workplane, would be a great feature.
Is there also a hierarchy of planes, for example, created by the order of groups in a slvs file ?
Is there also a hierarchy of planes, for example, created by the order of groups in a slvs file ?
Post a reply to this comment: