Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
|
| ||
| Views: 19,994,571 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
04-19-24 01:24 PM |
| Guest: | ||
| Main - Posts by dash |
| dash |
| ||
|
Normal user Level: 9 Posts: 1/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
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.
|
| dash |
| ||
|
Normal user Level: 9 Posts: 2/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
It's my intention to mess around with the bmdview2 codebase, I created a googlecode copy of it here:
http://code.google.com/p/bmdview2/ 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. |
| dash |
| ||
|
Normal user Level: 9 Posts: 3/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by Mega-Mario 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. http://code.google.com/p/bmdview2/ As regards reverse engineering the bdl/bmd format, I wonder if the format makes use of bump mapping? |
| dash |
| ||
|
Normal user Level: 9 Posts: 4/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
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: ![[image]](http://www.xdr.com/misc/with_shader.jpg)
Here's one with the shaders off (using the fallback rendering, whatever it is...) ![[image]](http://www.xdr.com/misc/without_shader.jpg) |
| dash |
| ||
|
Normal user Level: 9 Posts: 5/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by blank 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. |
| dash |
| ||
|
Normal user Level: 9 Posts: 6/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by blank 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 EDIT2: 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. |
| dash |
| ||
|
Normal user Level: 9 Posts: 7/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by blank 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: http://www.amnoid.de/gc/tev.html 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. |
| dash |
| ||
|
Normal user Level: 9 Posts: 8/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by blank 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):
We see each row has the TEV configuration for both the rgb and alpha machinery.
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) 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. http://www.gamasutra.com/view/feature/131354/shader_integration_merging_.php?page=2 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()." |
| dash |
| ||
|
Normal user Level: 9 Posts: 9/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by blank 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? |
| dash |
| ||
|
Normal user Level: 9 Posts: 10/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
Posted by blank 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). |
| dash |
| ||
|
Normal user Level: 9 Posts: 11/11 EXP: 2332 Next: 830 Since: 02-08-13 Last post: 4073 days ago Last view: 4069 days ago |
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:
http://code.google.com/p/bmdview2/ 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.029 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 119/119, time: 0.009 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |