Views: 19,702,136 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
02-25-24 03:38 PM

Main - Posts by dash

Posted on 02-08-13 09:42 PM, in The Introductions Thread Link | #14389
Found this forum and thought it had lots of useful information. It's been on my TODO list to extract artwork and models from the SMG games (also NSMB) on Wii. I'm a programmer, linux related usually.

Posted on 02-08-13 09:52 PM, in Model formats - A better understanding Link | #14394
It's my intention to mess around with the bmdview2 codebase, I created a googlecode copy of it here:


I don't know how long I'll mess with it until I run out of steam... at the moment I want to make it easier to navigate around the model, maybe use the mouse to "drag" the screen. Similiar to google earth and white hole.

Posted on 02-11-13 06:24 PM, in Model formats - A better understanding (rev. 2 of 02-11-13 06:24 PM) Link | #14886
Posted by Mega-Mario

Something that would definitely be lovely would be to combine editing/importing abilities into bmdview2.

Oh and if you need help with reverse-engineering stuff or whatever, you can try asking me. No guarantee I'll be able to answer, though. But I'm available.

I've managed to get the mouse control working pretty well in bmdview2. The codebase I'm starting from seems to have a few issues, as in the text overlays are not visible, and the gl shaders don't seem to be rendering everything correctly.


As regards reverse engineering the bdl/bmd format, I wonder if the format makes use of bump mapping?

Posted on 02-12-13 12:17 AM, in Model formats - A better understanding Link | #14919
I realized the text overlay is off by default, you had to hit tab to get it to show up. I changed it so it's visible all the time.

The issue with the shader not rendering correctly... I realized it is rendering the textures but they're just very dark. So I think it's a lighting issue. Hitting the 'g' key causes the program to fallback to some other rendering approach (standard GL without shader language?) and that looks like it matches the real program more closely.

Here's an image with the shaders on:
Here's one with the shaders off (using the fallback rendering, whatever it is...)

Posted on 02-13-13 04:21 PM, in Model formats - A better understanding (rev. 2 of 02-13-13 04:39 PM) Link | #15198
Posted by blank
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];

I made that change in ordering but it didn't improve anything. For the scene I'm viewing (WoodCircleCutPlanet.bdl, which is in the BigTree2Galaxy in whitehole) both the enable and litMask fields are 0 in all cases.

I dug a bit just to understand the discussion of indirect texturing, found out bump maps are often done by making use of a height map (an array of scalers) by finding the partial derivatives in x and y to get the surface normal... and also to understand a little better the gamecube pipeline. But I'm not sure if this is associated with the dark texture issue.

Posted on 02-14-13 03:40 AM, in Model formats - A better understanding (rev. 3 of 02-14-13 04:10 AM) Link | #15289
Posted by blank
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.

I'm not sure of that, I checked the fragment shader code at it is outputting a color c0:
vec4 c0 = vec4(-1.447059, -0.400000, -0.098039, 0.172549);
if I force "ONE" to be used instead of c0, the grass looks correct. The code is from the MAT 6 (numbered from 0). WoodCircleCutPlanet.bdl_frag_6.txt

the colorS10 pick array contains
colorS10: 0005000600020003
and the colors are these:
colorS10: 00ff00ff00ff0000 0000000000000170 00ff00ff00ff00ff 0000000000000000 fe8fff9affe7002c 006500650065ffcb 012f012f012f011b (7 many)

It's like the material is asking for color 5 there but is getting 4... that fe8f ff9a ffe7 002c is the c0 rgba values in signed 16 bit...
EDIT: Whoops I was looking at mat7. mat6 colorS10 pick is this:
colorS10: 0004000100020003
If I make it so the starting color register c0 comes from the color3 pick array, the scene looks much nicer, and the green is perfect on the grass.
const Color16& c = mat.colorS10[currMat.color3[i==0?3:i-1]]; //XXXX ????? (sunflower.bmd)

as opposed to
const Color16& c = mat.colorS10[currMat.colorS10[i]]; //XXXX ?????

But that change makes the Mario.bdl model look too white and overexposed.

Not sure if I'm looking in the right place.

Posted on 02-14-13 06:30 PM, in Model formats - A better understanding (rev. 2 of 02-14-13 07:19 PM) Link | #15352
Posted by blank
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.

I'm completely lost, I'm trying to figure out what you're saying here. I don't know which controls in the material you're speaking of, I don't grasp the precise usage of "lit" or "channel". I'm very familiar with opengl and shader language, but the gamecube/wii graphics pipeline is relatively new to me and the bmd graphics format is new also. The only document I've located that provides info on the gamecube pipeline is this:


EDIT: Possibly your statements are connected to your definition of the ColorChanInfo struct you provided earlier. That has 2 fields, enable and litMask. In the WoodCircleCutPlanet.bdl the array of those structures has 5 entries:
colorChanInfo: 000100020100ffff 010104020100ffff 010000010000ffff 000000000200ffff 000000020100ffff (5 many)

The material 6 structure has this for chanControls:
chanControls (?): 0000000100020003

The bmdview2 source looks at chanControls[0] (the first entry, 0000). The whitehole source just skips over the chanControls array.

Posted on 02-15-13 05:20 AM, in Model formats - A better understanding (rev. 2 of 02-15-13 06:33 AM) Link | #15473
Posted by blank
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).

Good lord this is hellishly complicated...

According to the debug dump from bmdview2 it is saying numChans=00 for all the materials. I sort of grasp the 3 different options for GX_SetNumChans(), but it was looking like the numchans was always getting set to 0. But it appears there is a table lookup, so that numChans=00 is indexing into a table:
numChans (?) (unk[2]): 01 54 68 69 (4 many)

Which would mean we actually are doing GX_SetNumChans(1). Similiarly it looks like each material has a tevcount number, but those only make sense if they're also indexing into a table:
tevStageCounts (unk[4]): 02 01 54 68 (4 many)

Now, I grasped the TevStageInfo how it has abcd selection, operation, bias, scale, doclamp and output select for BOTH the rgb and alpha. I hadn't noticed the alpha side of things until I saw the function calls in that libogc reference, and saw everything was duplicated for alpha as well...

But are you sure the chanControls[] table works as you suggest? It would make more sense (to me at least) if that table indexes into the colorChanInfo table, but NOT where chanControls[0] is associated with the rgb, and chanControls[1] is associated with the alpha.

See, you've got 0, 1 or 2 channels feeding into the TEV pipeline. You've got a big table of control settings for a channel. A material would need a small table indexing into the channel control settings table for anywhere from 0 to 2 channels being used. So whoever worked out this storage format leaves space for 4, to accomodate a bit of future expansion (one more channel).

There are the TevStageinfo lines:
TevStageInfo (ff) (ain, bin, cin, din) (op, bias, scale, doClamp, tevRegId):
ff 0e 02 0a 0f 00 00 00 01 00 06 07 05 07 00 00 01 01 00 ff
ff 0f 00 08 01 00 00 00 01 00 07 05 04 07 00 00 00 01 00 ff
ff 0f 0a 08 0f 00 00 00 01 00 07 05 04 04 00 00 00 01 00 ff (3 many)
We see each row has the TEV configuration for both the rgb and alpha machinery.

Now it seems to me the problem with bmdview2 is the variable number of TEV stages is implemented, but only (effectively) a single channel is implemented. All the materials in the WoodCircleCutPlanet.bdl use 2 channels.

I haven't come to understand exactly how the multiple channels are combined before being fed into the TEV pipe. This link provides some useful theory about the gamecube hardware, I saw it referred to somewhere (this website?) but don't remember where.


That page mentions channels. "The conditional add is facilitated using the two different color channels GX_COLOR0 and GX_COLOR1."
EDIT: I found how the 2 channels are combined: They aren't. This is from that gx_8h.html page: "Since there is only one rasterizer for color in the graphics hardware, you must choose which color to rasterize for each stage in the Texture Environment (TEV) unit. This is accomplished using GX_SetTevOrder()."

Posted on 02-15-13 12:55 PM, in Model formats - A better understanding Link | #15517
Posted by blank
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.

Ok that does seem to make more sense.

I'm not even sure now what would need to change in order to fix this. As you say lighting is off on the rgb channel, but on on the alpha channel. I'm not even sure of what is supposed to happen. If the alpha is not 1.0, doesn't that imply transparency when the texture is rendered to the display? And wouldn't that mean you've got a transparent grassy texture combined with the wood wall? And in that case, wouldn't the order the textures are rendered in matter?

Posted on 02-15-13 05:17 PM, in Model formats - A better understanding Link | #15547
Posted by blank
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.

Still, I think I benefitted a bit from digging around (always nice to have an excuse to learn something). And the discussion might be of benefit to others who want to further refine the understanding of the bmd files.

One thing that is obvious from this exercise is the bmd files are just a wrapper for the settings values for the gamecube / wii SDK functions (which presumably just set hardware registers). That is, by understanding the API calls and what they're supposed to do it becomes pretty obvious what the fields in the BMD file are for. I imagine in the old days the first pass at figuring out what the bmd format was involved using a debugger to single step the CPU and find out how data is read from the bmd file and fed into API calls. It can't be very convoluted, for performance reasons. So I'd guess there wasn't a lot of assembly code to wade through.

Something I've wondered about. The devkitpro / libogc that is used to program the wii (Wiibrew)... it seems so polished and elaborate I'd always thought it was Nintendo's own SDK released to the public (or leaked).

Posted on 02-22-13 05:49 PM, in Model formats - A better understanding Link | #16320
For the sake of closure I just wanted to note I fixed the problem in the bmdview2 codebase that was causing it to output a corrupt 3ds file. The updated code is on the googlecode page here:


The original author probably would be kicking himself, the mistake was so trivial:
- for(size_t k = 2; j < curr.points.size(); ++j)
+ for(size_t k = 2; k < curr.points.size(); ++k)

Main - Posts by dash

Page rendered in 0.050 seconds. (2048KB of memory used)
MySQL - queries: 21, rows: 119/119, time: 0.012 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.