Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
|
| ||
| Views: 20,050,632 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
04-24-24 08:48 AM |
| Guest: | ||
| Main - Posts by blank |
| blank |
| ||
|
Normal user Level: 26 Posts: 41/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
But you didn't fix Yaz0File. The way it works now is really bad designwise, as it is counter intuitive and is just asking to be used in a wrong way. |
| blank |
| ||
|
Normal user Level: 26 Posts: 42/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
There is no reason why blender models should be harder to convert than models made by other programs. If you are having problems, somebody should proabably tell me about it, so I might have a chance to fix them. |
| blank |
| ||
|
Normal user Level: 26 Posts: 43/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
Posted by SuperMario64DS Have you actually talked to BlackJax about this, or have you just heard some rumours? Because I don't really feel it's worth the time to write a full description if I'm the only one working on BDL editing tools anyway. |
| blank |
| ||
|
Normal user Level: 26 Posts: 44/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
Posted by SuperMario64DS I do agree that the BMD/BDL file format should be documented in such a way, but if there's nobody who actually needs it, I don't really feel like writing it at the moment. Posted by NWPlayer123 It's not about figuring anything out. Everything but a few minor things has been figured out. It's just about writing documentation. EDIT: Posted by SuperMario64DS If anybody is interested in working on BMD/BDL editing, they can contact me. And I'm not withholding any information, I just choose not to write it up in an easy accessible way. The most important parts of the documentation can already be found in the source of bmdview2 anyway. |
| blank |
| ||
|
Normal user Level: 26 Posts: 45/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
No. The only planets in SMG2 with the WaterFlag set is NewOnimasuPlanet and StarCreekPlanet, and there is far more planets with water collision models.
By the way, water collision models are stored in MoveLimit.kcl files. But these MoveLimit.kcl files aren't necessarily water collision, they can also be other things such as gravity changing boundaries. I don't know exactly how the game decides what is water and what is something else, but I'm guessing it has something to do with areas. |
| blank |
| ||
|
Normal user Level: 26 Posts: 46/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
The only thing I noticed after a brief look that might cause problems is that you only export/import one scale, translation and rotation per joint. I don't have any BCK files at my disposal at the moment, so I can't really test it. |
| blank |
| ||
|
Normal user Level: 26 Posts: 47/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
The dark textures might be caused by ColorChanInfo, which thakis didn't get quite right. It should be
struct ColorChanInfo
{ u8 enable; u8 matColorSource; u8 litMask; u8 diffuseAttenuationFunc; u8 attenuationFracFunc; u8 ambColorSource; u8 pad[2]; }; As for bump mapping that's done through indirect texturing. The information on indirect texturing is stored in MatIndirectTexturingEntry struct IndTexOrder { u8 texcoord; u8 texmap; u16 padding0; }; struct IndTexMatrix { f32 offset_matrix[2][3]; s8 scale_exponent; u8 padding0[3]; }; struct IndTexCoordScale { u8 scale_s; u8 scale_t; u16 padding0; }; struct TevIndirect { u8 indtex; u8 format; u8 bias; u8 mtx; u8 wrap_s; u8 wrap_t; u8 addprev; u8 utclod; u8 a; u8 padding0[3]; }; struct MatIndirectTexturingEntry { u8 unknown0; // always 0 or 1 u8 unknown1; // unknown1 = unknown0, one of these are numindtexs u16 padding0; IndTexOrder indtexorder[4]; // arguments to GX_SetIndTexOrder IndTexMatrix indtexmatrix[3]; // arguments to GX_SetIndTexMatrix IndTexCoordScale indtexcoordscale[4]; // arguments to GX_SetIndTexCoordScale TevIndirect tevindirect[16]; // arguments to GX_SetTevIndirect }; |
| blank |
| ||
|
Normal user Level: 26 Posts: 48/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
I took a quick look at the shader generation code, and rasterizer color selection isn't implemented. That could be the cause of the dark textures. |
| blank |
| ||
|
Normal user Level: 26 Posts: 49/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
After a considerably closer look I can say that it is definitely lighting that's the issue. That particular material has the alpha channel lit but not the RGB channel. But bmdview2 only checks whether the RGB channel is lit. That and lighting isn't really implemented. |
| blank |
| ||
|
Normal user Level: 26 Posts: 50/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
Color channels are basically what produces the rasterizer color. There are two color channels, a primary and a secondary. Each channel takes as input a material color and an ambient color, and calculates an output color based on the channels lighting configuration. That color can then be used in the TEV stages.
But color and alpha can be configured separately, and the material in WoodCircleCutPlanet.bdl with the dark texture problem has lighting enabled for the alpha channel but not for the color channel. Try looking here: http://libogc.devkitpro.org/gx_8h.html. The relevant functions are GX_SetChanCtrl, GX_SetChanMatColor and GX_SetChanAmbColor. The relevant information in bmdview2 in the Material struct is chanControls, color1 (arguments to GX_SetChanMatColor) and color2 (arguments to GX_SetChanAmbColor). Posted by dash Yes, that is the problem: bmdview only looks at chanControls[0] (the channel controls for the primary color channel) but not at chanControls[1] (the channel controls for the primary alpha channel). |
| blank |
| ||
|
Normal user Level: 26 Posts: 51/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
Posted by dash Yes, just about everything in the materials are indices into some table. Posted by dash chanControls[0] references the controls for the primary color channel (GX_COLOR0), chanControls[1] references the controls for the primary alpha channel (GX_ALPHA0), chanControls[2] references the controls for the secondary color channel (GX_COLOR1) and chanControls[3] references the controls for the secondary alpha channel (GX_ALPHA1). I'm certain of that. |
| blank |
| ||
|
Normal user Level: 26 Posts: 52/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
It's a common misunderstanding that alpha is same as transparency, but it's not. Alpha is an extra auxiliary value that can be used for a lot of different things. In the gamecube/wii, what the alpha value is used for depends on stuff like the TEV stages, alpha compare settings and blend mode.
As for what to do to fix the problem, I don't really know either. Lighting isn't really implemented in bmdview2, and properly implementing it is more work than it's worth, in my opinion. |
| blank |
| ||
|
Normal user Level: 26 Posts: 53/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
You forget to align trans_offset. |
| blank |
| ||
|
Normal user Level: 26 Posts: 54/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
The MDL3 section contains the materials of the model, but in a format different from the MAT3 section. In the MAT3 section the materials are stored as arguments to the GX functions, while in the MDL3 section they are stored as raw GP packets. |
| blank |
| ||
|
Normal user Level: 26 Posts: 55/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
Posted by Marionumber1 I don't really think there is a good reason. They probably added the MDL3 section because the GP packets are faster to load, and kept the MAT3 section because the BDL format is supposed to be an extension of the BMD format. Posted by JwopDk That was also my first idea, but that won't work. You might want to read this thread (you'll have to sign up to the forum to see it) to see what have already been done. EDIT: You might also find this thread interesting. |
| blank |
| ||
|
Normal user Level: 26 Posts: 56/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
There is some texture matrix info and one unknown in the MAT3 section that is not in the MDL3 section, so MDL3 is not a complete replacement for MAT3. But other than those two things, the information in the two sections is the exact same, just stored in different formats. |
| blank |
| ||
|
Normal user Level: 26 Posts: 57/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
struct TexMtxInfo
{ u8 projection; u8 type; u16 paddding0; // 0xFFFF f32 center_s,center_t; f32 unknown0; f32 scale_s,scale_t; u16 rotate; // -32768 = -180 deg, 32768 = 180 deg u16 padding1; // 0xFFFF f32 translate_s,translate_t; f32 prematrix[4][4]; }; The projection field can be either GX_TG_MTX3x4 and GX_TG_MTX2x4. The type field specifies which texture matrix type to use. I've found 6 different types in SMG2: type=0x00 Always combined with projection=GX_TG_MTX2x4 and has regular texture coordinates as source. This is the simplest and most common type. The texture coordinates is first rotated and scaled about (center_s,center_t) and then translated. type=0x06 Always combined with projection=GX_TG_MTX2x4 and has transformed normals as source. The normals are first projected with the matrix [[0.5, 0, 0, 0.5], [0, 0.5, 0, 0.5]] and then the same transformations as for type=0x00 are applied. NOTE: It is possible that the matrix prematrix is applied to the normals before they are projected. type=0x07 Always combined with projection=GX_TG_MTX3x4 and has transformed normals as source. Same as for type=0x06 except the projection matrix is [[0.5, 0, -0.5, 0], [0, 0.5, -0.5, 0], [0, 0, -1, 0]]. type=0x08 Always combined with projection=GX_TG_MTX3x4 and has untransformed position coordinates as source. First the matrix prematrix is applied to the coordinates, then the coordinates is projected by the matrix [[0.5, 0, 0.5, 0], [0, -0.5, 0.5, 0], [0, 0, 1, 0]] and then the same transformations as for type=0x00 are applied. type=0x09 Always combined with projection=GX_TG_MTX3x4 and has transformed position coordinates as source. I don't know how this works, but I think it's just like type=0x08 but with transformed position coordinates. type=0x80 Always combined with projection=GX_TG_MTX2x4 and has regular texture coordinates as source. I don't know how this works either, but it seems to be like type=0x00 except it uses unknown0 in some way. |
| blank |
| ||
|
Normal user Level: 26 Posts: 58/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
This is the python code I use to generate texture matrix commands for the MDL3 section
def SetTexMatrix(self,slot,args):
c = cos(args.rotate) s = sin(args.rotate) R = numpy.matrix([[c,-s,0],[s,c,0],[0,0,1]]) S = numpy.matrix([[args.scale_s,0,0],[0,args.scale_t,0],[0,0,1]]) C = numpy.matrix([[1,0,args.center_s],[0,1,args.center_t],[0,0,1]]) T = numpy.matrix([[1,0,args.translate_s],[0,1,args.translate_t],[0,0,1]]) if args.type == 0 or args.type == 0x80: P = numpy.matrix([[1,0,0,0],[0,1,0,0],[0,0,0,1]]) elif args.type == 6: P = numpy.matrix([[0.5,0,0,0.5],[0,0.5,0,0.5],[0,0,0,1]]) elif args.type == 7: P = numpy.matrix([[0.5,0,-0.5,0],[0,0.5,-0.5,0],[0,0,-1,0]]) elif args.type == 8 or args.type == 9: P = numpy.matrix([[0.5,0,0.5,0],[0,-0.5,0.5,0],[0,0,1,0]]) M = T*C*S*R*C.I*P*numpy.matrix(args.premtx) if args.projection == gx.TG_MTX2x4: self.texmatrix[slot][:] = (M[i,j] for j in range(4) for i in range(2)) elif args.projection == gx.TG_MTX3x4: self.texmatrix[slot][:] = (M[i,j] for j in range(4) for i in range(3)) C.I is the inverse of the C matrix. As you can see, I have chosen to apply the prematrix for all types, but I am not sure this is correct. It will need some more testing. |
| blank |
| ||
|
Normal user Level: 26 Posts: 59/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
I'm pretty sure those values aren't there. They definitely aren't in the MDL3 section and I haven't found anything that looks like them in the MAT3 section. |
| blank |
| ||
|
Normal user Level: 26 Posts: 60/129 EXP: 96163 Next: 6112 Since: 07-08-12 Last post: 3340 days ago Last view: 2313 days ago |
I don't have the Link model from Wind Waker, so I don't even know what the exact problem is. How does his eyes look as it is now? |
| Main - Posts by blank |
|
Page rendered in 0.060 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 138/138, time: 0.020 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |