My guess is that they fail in your Feature Manager when you create features before split lines because the Split line feature is dependent on a specific face/s in which to split. Because every feature in SW identifies faces called "face ID's" (internal to the software) a feature before your split line will change the idenfication of the face you orginally split. This is basically how we make all the history based parametrics work in SW. I believe it's not too bad when this happens, since all you need to do is edit the split line feature and identify the correct face. I think we could do better at this but it would require that we make a lot of assumptions about what you did when you rolled back before the Split Line - kinda like a Terminator movie
I realise this may not be as simple as it sounds, but couldn't (or shouldn't) the internal "face IDs" be fixed once they are referenced by another feature? If a new feature is created, surely it and only it should adopt new IDs. Existing IDs should be left intact.
The user shouldn't have to edit anything as a workaround for the programs shortcomings. The program should be doing the editing, either by not changing other IDs in the first place, or by updating the ID references used by existing features.
Yes, you're right, we should try to track Face ID's when possible, and in some cases SW does, but the "ID" is lost in some cases when features "spawn" or divide new faces as a result of the feature - then what? - it's a 50/50 or worst guess at to what should be split as a result of what happens up stream. Don't get me wrong, I'm not saying this is justified, I'm just saying it's a harder problem to solve than you might initially realize.
I think I'd have to see Carter's file before I venture down this road any further. So, Carter, if you can reproduce this in a non IP file and post it, I'd be very interested to see what exact might be happening.
Well here is a prime example of simple change that isnt easy to accomplish without breaking stuff.
The stuff that gets *broken* is all quite minor and logical to the user but it sucks up time to fix it.
What say Carter was trying to develop his ideas as modelling progressed.
It took him an hour to redo it this one time but what say he had a bit of experimentation to do to arrive at his best solution.
Easily half a day gone and its not much of a change.
This is the type of thing that is really aggrevating and an obstacle to productivity which is why I have learned to plan well rather than play inside SW and why I dont support your initiative to promote/enable SW use from concept to final inside one model.
I know I've seen this split line problem before myself and it becomes very tedious to correct particularly if the rebuild time is long.
It is fairly likely that the surface being split is the same one as was identified before.
It would be artificially intelligent to presume to replace the missing one with the nearest to the last and have all the following dependant features auto heal. Popup box 'Should SW use this surface to replace the missing one and propogate the result? Y/N'...Y and done ..
Some while ago now lost in history I proposed rearchitecting SW so that a cpu thread was running AI monitoring the modelling process and offering helpful assistance. This is an example of that. The questions posed can be somewhat grey in nature and make assumptions on the basis of the typical work the user does and the tools he/she is using. They neednt be geometric or logical tests.
If you want to pursue a more responsive system to the users workflow consider one that can relax or suspend contraints at appropriate times or make substitutions on the basis of likely intent to assist progress. Perhaps this is something that Rick might find interesting to pursue.
I still wouldnt support concept to final augmented by these refinements.
Face ID's being an internal thing and all, I have no idea how they actualy work, but here's my thought on the tracking process...
If the Face ID was a series of letters, say Face A, Face B, Face C, etc. then if Face A get's split, the new faces take on ID's of Face AA, Face AB, etc. The initial 'A' then indicates to downstream features that it is still the old face A, and then the feature makes a decision (based on system options), or presents the user with a dialog box asking whether to incorportate all new faces, or just selected faces, etc. (ala body scope).
I wouldn't be surprised if the situation is way more complicated than this though, or I am way off the mark...