Talk:KCL (File Format)
Jump to navigation
Jump to search
Biggest KCL
What is the biggest KCL file? Koopa Cape's isn't big enough for a course I'm making. --Bcphoton (talk) 18:39, 16 March 2013 (UTC)
- Don't use the SZS Modifier for anything except for the minimap. There are tons of alternatives, I recommend Wiimm's KCL Tool.
- kHacker35000vr (talk) 18:50, 16 March 2013 (UTC)
- However for the record I believe the biggest KCL in MKWii is Maple Treeway's. -- WorldsBoss (talk) 19:05, 16 March 2013 (UTC)
- There are 4 kinds of big:
- Big in vertex size (Koopa Cape)
- Big in normal size (Koopa Cape)
- Big in triangles size (Maple Treeway)
- Big in octree size (Maple Treeway)
- Read this for technical limits and how to create an optimal sized KCL: KCL Tutorial (Wiimms Tools)
- Wiimm (talk) 20:40, 16 March 2013 (UTC)
- There are 4 kinds of big:
Octree
I am trying to understand the octree. I understand the basics of it but there is one thing that is very unclare. The offsets in the octree (that links to more nodes or a triangle list), what are they relative to? I have tried with start of octree data and relative to itself but they seem wrong to me.
--Wexos (Talk | Contribs) 16:37, 5 May 2017 (UTC)
- If I remember right, all links are relative to the beginning of the octree section. But the highest bit decides about the object behind the link: tree entry or triangle list.
- If you want a human readable dump of KCL, try: wkclt dump -ll FILE
- ... and search »#O#« for the octree and »#L#« for the triangle list. Use wkclt help dump to get help.
- -- Wiimm (talk) 19:20, 5 May 2017 (UTC)
- I'll try that. I saw an offset in a KCL created with your tool that linked (if relative to the start of the octree data) into the middle of a triangle list offset (it linked to the third byte in a UInt32). I don't see how that could work. The first triangle list was directly after that offset.
--Wexos (Talk | Contribs) 21:29, 5 May 2017 (UTC)
- I'll try that. I saw an offset in a KCL created with your tool that linked (if relative to the start of the octree data) into the middle of a triangle list offset (it linked to the third byte in a UInt32). I don't see how that could work. The first triangle list was directly after that offset.