Hi Michael

Is there a way to enable history when arraying an object along a curve , so that if I edit the curve points the resultant objects move to reflect this.





I just realised this is covered at the end of the history and symetry post , it would though be a fantastic function for what I design, even with a drop in pc performance

thanks
shayne

Hi shayne, unfortunately I found at one point that the method MoI uses for storing history with storing it on the result objects was ending up making a large file size when there was a large array of curves for example, with each generated curve having the history data saved with it.

So because of that file size bloat from large arrays, none of the array tools have history enabled for them and there is not any way to adjust that currently, sorry.

In the future I want to significantly rework how history is stored and save it in a centralized list that is a sequence of actions rather than it getting saved as additional data only on result objects, when that work happens it should then be possible to remove this limitation and have history and array working in combination with one another.

- Michael

Thanks Michael
I find the history function when sweeping a profile then fine tuning it after generation invaluable.
I typically would array the stone solids and beads and array them along a shoulder profile and once correct don't change it, perhaps a history dump button or option on the history could get rid of the back history and reduce file size .
I see your point that saving all that data will generate large file sizes, my pc seems to handle large files with over 2000 solids (a lot of them with fillets ) Ok , some of the stl output files are in the 100's of mb
Feel free to add history on arrays to my wish list :) oh and the variable radius fillets (like the 2 distance chamfer) :) I realise thats a hard one also

perhaps an on off toggle in the options for those not wanting it rather than mucking around with the side pane buttons

thanks
shayne

Hi shayne, yeah there are some different possible approaches. But since I'm planning on doing a significant overhaul to how history works, it very well might be a kind of "dead end" to do much work on the current system, so at least currently I'm not really prioritizing work that would only apply to the current history system and then not do any good when it's all redone...

Also now that I think about it some more I seem to remember that in addition to the file size issue there was also a problem that the current history system actually only works in the cases where one single object is the output from the command like with a regular sweep for example. With multiple outputs the history system doesn't currently know how to process it.

- Michael