@dalelear , is it possible to use all the “output” from one command as “input” to the next command using history?
For example, intersect a plane and torus with history=on, and then copy intersecting curves to new location. When transform input geometry, the copied version is updated. This is good so far, but what if I need to copy all the curves resulting form the intersection, and those can change from one to more curves depending on the locations of input geometry? Are there some parameters within history that can handle such case?
“Command” creates a “History Record” that lists the inputs and outputs and a history “replay” function to run if one or more of the inputs “change”.
“Change” means an object is deleted or replaced in a call to CRhinoDoc::ReplaceObject().
If a change is detected, then the command’s replay function is run and that replay function is given access to the history record the command created.
If the person writing the replay function decided to inspect all outputs, dug around history records to see if those outputs were subsequently used as inputs to a transform command and then dug into the associated transform history record to get the transform commands transformation, then the replay history could additionally copy and transform “new” components.
Another approach would be to have the transform command’s replay history detect if all of its inputs were the decedents in some earlier history record. Then the transform command’s replay function could be written to transform all outputs associated with the history record. The approach is general, I’m using “transform command” as an example because it’s a good example and what you’re asking bout makes sense in the context of a transform command.
Conceptually, neither approach is hard or complex as an abstract set of steps. In practice, there are many tedious details to get right and lots of corner cases that would pop up and need to be handled.
Are lots of customers asking about this? If so, what are they doing and are there other possible solutions?
Hi Dale,
Thanks for the details. I certainly see a potential of using history more effectively in a more advanced functionality, but I am not sure it is there yet. I am not sure if other developers have already tested the limits of history, or simply created their own user-data, plugin tables, event handing etc to achieve what could perhaps be achieved more efficiently with history and hence I do not have other examples beside mine.
Here is some of what I need in sectioning (and what I already do in SectionTools without History)
1- Section geometry is extracted from intersecting clipping plane(s) with selected geometry.
2- Extracted intersection curves maybe turned into trimmed planar breps (if closed and the source is solid). (History?)
3- Extracted intersection curves maybe turned into hatched pattern (if closed and the source is solid).(History?)
4- Extracted curved maybe transformed (or unrolled) to lay flat on the xy-plane (basically create 2D Layout). (History)
As the model change and ClippingPlane move, the number of intersections coming out of #1 will vary. Also the attributes may need to change based on input. Additional necessary history functionality in relation to attributes is stated in RH-28095 &RH-18955.
I also need to understand how to support activating history inside the command (regardless if “RecordHistory” button is turned on or off), and also control the ReplayHistory so it is not happening automatically with every change, but only with some “Update Section” command or button.
My question is this: For the work I am doing in sectioning for V6 and beyond, do you think that History is/will be sufficient, or should I use user data, event handing, etc., etc.?
Not as far as I am concerned, but I was not sure if this discussion was going to turn useful for the general community. Feel free to change the category if you wish.
Another example that shows the limitation of history in PanelingTools.
If a grid is built out of a surface using some specified distance, then panels are generated using the grid, changing the size of the surface (more points are generated) will not populate paneling on the new updated grid as in the image.
