Taking another try at describing a French Curve or Fair Curve tool to use the current tools we have already defined.
The French Curve or Fair Curve tool will call the Curve - Interactive Points tool with predefined values.
This is similar to the ‘MidPoint’ tool which creates a ‘Point - On Line’ with the preset length (CurrentLength/2)
User inputs the points & desired curve shape:
Four points (p1, p2, p3, p4) of the two lines to connect with a curve
Curve shape of the 1st curve half and the 2nd curve half (flat, medium, or deep). The user can set the 1st half of curve to ‘flat’ and the 2nd half of curve to ‘deep’ if they wish to skew the curve towards the 2nd half like a French Curve tool, or other combinations as desired. Default is ‘medium’ which sets the control handle length to 1/3 the distance between the curve’s begin and end points. Setting both control handles to 1/3 distance creates what is called a ‘Fair Curve’. The user can tune this up after the curve’s initial creation, similar to updating the length parameter in the MidPoint tool.
The tool calculates:
D = Line_p2_p3 (distance between the curve’s begin and end points). Create this line if it doesn’t exist, dotted & hidden by default. This is a text string “Line_p2_p3”
Angle1 = AngleLine_p1_p2, and Angle2 = AngleLine_p4_p3. Create the lines if they don’t exist, dotted & hidden by default. This is a text string “AngleLine_p1_p2”
if flat Shape = (1/6), if medium Shape = (1/3), if deep Shape =(2/3). This is a text string “(1/3)”
Length1 = (D * Shape) and Length2 = (D * Shape) – this is a text string “(Line_p2_p3 * (1/3))”
The tool creates a “Curve - Interactive” Spl_p2_p3 with preset parameters (p1, Length1, Angle1, p2, Length2, Angle2).
Buenas noches. Gracias pero podrías por favor poner un paso a paso con texto e imágenes, porque este tema es fundamental y no lo sé hacer. Y como es nuevo para mi, aún con la descripción que haces no entiendo. Que pena. Quedo atenta. Muchas gracias.
Todavía se está programando. Nos están creando nuevas herramientas
para facilitarnos el trabajo. Estoy muy emocionada. Estoy seguro de que van a añadir un tutorial antes de que entre en la última versión.
Esta es una discusión sobre una herramienta futura propuesta.
Publiqué la descripción del algoritmo para asegurarme de que esta herramienta satisfaga las necesidades de nuestros usuarios y recopilar comentarios para mejorar.
This is a discussion about a proposed future tool.
I posted the description of the algorithm to make sure that this tool will meet our users’ needs and to gather feedback for improvement.
OR… a user selects a curve fom a list of stored curves (which are extracted from existing curves) and applied to a (new) curve. Like other systems do. The idea should be a tool that automates a process - not add another tool that requires a slew of more inputs. In fact - in video editing terms - it would be more of an “effect” preset rather than a new tool. Select a curve, apply a French Curve to it, and it sets the new curve’s tool properties… like the Midpoint tool does to the Point - On Line.
It might be worth considering, if you do decide to add a new tool, to make the tool allow having a “clipboard” where you can cut or copy from one .val file to a different .val file. If you had that, then it should be fairly easy to create a .val file which contains a “generic french curve” and make that available. Just a random thought
@douglas I can see how both approaches (yours with predefined curve profiles for specific use cases, and mine where users have total control over their curves and could add their own curve deginitions to your curve list) automate the curve definition process.
I don’t see our curve tool descriptions as exclusive or competitive, I see them as complimentary.
They are competitive… your talking a whole new tool (and all the coding that comes with it) , while I’m talking of a way to automatically fill out the fields of existing curves with presets… which the user still has total control over.
Possible, but would take custom clip and paste as there are no “curve” types for the clipboard.
BTW… I’m not proposing a new tool, but rather the ability to save and apply presets to existing curve tools. There’s no reason to reinvent the curve tools… just make it easier to use the existing ones. Again… just like the Midpoint tool - it’s NOT a new tool, but rather the Point- On Line tool with a preset length.
We may be able to bring other programmers on board for this. The curve profile list is a brilliant idea, and I’m all for it. My questions are:
Q1: Would curve profiles use the begin and end angles of the original curve, then adjust the control handle lengths? If not, how will they calculate the begin & end angles?
Q2: Wouldn’t the ability to auto-calculate the original curve’s begin & end angles at the time the curve is created be a time saver? Especially if the profile list is accessible from within the curve’s Properties dialog?
Consider the following suggestion that melds the two ideas to provide the same benefit as Midpoint Tool for the Curve Tools. The user can create responsive scalable curves quickly & easily without typing:
Auto Curve (simple) - User clicks 4 points (tangent point, begin point, end point, tangent point) and selects a profile. This auto-calculates the begin & end angles and control handle lengths and calls the Curve Tool. No fiddling with formulas required.
Auto Curve (spline) - User clicks 2 points (tangent point & begin point), the intermediate curve points, the last 2 points (end point & tangent point), selects a profile for each segment. The parameters are auto-calculated then calls the Spline Tool. Again, no fiddling with formulas required.
The Fair, Shallow, and Deep curve profiles are included in the profile list.
Users can add their own profiles to the list. Example: Not every sleeve cap will need the sleeve cap shape provided by our list. Our tools should enable users to speed up their custom workflow, which is a goal of this project. Similar to how players create custom Lua scripts of their attacks in Warcraft to improve their speed, accuracy, and precision while retaining their individual style of play.
In the proposals for new tools that facilitate complex sets of instructions, or automate certain tool definitions, I have the feeling that you are talking about extensions, or macros if you want. In principle, you could add these to the program in two different ways. Either you define them as new tools alongside the existing tools. This could easily lead to redundant code, as the operations can already be done with the existing tools. It could also clutter the GUI as the number of tools would rapidly grow. Alternatively, you could program them as extensions that translate the complex operations into a series of automatically parameterized elementary (existing) tools. The extension would then generate a number of lines in the *.val file, which can be processed with the existing parsing mechanisms and added to the pattern file. A disadvantage would be that the result will appear as a set of elementary operations that can only be edited afterwards at that level. However, the advantage would be that you separate the maintenance of the basic parser and elementary tools, from the development of diverse useful extensions. I would personally be in favour of this solution, as it will keep program maintenance more manageable.
Hey I just put the following info into bulleted groups to make them quicker to understand:
Avoid redundant code by following the rules for creating RISC chips: Create base functions then define complex functions by combining and calling the base functions. Increasingly complex functions can be defined upon the previous layers of base and complex functions. This method produces fast, efficient, maintainable code without redundancy.
Complex commands when defined outside the code base (example: using Lua script to call a series of Warcraft functions without performing any additional calculations to use as parameters) are referred to as macros or scripts. When they’re defined inside the code base they’re not typically referred to as macros, whether or not they perform additional calculations to use as parameters when calling base functions). Macros and scripts are typically written with interpreted languages, and the interpreted languages are typically much slower than the compiled code base.
Redundant code happens when programmers aren’t aware of the base functions and therefore don’t use them.
The GUI isn’t cluttered if the current tool organization structure is followed.
The proposed curve tools by definition “translate the complex operations into a series of automatically parameterized elementary (existing) tools.” They need to be in c++ for speed and maintenance, and they will call base functions. They will appear in the XML with their unique element tag and their parameters. The code uses these parameters to call the complex functions which make calculations and call the base functions with those calculations as parameters. This is current best practice followed by Inkscape in their c++ code base and by other design tools and software programs. These proposed curve tools are the powerful yet still simple tools that were in the TMTP prototype that haven’t been implemented yet in Seamly. These complex tools’ options and parameters will be user-editable via an Options or Properties dialog, exactly the same as current tools.
The goal is to create additional complex tools like the MidPoint tool in the code for Automatic Curve creation, Automatic Buttonhole/Button placement, Automatic Collar creation, Automatic Sleeve creation, for known common shapes for collars, sleeves, etc. These tools provide the user with a “quick-start” on these complex objects and the user can continue to work with them in Draft mode if desired, same as they currently work with Mirrored or Rotated objects.
Next Phase Development: Users will eventually have the ability to script their own custom macros of base tools and complex tools so they can speed up and replicate their own favorite way of using Seamly, and add their own special sauce including defining their own variations of sleeve, cuff, collar, placket, waistband, armor pieces, horse blankets, etc. (But this is for advanced users, they have to know how to use Seamly well before they can do this. We first need to provide some advanced capability for standard multi-step workflows that are accessible by every user as pre-defined tools distributed in the code base). It’s always been the goal to have customizable user workflows by enabling palettes of favorited tools and combined sequences of tools with customized settings, same as for any advanced design or gaming software. How these workflows are implemented, whether by enabling them as user-defined text files containing command names and parameters that are read by the code base’s API or as user-defined python or Lua scripts that run interpretively, is TBD.
@slspencer, I agree with most of what you write, but I am worried about these additional tags and their consequences for maintenance of the code. It means that with the addition of every super-tool, the parser, property editors and probably a lot of other dependent functions will have to be aware of the new tag and its consequences. Whereas, if the supertools would directly translate into a set of elementary operations, the core of the program could remain stable. This would facilitate the development of new tools (potentials are large, as is the diversity!) and facilitate maintenance and keeping the core intact. The disadvantage that you cannot redo the supertool could be offset by the advantage that you can edit properties finely, also outside of the parameter settings of the supertool. What would be needed in the code is an API where the new supertools can find information on the current pattern, and deliver their additions to be included in the pattern. Once done, the new objects would then become just a normal part of the pattern. If I were to develop one of the new supertools, I would prefer this much above having to chase all consequences of introducing a new tag. In fact, it should be possible to make a template for the new tools that can “easily” be modified into another cool new option.
Maybe we just need to update the current Curve - Interactive and Spline - Interactive tools, so we don’t need a new tag or function. Add P1 and P4 and the Profile drop down to the Properties dialog of the current tool. The P1 & P4 points and the Profile selection can be optional. Update the tag and function to accept these new parameters.
If P1 is null or empty, then Angle1 is entered by the user, no change from the current tool. P4 is processed same as P1.
If the Profile is null or empty, then the Control Handle lengths are entered by the user, no change from the current tool.
Question: for the Spline- Interactive would the profile apply to all segments?
Not neccessarily… what I proposed for a French Curve tool - just like the Midpoint tool - is a “preset”. There is no new (XML) tool, or addition (extension) to an existing tool… just a preset.
Depends… Again… using the Midpoint tool - the only addition in this tool is the icon and handler in the mainwindow, It simply presets the length for the Point - On Line tool.
Again… that depends. On how the GUI is (re)designed. Again using the Midpoint tool… there is no need for the Midpoint tool icon in the tool box and menus. We just need a Point - On Line tool, from which we can load presets.
The Midpoint tool is not an additonal, nor complex tool - it’s simply the Point - On Line with a “preset” length. I say this with the understanding that the app has a specific meaning to the term “tool”, and that is that a tool has a toolType and a toolId. There is no “midpoint” tool… it’s a point tool with a tooltype of “alongLine” with a length of “CurrentLength/2”. Which is why I don’t see a need for a new French Curve tool, but rather a means to save and load curve tool presets.
With that being said, I really wish RT had called “tools” - “objects”, and “objects” - “children” so that we could talk about “tools” (that have no properties) that operate on “objects” (that have properties) which may or may not have “children”.
Think ‘complex’ versus ‘base’. The base tools have to exist first before the complex tools can be created.
Complex only means that the tool is designed to be a quicker easier way to accomplish a common task. Complex tools calculate values (“presets”) then calls one or more existing tools with those values as parameters, which is what the Midpoint tool does.
Agee with all that. I’m all for that “Tool” definition… for example The Export Tool. There is no tool class for exporting… as exporting is basically a method to dump the current Qt scene. Problem though is in all the code naming - which in itself RT is not even consistent. < sigh >.
Also there is the additional “objects” that are children of the “tool” - such as in the Operation tools… the tool has an id, and the children objects each have an id - and in terms of the UI everything is a QGraphicsItem of sorts, so in the case of the Ops tools, the objects literally are children of the tool. That’s why I suggested “children”… or probably something more descriptive like “objectId” and “childObjectId”.
“Canvas”… I’d say No. We’re not a paint program. It should be called a “Workspace”… and remain in the code as the Qt term - “Scene”.
“Options”… Again I’d say no… Objects have properties… thus the change to the “Properties” context menu item, and the “Properties Editor” dock. For example… you HAVE to set a lineType attribute - it’s NOT an option. An option is for ex: “to not see this message box again check here”. And just to be complete… a Preference is a default option or property - such as the previous would be “unchecked” so as to show the 1st time through or a preferred lineType could be solid.
Just to be clear, when we write the manual and refer to lines and curves as ‘children’ it might not translate well.
Let’s consider the vocabulary to be viewpoint dependent, and terms appropriate for the developer may differ from the terms that help the user.
Tool, Scene, Children, and Properties make sense for the developer in any language and are known recognizable terms when developing with c++, Qt, and many other programming packages.
Tool, Canvas, Pattern Objects (or Objects), and Properties would make sense for our users and would translate well. AutoCAD names it’s working area as ‘Canvas’: Fusion 360 Help
para facilitarnos el trabajo. Estoy muy emocionada. Estoy seguro de que van a añadir un tutorial antes de que entre en la última versión.
