Hey everyone, got another DC puzzle that’s wearing me down
Building this rolling ladder, which uses Triangle geometry to set the angle and length of the ladder, it’s sides, and it’s steps. In the past, I’ve made things with angled pieces that don’t get skewed when they’re resized, but for some reason this one does. More strangely, the COPY seems correct while the original is problematic, yet the problem persists even after copying the COPY’s insides to the original. Thoughts, anyone?
You don’t say exactly what you’re trying to resize. If you are trying to resize one of the side assemblies and you expect the other one to follow along, it won’t work because they are two separate component definitions.
The one on the left is listed in the outliner as “<Ladder_SideAssy>” – The name of the component definition and the component instance are identical – “Ladder_SideAssy”.
The one on the right is listed in the outliner as “Ladder_SideAssy copy 001 <Ladder_SideAssy#4>” The name of the component instance is “Ladder_SideAssy copy 001” while the name of the component definition is “Ladder_SdieAssy#4>”
Since they don’t use the same definition, change to one will not be reflected in the other.
A fix: in Ladder_SideAssy, chang copies from 1 to 0, create a custom attribute “length”, with value = parent!lenz, for lenz delete the parent!lenz reference, so becomes grey, no longer a fixed value
in Ladder_Side, change parent!lenz to parent!length
then copies back to 1
Oh wow, I see that this works…but why? Was it overdefined before? I’m glad for the fix. Maybe it has to do with the angle? Nearly everything I’ve made before followed an axis, so the parents and children haven’t gotten upset like this when they reference up the tree (with or without copies)
This is perfect, thank you!!
Now I gotta work out how to keep the wheels from getting skewed. Easiest solution is to just take them out of the side and have them do their own thing, but I’d like a more elegant solution. Does Skew not reset itself? It’s strange, to me, to see an axis that doesn’t sit
I think I’m starting to understand. I’m defining the LenX,Y,Z of components from the top down, forcing those “containers” to morph their contents by changing size (and, therefore, basically scaling their geometry-defining boxes). By using a pass through “length” attribute (I like xlen, ylen, zlen as a standard), the information is then being passed where it needs without anything getting stretched or compressed. Sound right?
There are a few “bugs” that can give unexpected results. You can as you say force the result you want, but this creates a very complicated set of DC formulas that need various fixes or workarounds. When you put rotations in, the chances of the DC code breaking down, hence the skew, is high as there some attempt within the code or SU to scale in the changed direction. @Proelan shared a simple DC where the axis are placed at a set distance from an object, this made sense in order to simplify the required position without using formula, this works fine whilst there is only one component, but adding another it breaks down. The distance from the axis is then scaled as well. So the DC algorithm does not cater for this scenario.
the fix in this case was
however a safe approach would be always to attach the axis to the object and use the position formula, only use the offset axis when it is required
Another safe approach is to build a model where the formula results in the same grey value, if lenX has 20 as a grey value, then a formula like Lenz*sin(ang-30) results in 20, not some other value, that will start the scaling. Forced values creates issues of synchronisation, although I have and one can work with this, and sometimes need to, the values of the parent sizes will not correlate.
This especially applies for Rotation as with an axis change there needs to be a swap in say lenZ to lenX. The safe approach here is to create a “at rest” model, in the case of the ladder have it hang at 0 degrees, with the same axis as the rest of of the model and always return to this state before editing. So the working model can have the angle at 12 degrees, but, I stress return this value to 0, the rest position before attaching more changes.
If you build with these three concepts, you will find you don’t have to account for every value, the grey will update to the their natural scale on scaling, etc
Yes
Most times to dont need to account for every lenX, Y … rather just those that require a set size or position, if all are in harmony, with no scale issues, they should work with minimum force. Plus there should be minimum jumping and redraw requirements during editing.
On a previous post with regards a mannequin, I decided to have a go at trying to get every part in sync, all axis, all scales, all positions, This I did after removing the formula, setting axis all in same direction and attached to the object, resetting scales and/or scaling definitions to get the model somewhat back an original state. I had reasonable success, however it cost time and patience, but a good exercise in trying to “mend” it, I observed a few DC peculiarities in how the measures change ever so slightly, thus revealing some residue scale problems, exploding and reinstating was the only way of fixing these. It is probably much easier to start again using a set of known size parts, making them the “at rest” then adding formula to match the grey, change the entry variable, check that it works, then go back to the rest position.
Sometimes I blunder on without a return to the rest position, formulas involving position and size are not a problem, if necessary, they can be “fixed” via reset or scale definition, but anything where there is rotation nearly always requires a return to this “at rest” position, otherwise there are skew problems. You can reset the skew via the right click menu, however as the DC becomes more involved, such fixes are a bit “hit and miss”.
I am not suggesting that you can’t model with out of sync bits or is wrong. There are times where you want it to be so, like in a case of a surround like a mold to fit to the outside of an opening that changes as the opening is scaled, then lenX,lenZ are not in sync between parent and child, one is definitely forced
So I would suggest exploding your model parents at their best position /size, right down to the lowest component, then with these, either reset or scale definition, via context menu (selection can be done in outliner as well) Set the ladder perpendicular, make all axis the same and attached to each part. On the context menu there should no more option to set scale or skew. plus their values should be precise, no stray .0035, etc. You can force a new size but then scale the definition. If the stray minor decimal places persist then copy the component name, explode and purge and remake with the pasted name.
then back to rebuilding the hierarchy and formula…all the best
