LDraw.org Discussion Forums

Full Version: MLCad ~movedto buggy???
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
I just discovered that MLCad seems to ignore transformation matrix and origin offset when it "upgrades" older version parts!
Attached a sample file and the buggy result I get after "upgrade" and save with MLCad.
Now I am appaled Sad
Did I miss something and is this a known bug?
MLCad doesn't appear to ignore the transformation for me.

If I build a model now with a u9131.dat and 132-old.dat then I have to rotate 132-old.dat to get them to match, but presumably since there is a transformation in the current 132-old.dat then if I had built the model 5 years ago I wouldn't have needed that same rotation - all tyres would be 1 0 0 0 1 0 0 0 1 with the side of my "car" in MLCad's "front" view - as you get now with u9131.dat.

But if MLCad loads an old model now with the old part at 1 0 0 0 1 0 0 0 1 it then detects the new part (which is internally oriented differently from the old part) and if I allow it to "upgrade" the part it does apply the transformation from 132-old.dat which causes it to negate the internal rotation that took place when the part was originally changed.

Apologies if I've totally missed the point - this is more than a little confusing without access to how 132-old.dat presumably used to look before 2011 and with a model built back then. But answering "yes" or "no" to the "upgrade?" prompt does provide different results - so transformation is not being ignored (I didn't test with origin offset).
Indeed, I was not probably very clear. The problem is indeed that if I answer "yes" to "upgrade" I get a wrong result... If I answer no, the movedto file becomes a plain regular file, and the included transformation is properly done.
In my mind answering "yes" to "upgrade" gives the correct result.

I'm assuming in the history of this tyre, whatever part number it has, the part's definition has internally been rotated at some point.

Answering "no" would give the wrong result - in the sense that viewing the old model with the old part number that now links to the new part but without the transformation applied (because you chose "no") means the tyre would face the wrong way.

The logic only looks wrong to me if you now create a new model and add 132-old.dat, since the first reload+upgrade of this model will flip the tyres the wrong way, but you're not supposed to be using the part on new models. The upgrade, I have assumed, is for fixing old models, and choosing "yes" seems to do what I'd expect.
Mmmhhh... headache now stronger!
According to me, testmoved.ldr above is the old file created before moved to. If I look at it using LDView, it looks right.
testmovedmlcad.ldr is the saved upgarded file in MLCad - and it does look wrong in LDView! So imho there IS a problem: "Upgrading" files gives breaks the file.
Philippe Hurbain Wrote:According to me, testmoved.ldr above is the old file created before moved to. If I look at it using LDView, it looks right.
testmovedmlcad.ldr is the saved upgarded file in MLCad - and it does look wrong in LDView! So imho there IS a problem: "Upgrading" files gives breaks the file.

But testmoved.ldr presumably isn't really an old file in the sense of "old model". You've just created it, using the current incarnation of the parts library, right?

I think the MLCad upgrade process is for upgrading old models that used old parts, not new models using old parts whose definitions have been internally rotated in their more recent history. If you added 132-old.dat now to a model of a car whose side was visible in MLCad's "front" view you would need to rotate the tyre. But I don't think that would always have been the case with an earlier version of the parts library. We're trading the rotation from the upgrade process against the rotation that occurred in the past when the part was modified.

I think.

Philippe Hurbain Wrote:Mmmhhh... headache now stronger!

I know the feeling! I'm sending you my paracetamol bill ;-)
Ok, having looked at this some more, I think you may be correct and my earlier assertion about how things are handled when a part has deliberately had its orientation changed in the past may not be correct. I created my own new part, used it in an "old" model, redefined the part with a ~moveto/rotation to keep compatibility, and nothing I do now will cause MLCad to display it correctly. But to be honest my head hurts and my brain can't take any more now, so depending on what anyone else here says, I may attempt the experiment again when/if my brain recovers.
Yes, I think we need fresh SPAM CONTENT here Wink
It's no fun getting old. 20 years ago I would have had this one sussed in 5 minutes.

For what it's worth, I found an old lugnet post talking about a slightly earlier edition of MLCad that seems to confirm that MLCAD does indeed not honour the translation/rotation on a ~moveto, and the same probably still applies to 3.4.
To me everything looks to be correct.

The problem is that you might be tempted to "see" the current part "132-old" as being the same as the old part. It is not. The current file, the Moved to-file, shows a part in the same position as the old file, but you are actually looking at u9131.

Any model, new or old, containing a reference to the file "132-old.dat" is correctly being updated, and rotated, by MLCad if you answer Yes .
Pages: 1 2 3