(2023-04-08, 11:57)Magnus Forsberg Wrote: No, you are correct. Two stud primitives are incorrectly flipped in 4733, and should be corrected.
Stud primitives should be rotated into the wanted position. Never fipped.
(The only exception is the bottom stud that is always used mirrored, but only on the y-axis.  https://www.ldraw.org/library/primref/#studstud )


LDraw uses a right-handed co-ordinate system where -Y is "up".
https://www.ldraw.org/article/218.html#coords

(2023-04-08, 12:25)Florentin Wrote: How come that softwares that use ldraw (like Studio) render them correctly? Do they manually check each part if they are correct and so they pretty much have their own library or how does that work?

(2023-04-08, 12:25)Florentin Wrote: EDIT: Ok i fixed the studs issues: I flipped the matrix intake around, not reading in the first 3x3 part where the rotation happens column first but row first and now I just have some random triangles flying around on some parts, so it's better but not fully correct yet (see last 2 pictures)!

(2023-04-10, 11:00)Florentin Wrote: So you want me to read in the values like this?

Code:

const splittedLine = this.splitter(line, " ", 14);
let transform = new Matrix4();

transform.set(
  parseFloat(splittedLine[5]), parseFloat(splittedLine[8]), parseFloat(splittedLine[11]), 0,
  parseFloat(splittedLine[6]), parseFloat(splittedLine[9]), parseFloat(splittedLine[12]), 0,
  parseFloat(splittedLine[7]), parseFloat(splittedLine[10]), parseFloat(splittedLine[13]), 0,
  parseFloat(splittedLine[2]), parseFloat(splittedLine[3]), parseFloat(splittedLine[4]), 1
);

I use Threejs so the set method puts in the values row first into the matrix (I assume that's how you put the values into your matrix).
That results in an also incorrect result (see pic 1).

I think your reading of the values is wrong, because this is how i learned that you multiply homogeneous matrices and points the 3d space (unless you meant column first inserting into the matrix, cause then I'd be the same as I read in the values first but well that's because I made this post ):

Code:

a b c x         u
d e f y     *   v
g h i z         w
0 0 0 1         1

(2023-04-10, 14:07)Jonathan N Wrote: Different libraries have different conventions for how the matrix entries are initialized and accessed. You should be able to call the decompose function on your matrix to double check that it's working properly. The translation, scale, and rotation vectors should match what you expect if everything is working properly. I would also double check the matrix multiplication itself since A*B != B*A in general.

(2023-04-10, 15:05)Florentin Wrote: I may have found the problem....
So I am writing an io file parser, not one for specifically an ldr file. And those .io files have three ldr files in them. One of them has all resolved subparts (or whatever you call them ) in them so you don't need to load all the needed files for that but have them all things you need in just one. And I was always working with that file (it's the "model2.ldr" one).
And what could be is that this file just has wrong values in it... at least that's what I do expect rn

(2023-04-10, 18:29)Max Murtazin Wrote: You should use model.ldr file for .io-s

(2023-04-12, 18:43)Florentin Wrote: So I have to resolve all of the parts and subparts manually to get a full mesh to display it ok.
Is there a way to differentiate if a reference (a Line Type 1) is leading to a part, a subpart or a primitive for easier fetching of the part? Is there a list or something where a program could look up each filename and find out what kind is being meant?