LDraw.org Discussion Forums

Hello all,

I discovered rendering glitches in the Linux version of my LDCad are caused by the limited way I correct 'invalid' matrices in part files. The wrong matrices cause all kinds of lighting problems in Ubuntu 11.10 with the open source radeon driver. Yet for some reason the windows driver couldn't care less, how's that even possible?

Anyhow I'm improving the correction code, but not being a part editor or a matrix expert I'm having difficulties with it. For example I can correct these (log fragment):

Code:
parts\2694.dat | line 164 | Matrix corrected from [10 0 0 0 0 0 0 0 10 ] to [10 0 0 0 1 0 0 0 10 ]

parts\2694.dat | line 165 | Matrix corrected from [-10 0 0 0 0 0 0 0 -10 ] to [-10 0 0 0 1 0 0 0 -10 ]

parts\2695.dat | line 13 | Matrix corrected from [6 0 0 0 0 6 0 0 0 ] to [6 0 0 0 0 6 0 1 0 ]

parts\2695.dat | line 14 | Matrix corrected from [6 0 0 0 0 6 0 0 0 ] to [6 0 0 0 0 6 0 1 0 ]

These all have exactly one row that's all zero's, the position for an automatic '1' can be determined quite easily.

But what about these:

Code:
parts\3039p32.dat | line 40 | Invalid matrix detected [2 0 0 0 0 1.4286 0 0 -1.4286]. It could not be corrected automatically, it might cause rendering glitches.

parts\3039p32.dat | line 41 | Invalid matrix detected [2 0 0 0 0 1.4286 0 0 -1.4286]. It could not be corrected automatically, it might cause rendering glitches.

I'm guessing the middle '1.4...' should move one place to the left, but how to automatically detect and correct for this (you could also do this for the 3rd row not?).

And these are even worse I think:

Code:
parts\6016.dat | line 38 | Invalid matrix detected [2.84 0 2.84 0 0 0 2.84 0 -2.84]. It could not be corrected automatically, it might cause rendering glitches.

parts\6016.dat | line 47 | Invalid matrix detected [-2.84 0 -2.84 0 0 0 2.84 0 -2.84]. It could not be corrected automatically, it might cause rendering glitches.

Or could I just put a '1' in the middle row's middle pos?, but yet again how to do a fool proof correction.

Any help would be appreciated.

Or maybe someone could just fix all the part files (just kidding Big Grin

)

> Or could I just put a '1' in the middle row's
> middle pos?, but yet again how to do a fool proof
> correction.

Without knowing the intention of the matrix you can't!

Firstly I think you should always assume that what is already in a column belongs there.

However, what you do know is that no column should contain only zeroes. So if one does a simple fix would be to replace it by the cross product of the other two columns renormalised to 1.

That way it will be orthogonal to the others columns but not large. If, as in the examples you give, the parts are flat and the third dimension is ignored then this will work perfectly.

This solution works for all the examples you give eg.

Code:
M=[-2.84 0 -2.84 0 0 0 2.84 0 -2.84]

=[-2.84 0 -2.84

      0 0     0

   2.84 0 -2.84]

c1=[-2.84 0 2.84]

c2=[0 0 0] !!!! Needs fixing

c3=[-2.84 0 -2.84]

x=cross(c1,c3)=[0 16.13 0];

c2p=[0 1 0]

> Any help would be appreciated.
>
>
> Or maybe someone could just fix all the part files
> (just kidding Big Grin

)

I think this would be the better solution.

Tim

Code:
> parts\3039p32.dat | line 40 | Invalid matrix

> detected [2 0 0 0 0 1.4286 0 0 -1.4286]. It could

> not be corrected automatically, it might cause

> rendering glitches.

> parts\3039p32.dat | line 41 | Invalid matrix

> detected [2 0 0 0 0 1.4286 0 0 -1.4286]. It could

> not be corrected automatically, it might cause

> rendering glitches.

>

>
> I'm guessing the middle '1.4...' should move one
> place to the left, but how to automatically detect
> and correct for this (you could also do this for
> the 3rd row not?).

Actually it shouldn't. The 'proper' matrix is given by the rule I state and is

Code:
[2 0 0 0 0.7071 1.4286 0 0.7071 -1.4286]

Brilliant, using the cross product just like with normals that's a much nicer approach then just tossing in a '1' somewhere.

I'm going to change it so if ether (exactly) one row or col is all zero's it fills it with the crossproduct of the other two rows/cols.

That should take care of most, if not all, det==0 problems.

Thank you very much.

It should work on all flat parts that are otherwise correct. It basically comes from the fact that a plane is overdescribed by three vectors so you can simply set the third vector to be perpendicular and normalised.

If you have two zero columns I think the part should be flagged as a dud. That's remapping a 3d object to a line and since there's no reason to ever do this it's definitely incorrect.

Tim

Thanks again,

It turns out (most of) the actual rendering glitches are caused by a bug in the Open source Radeon driver in Ubuntu 11.10 (it doesn't apply two sided lighting correctly).

But still thanks for this approach, parts like the model team wheel look nicer now.

I realize you've already had replies, but if you're still having problems, please look at the LDLModelLine::tryToFixPlanarMatrix() function in LDView's source code here.

Roland Melkert

Tim Gould

Tim Gould

Roland Melkert

Tim Gould

Roland Melkert

Travis Cobbs