Jul -- Posts by VL-Tone

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 449/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 02:29:52 AM, in Using Blender

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Hectamatatortron
I'm a beginner to 3D drawing, but I'm definitely not a beginner.

I got Blender before I saw this thread because it uses the Bullet engine that I was going to learn the API of for a homebrew game I started.

I decided to do most of the game in Blender and get it running on the PC before trying to port it to the DS and then to the Wii. I learned enough about OpenGL to be confident in my ability to import objects I draw in Blender into homebrew applications in the future.

So far I've only drawn a bullet object (not because of the humorous pun, but because I'm working on a first person shooter) and practiced enabling movement of the camera "in game" (when the game engine of Blender is active) by assigning movement directions to arrow keys (though the interface suggests the relationship is the other way around).

I just wish there was a tool for indenting surfaces using a sort of spherical shaped tool to "push" faces inward, automatically splitting the face into sub-faces as necessary. That would make 3D drawing much easier. Isn't that what the better apps do?

But hey, Google's Sketch Up might do the trick. I'm sure it's easy enough to export from Sketch Up and import into Blender.

If you need me to write any applications to convert formats, just give me the specifics of the source and destination formats and I can write something up. What exactly is VL-Tone having trouble with? Seems like he can import polygons, just not textures? We should prototype the insertion process by using a bland default texture for imported 3D models to at least test that the vertex importing functionality works.

The vertex functionality works, I already created a demo level with it.

I don't have any problems reading the .obj and .mtl files, except for the texture file paths in the .mtl file, found after the map_Kd command.

There's some lack of standards regarding the kind of path that should be there. Some programs will output an absolute path, some don't. And for a relative path, some will use ".\\" at the begining of the path name, some will not. There's also the potential issue of some program using UNIX style path (slashes instead of backslashes). Some programs put the textures in a different folder even though they are referenced by a simple relative path that doesn't include the name of the texture folder (essentially just the texture file name). These will open fine with Blender because it does a recursive search to find them.

I guess it's just laziness on my part, but I didn't want to deal with that mess.

That being said, I'm reconsidering the possibility of importing textures directly using the .mtl file. What I'll do is simply extract the filename from the path (if it's absolute) and try to open the texture file in the same folder as the .mtl file. I may also add support for a texture folder, which may be called "Materials", but this name will be hard-coded. TT64 will first try to open it in the same path as the .mtl file, then try the "Materials" folder. If it fails there won't be any recursive search. Director doesn't have built-in commands to achieve it, and it would require yet another plug-in, which may or may not be free.

This will force users to make sure that their textures are in the same folder or in a folder called "Materials".

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 450/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 04:11:06 AM, in Multi-Room levels hacking (last edited by VL-Tone at 04-26-09 01:11 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

I'm creating this thread so that we can have a dedicated place to find out more about multi-room levels and how they work. If we also manage to find more about camera mode triggers along the way, I'll change the title of the thread.

Originally posted by messiaen
Originally posted by Hectamatatortron
Originally posted by VL-Tone
As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

Eh, I could probably do it too.

Whether I will is a mystery...

We really could use some help from an experienced hacker , I have tried a few times to find for instance how hardcoded camera positions work (especially level-specific, which depends on the current "level id" at 0x8032ddf8) without success.

VL-Tone, do you have any notes about how the "room" system works?

Here's what I know:

Rooms sets are defined in the geo layout script of a level. I use to think that the 0x02 and 0x03 jump commands were used to enclose room sets since among all level geo layout scripts, only those with multiple rooms where using them, but looking back at the geo layout code, it becomes obvious that it's the 0x0B command that tells the engine that the content of the next node (between 0x04 and 0x05) will be a room set.

I call them "room sets" because each group is composed of 2 or more rooms that are connected together by doors. So the rooms don't "light" up individually, instead, groups of room all light up at once. The idea was probably to be able to create transition states where two or more rooms are lit up while Mario crosses the door in between them. Unfortunately the process is actually buggy in the real game, and you can see the other room disappearing while Mario is doing the door animation.

Down below is the level geo layout script for inside the castle, 1st floor.

And here's an old animation of mine of all three floors, which may help you visualize the structure of the level (each polygon being drawn in a different color is a 0x15 command)

In this case, almost all 0x15 commands correspond to a room, though in some cases a room is composed of two 0x15 commands (the floor and the roof).

Note that the script dumper is buggy in the current release and won't actually display the 0x02 and 0x03 commands... it's obviously fixed in my development version.

The interesting part is the "0E 00 00 11 80 29 DB D4" 0x0E "animation" command found at the root of all rooms. It tells us that there's 0x11 (17) room sets in that area, and at 0x8029DBD4 in RAM you should be able to find the code that controls which room set is chosen...

003D04D0 / 0E001400 [ 08 00 00 0A ]

003D04D4 / 0E001404 [ 00 A0 00 78 ]

003D04D8 / 0E001408 [ 00 A0 00 78 ]

003D04DC / 0E00140C [ 04 00 00 00 ]

003D04E0 / 0E001410    [ 0C 00 00 00 ]

003D04E4 / 0E001414    [ 04 00 00 00 ]

003D04E8 / 0E001418       [ 09 00 00 64 ]

003D04EC / 0E00141C       [ 04 00 00 00 ]

003D04F0 / 0E001420          [ 19 00 00 01 00 00 00 00 ]

003D04F8 / 0E001428       [ 05 00 00 00 ]

003D04FC / 0E00142C    [ 05 00 00 00 ]

003D0500 / 0E001430    [ 0C 01 00 00 ]

003D0504 / 0E001434    [ 04 00 00 00 ]

003D0508 / 0E001438       [ 0A 01 00 40 ]

003D050C / 0E00143C       [ 00 32 1B 58 ]

003D0510 / 0E001440       [ 80 29 AA 3C ]

003D0514 / 0E001444       [ 04 00 00 00 ]

003D0518 / 0E001448          [ 0F 00 00 0D 00 00 07 D0 ]

003D0520 / 0E001450          [ 17 70 00 00 00 00 00 00 80 28 7D 30 ]

003D052C / 0E00145C          [ 04 00 00 00 ]

003D0530 / 0E001460             [ 0E 00 00 11 80 29 DB D4 ]

003D0538 / 0E001468             [ 04 00 00 00 ]

003D053C / 0E00146C                [ 02 01 00 00 0E 00 0F 30 ]

003D0000 / 0E000F30                   [ 0B 00 00 00 ]

003D0004 / 0E000F34                   [ 04 00 00 00 ]

003D0008 / 0E000F38                      [ 15 01 00 00 07 02 8F D0 ]

003D0010 / 0E000F40                      [ 15 04 00 00 07 02 95 78 ]

003D0018 / 0E000F48                      [ 15 01 00 00 07 02 A6 50 ]

003D0020 / 0E000F50                      [ 15 06 00 00 07 02 AA 10 ]

003D0028 / 0E000F58                      [ 15 04 00 00 07 02 AB 20 ]

003D0030 / 0E000F60                      [ 18 00 00 00 80 2D 23 60 ]

003D0038 / 0E000F68                   [ 05 00 00 00 ]

003D003C / 0E000F6C                [ 03 00 00 00 ]

003D0544 / 0E001474                [ 02 01 00 00 0E 00 0F 70 ]

003D0040 / 0E000F70                   [ 0B 00 00 00 ]

003D0044 / 0E000F74                   [ 04 00 00 00 ]

003D0048 / 0E000F78                      [ 15 01 00 00 07 02 E4 08 ]

003D0050 / 0E000F80                   [ 05 00 00 00 ]

003D0054 / 0E000F84                [ 03 00 00 00 ]

003D054C / 0E00147C                [ 02 01 00 00 0E 00 0F 88 ]

003D0058 / 0E000F88                   [ 0B 00 00 00 ]

003D005C / 0E000F8C                   [ 04 00 00 00 ]

003D0060 / 0E000F90                      [ 15 01 00 00 07 02 FD 30 ]

003D0068 / 0E000F98                      [ 15 01 00 00 07 02 3D B0 ]

003D0070 / 0E000FA0                   [ 05 00 00 00 ]

003D0074 / 0E000FA4                [ 03 00 00 00 ]

003D0554 / 0E001484                [ 02 01 00 00 0E 00 0F A8 ]

003D0078 / 0E000FA8                   [ 0B 00 00 00 ]

003D007C / 0E000FAC                   [ 04 00 00 00 ]

003D0080 / 0E000FB0                      [ 15 01 00 00 07 03 15 88 ]

003D0088 / 0E000FB8                      [ 15 04 00 00 07 03 17 20 ]

003D0090 / 0E000FC0                      [ 15 04 00 00 07 03 18 30 ]

003D0098 / 0E000FC8                   [ 05 00 00 00 ]

003D009C / 0E000FCC                [ 03 00 00 00 ]

003D055C / 0E00148C                [ 02 01 00 00 0E 00 0F D0 ]

003D00A0 / 0E000FD0                   [ 0B 00 00 00 ]

003D00A4 / 0E000FD4                   [ 04 00 00 00 ]

003D00A8 / 0E000FD8                      [ 15 01 00 00 07 03 2F C0 ]

003D00B0 / 0E000FE0                      [ 15 04 00 00 07 03 31 58 ]

003D00B8 / 0E000FE8                      [ 18 00 00 00 80 2D 5D 0C ]

003D00C0 / 0E000FF0                      [ 18 00 01 00 80 2D 5B 98 ]

003D00C8 / 0E000FF8                   [ 05 00 00 00 ]

003D00CC / 0E000FFC                [ 03 00 00 00 ]

003D0564 / 0E001494                [ 02 01 00 00 0E 00 10 00 ]

003D00D0 / 0E001000                   [ 0B 00 00 00 ]

003D00D4 / 0E001004                   [ 04 00 00 00 ]

003D00D8 / 0E001008                      [ 15 01 00 00 07 03 4D 88 ]

003D00E0 / 0E001010                      [ 15 04 00 00 07 03 51 78 ]

003D00E8 / 0E001018                      [ 15 04 00 00 07 03 52 88 ]

003D00F0 / 0E001020                      [ 18 00 00 00 80 2D 5D 0C ]

003D00F8 / 0E001028                      [ 18 00 01 02 80 2D 5B 98 ]

003D0100 / 0E001030                   [ 05 00 00 00 ]

003D0104 / 0E001034                [ 03 00 00 00 ]

003D056C / 0E00149C                [ 02 01 00 00 0E 00 10 38 ]

003D0108 / 0E001038                   [ 0B 00 00 00 ]

003D010C / 0E00103C                   [ 04 00 00 00 ]

003D0110 / 0E001040                      [ 15 01 00 00 07 03 6D 88 ]

003D0118 / 0E001048                      [ 15 01 00 00 07 03 79 88 ]

003D0120 / 0E001050                      [ 15 01 00 00 07 03 7B F8 ]

003D0128 / 0E001058                      [ 15 05 00 00 07 03 7D E8 ]

003D0130 / 0E001060                      [ 15 05 00 00 07 03 82 40 ]

003D0138 / 0E001068                      [ 15 04 00 00 07 03 83 50 ]

003D0140 / 0E001070                      [ 18 00 00 00 80 2D 5D 0C ]

003D0148 / 0E001078                      [ 18 00 01 03 80 2D 5B 98 ]

003D0150 / 0E001080                   [ 05 00 00 00 ]

003D0154 / 0E001084                [ 03 00 00 00 ]

003D0574 / 0E0014A4                [ 02 01 00 00 0E 00 10 88 ]

003D0158 / 0E001088                   [ 0B 00 00 00 ]

003D015C / 0E00108C                   [ 04 00 00 00 ]

003D0160 / 0E001090                      [ 15 01 00 00 07 03 A6 C8 ]

003D0168 / 0E001098                      [ 15 04 00 00 07 03 A8 08 ]

003D0170 / 0E0010A0                      [ 15 01 00 00 07 02 34 C0 ]

003D0178 / 0E0010A8                      [ 15 01 00 00 07 02 35 20 ]

003D0180 / 0E0010B0                      [ 18 00 00 00 80 2D 5D 0C ]

003D0188 / 0E0010B8                      [ 18 00 01 01 80 2D 5B 98 ]

003D0190 / 0E0010C0                   [ 05 00 00 00 ]

003D0194 / 0E0010C4                [ 03 00 00 00 ]

003D057C / 0E0014AC                [ 02 01 00 00 0E 00 10 C8 ]

003D0198 / 0E0010C8                   [ 0B 00 00 00 ]

003D019C / 0E0010CC                   [ 04 00 00 00 ]

003D01A0 / 0E0010D0                      [ 15 01 00 00 07 02 8F D0 ]

003D01A8 / 0E0010D8                      [ 15 04 00 00 07 02 95 78 ]

003D01B0 / 0E0010E0                      [ 15 01 00 00 07 02 A6 50 ]

003D01B8 / 0E0010E8                      [ 15 06 00 00 07 02 AA 10 ]

003D01C0 / 0E0010F0                      [ 15 04 00 00 07 02 AB 20 ]

003D01C8 / 0E0010F8                      [ 18 00 00 00 80 2D 23 60 ]

003D01D0 / 0E001100                      [ 15 01 00 00 07 03 BA 08 ]

003D01D8 / 0E001108                   [ 05 00 00 00 ]

003D01DC / 0E00110C                [ 03 00 00 00 ]

003D0584 / 0E0014B4                [ 02 01 00 00 0E 00 11 10 ]

003D01E0 / 0E001110                   [ 0B 00 00 00 ]

003D01E4 / 0E001114                   [ 04 00 00 00 ]

003D01E8 / 0E001118                      [ 15 01 00 00 07 02 8F D0 ]

003D01F0 / 0E001120                      [ 15 04 00 00 07 02 95 78 ]

003D01F8 / 0E001128                      [ 15 01 00 00 07 02 A6 50 ]

003D0200 / 0E001130                      [ 15 06 00 00 07 02 AA 10 ]

003D0208 / 0E001138                      [ 15 04 00 00 07 02 AB 20 ]

003D0210 / 0E001140                      [ 18 00 00 00 80 2D 23 60 ]

003D0218 / 0E001148                      [ 15 01 00 00 07 02 E4 08 ]

003D0220 / 0E001150                   [ 05 00 00 00 ]

003D0224 / 0E001154                [ 03 00 00 00 ]

003D058C / 0E0014BC                [ 02 01 00 00 0E 00 11 58 ]

003D0228 / 0E001158                   [ 0B 00 00 00 ]

003D022C / 0E00115C                   [ 04 00 00 00 ]

003D0230 / 0E001160                      [ 15 01 00 00 07 02 8F D0 ]

003D0238 / 0E001168                      [ 15 04 00 00 07 02 95 78 ]

003D0240 / 0E001170                      [ 15 01 00 00 07 02 A6 50 ]

003D0248 / 0E001178                      [ 15 06 00 00 07 02 AA 10 ]

003D0250 / 0E001180                      [ 15 04 00 00 07 02 AB 20 ]

003D0258 / 0E001188                      [ 18 00 00 00 80 2D 23 60 ]

003D0260 / 0E001190                      [ 15 01 00 00 07 02 FD 30 ]

003D0268 / 0E001198                      [ 15 01 00 00 07 02 3D B0 ]

003D0270 / 0E0011A0                   [ 05 00 00 00 ]

003D0274 / 0E0011A4                [ 03 00 00 00 ]

003D0594 / 0E0014C4                [ 02 01 00 00 0E 00 11 A8 ]

003D0278 / 0E0011A8                   [ 0B 00 00 00 ]

003D027C / 0E0011AC                   [ 04 00 00 00 ]

003D0280 / 0E0011B0                      [ 15 01 00 00 07 02 8F D0 ]

003D0288 / 0E0011B8                      [ 15 04 00 00 07 02 95 78 ]

003D0290 / 0E0011C0                      [ 15 01 00 00 07 02 A6 50 ]

003D0298 / 0E0011C8                      [ 15 06 00 00 07 02 AA 10 ]

003D02A0 / 0E0011D0                      [ 15 04 00 00 07 02 AB 20 ]

003D02A8 / 0E0011D8                      [ 18 00 00 00 80 2D 23 60 ]

003D02B0 / 0E0011E0                      [ 15 01 00 00 07 03 15 88 ]

003D02B8 / 0E0011E8                      [ 15 04 00 00 07 03 17 20 ]

003D02C0 / 0E0011F0                      [ 15 04 00 00 07 03 18 30 ]

003D02C8 / 0E0011F8                   [ 05 00 00 00 ]

003D02CC / 0E0011FC                [ 03 00 00 00 ]

003D059C / 0E0014CC                [ 02 01 00 00 0E 00 12 00 ]

003D02D0 / 0E001200                   [ 0B 00 00 00 ]

003D02D4 / 0E001204                   [ 04 00 00 00 ]

003D02D8 / 0E001208                      [ 15 01 00 00 07 02 8F D0 ]

003D02E0 / 0E001210                      [ 15 04 00 00 07 02 95 78 ]

003D02E8 / 0E001218                      [ 15 01 00 00 07 02 A6 50 ]

003D02F0 / 0E001220                      [ 15 06 00 00 07 02 AA 10 ]

003D02F8 / 0E001228                      [ 15 04 00 00 07 02 AB 20 ]

003D0300 / 0E001230                      [ 18 00 00 00 80 2D 23 60 ]

003D0308 / 0E001238                      [ 15 01 00 00 07 03 2F C0 ]

003D0310 / 0E001240                      [ 15 04 00 00 07 03 31 58 ]

003D0318 / 0E001248                      [ 18 00 00 00 80 2D 5D 0C ]

003D0320 / 0E001250                      [ 18 00 01 00 80 2D 5B 98 ]

003D0328 / 0E001258                   [ 05 00 00 00 ]

003D032C / 0E00125C                [ 03 00 00 00 ]

003D05A4 / 0E0014D4                [ 02 01 00 00 0E 00 12 60 ]

003D0330 / 0E001260                   [ 0B 00 00 00 ]

003D0334 / 0E001264                   [ 04 00 00 00 ]

003D0338 / 0E001268                      [ 15 01 00 00 07 02 8F D0 ]

003D0340 / 0E001270                      [ 15 04 00 00 07 02 95 78 ]

003D0348 / 0E001278                      [ 15 01 00 00 07 02 A6 50 ]

003D0350 / 0E001280                      [ 15 06 00 00 07 02 AA 10 ]

003D0358 / 0E001288                      [ 15 04 00 00 07 02 AB 20 ]

003D0360 / 0E001290                      [ 18 00 00 00 80 2D 23 60 ]

003D0368 / 0E001298                      [ 15 01 00 00 07 03 4D 88 ]

003D0370 / 0E0012A0                      [ 15 04 00 00 07 03 51 78 ]

003D0378 / 0E0012A8                      [ 15 04 00 00 07 03 52 88 ]

003D0380 / 0E0012B0                      [ 18 00 00 00 80 2D 5D 0C ]

003D0388 / 0E0012B8                      [ 18 00 01 02 80 2D 5B 98 ]

003D0390 / 0E0012C0                   [ 05 00 00 00 ]

003D0394 / 0E0012C4                [ 03 00 00 00 ]

003D05AC / 0E0014DC                [ 02 01 00 00 0E 00 12 C8 ]

003D0398 / 0E0012C8                   [ 0B 00 00 00 ]

003D039C / 0E0012CC                   [ 04 00 00 00 ]

003D03A0 / 0E0012D0                      [ 15 01 00 00 07 02 8F D0 ]

003D03A8 / 0E0012D8                      [ 15 04 00 00 07 02 95 78 ]

003D03B0 / 0E0012E0                      [ 15 01 00 00 07 02 A6 50 ]

003D03B8 / 0E0012E8                      [ 15 06 00 00 07 02 AA 10 ]

003D03C0 / 0E0012F0                      [ 15 04 00 00 07 02 AB 20 ]

003D03C8 / 0E0012F8                      [ 18 00 00 00 80 2D 23 60 ]

003D03D0 / 0E001300                      [ 15 01 00 00 07 03 6D 88 ]

003D03D8 / 0E001308                      [ 15 01 00 00 07 03 79 88 ]

003D03E0 / 0E001310                      [ 15 01 00 00 07 03 7B F8 ]

003D03E8 / 0E001318                      [ 15 05 00 00 07 03 7D E8 ]

003D03F0 / 0E001320                      [ 15 05 00 00 07 03 82 40 ]

003D03F8 / 0E001328                      [ 15 04 00 00 07 03 83 50 ]

003D0400 / 0E001330                      [ 18 00 00 00 80 2D 5D 0C ]

003D0408 / 0E001338                      [ 18 00 01 03 80 2D 5B 98 ]

003D0410 / 0E001340                   [ 05 00 00 00 ]

003D0414 / 0E001344                [ 03 00 00 00 ]

003D05B4 / 0E0014E4                [ 02 01 00 00 0E 00 13 48 ]

003D0418 / 0E001348                   [ 0B 00 00 00 ]

003D041C / 0E00134C                   [ 04 00 00 00 ]

003D0420 / 0E001350                      [ 15 01 00 00 07 02 8F D0 ]

003D0428 / 0E001358                      [ 15 04 00 00 07 02 95 78 ]

003D0430 / 0E001360                      [ 15 01 00 00 07 02 A6 50 ]

003D0438 / 0E001368                      [ 15 06 00 00 07 02 AA 10 ]

003D0440 / 0E001370                      [ 15 04 00 00 07 02 AB 20 ]

003D0448 / 0E001378                      [ 18 00 00 00 80 2D 23 60 ]

003D0450 / 0E001380                      [ 15 01 00 00 07 03 A6 C8 ]

003D0458 / 0E001388                      [ 15 04 00 00 07 03 A8 08 ]

003D0460 / 0E001390                      [ 15 01 00 00 07 02 34 C0 ]

003D0468 / 0E001398                      [ 15 01 00 00 07 02 35 20 ]

003D0470 / 0E0013A0                      [ 18 00 00 00 80 2D 5D 0C ]

003D0478 / 0E0013A8                      [ 18 00 01 01 80 2D 5B 98 ]

003D0480 / 0E0013B0                   [ 05 00 00 00 ]

003D0484 / 0E0013B4                [ 03 00 00 00 ]

003D05BC / 0E0014EC                [ 02 01 00 00 0E 00 13 B8 ]

003D0488 / 0E0013B8                   [ 0B 00 00 00 ]

003D048C / 0E0013BC                   [ 04 00 00 00 ]

003D0490 / 0E0013C0                      [ 15 01 00 00 07 02 8F D0 ]

003D0498 / 0E0013C8                      [ 15 04 00 00 07 02 95 78 ]

003D04A0 / 0E0013D0                      [ 15 01 00 00 07 02 A6 50 ]

003D04A8 / 0E0013D8                      [ 15 06 00 00 07 02 AA 10 ]

003D04B0 / 0E0013E0                      [ 15 04 00 00 07 02 AB 20 ]

003D04B8 / 0E0013E8                      [ 18 00 00 00 80 2D 23 60 ]

003D04C0 / 0E0013F0                      [ 15 01 00 00 07 03 BA 08 ]

003D04C8 / 0E0013F8                   [ 05 00 00 00 ]

003D04CC / 0E0013FC                [ 03 00 00 00 ]

003D05C4 / 0E0014F4             [ 05 00 00 00 ]

003D05C8 / 0E0014F8             [ 17 00 00 00 18 00 00 00 80 27 61 D0 ]

003D05D4 / 0E001504          [ 05 00 00 00 ]

003D05D8 / 0E001508       [ 05 00 00 00 ]

003D05DC / 0E00150C    [ 05 00 00 00 ]

003D05E0 / 0E001510 [ 05 00 00 00 ]

003D05E4 / 0E001514 [ 01 00 00 00 ]

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 451/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 04:14:03 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-26-09 01:14 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by messiaen
Originally posted by Hectamatatortron
Originally posted by VL-Tone
As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

Eh, I could probably do it too.

Whether I will is a mystery...

We really could use some help from an experienced hacker , I have tried a few times to find for instance how hardcoded camera positions work (especially level-specific, which depends on the current "level id" at 0x8032ddf8) without success.

VL-Tone, do you have any notes about how the "room" system works?

To avoid going out of topic, I've created this thread: http://jul.rustedlogic.net/thread.php?id=4825 where we can discuss multi-room levels.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 452/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 04:41:40 AM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!) (last edited by VL-Tone at 04-26-09 03:43 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

One other setting that should be on is "triangulate", as the TT64 importer can't deal with polygons with more than 4 sides (triangulate will produce only triangles).

Question: did you create the "Materials" folder yourself or was it created by blender? The .mtl file contains the texture filenames, but without the \Materials\ folder needed to find them.

Here's how it look in the importer, with only one texture:

On the sides of the "skyscrapers", some parts of the texture are smeared up to the point of becoming lines instead of a
mesh, is it a problem on your side or in the importer? (I couldn't make the textures appear in blender to compare).

I'm going to use your model to try to implement multi-texture importation directly using the .mtl files. I'll keep you updated with the results...

Edit:

Hmm... That looks more like it?

I'm sure there are some bugs to be fixed, but at least it shows that I can do direct texture importing using .mtl files (note that I already wrote some code a while ago to do most of the work).

Before you guys get too excited, this is from the 3d preview in the importer, there are still a few things to be done until I can have this model inside the game, though the multi-texture aspect is not complicated to implement when generating the SM64 drawing lists.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 453/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 07:21:58 PM, in ToadsTool Suggestions (last edited by VL-Tone at 04-26-09 04:24 PM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Gecko
It would be nice having an indicator for Mario's size when importing an .obj file being asked to scale the level geometry.

That's a great idea!

I'll add it, probably a sphere, since Mario's collision is spherical.

Originally posted by Me-me
1. Being able to scale the model once it's imported, so it'll fit inside the boundraries.

There's already a manual scale feature, and an "auto scale" button that will maximize the size of the level to fit within boundaries. This feature is necessary since some 3d programs will output fractional units (-1.0 to 1.0) while others use integer units.

Originally posted by gamekrazzy
I do not think it impossible though. Because TT64 loads everything from a given level script, starting from a pointer and so forth. If VL-Tone added an extra flat world, and pointed the pic pointer there, he could obviously include it in TT64 because then there would be less difficulties because n ow the level has all the required scripts. The only one he would have to work on is the warps.

It's possible but there may be some special camera mode that will be triggered when entering the level. We don't know yet how to edit these...

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 454/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 08:33:59 PM, in Using Blender

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Gecko, the second screenshot is exactly the kind of interface I was planning to build. And a similar interface will be needed anyway since there are some additional parameters to be set for each texture even when they're automatically imported using the .mtl file. "Use transparency" for example, and other parameters that may be added in the future that are particular to the SM64 engine and are not easily transferable using the .obj file format.

The main difference though, is that to stay consistent with the way the importer works, texture will be managed inside the level file not inside the ROM, since the former which contains everything needed to create your levels. The textures are only saved to the ROM when you save your level there, with the rest of the data.

So instead of "Select texture from ROM" and "Load new texture into ROM", I'll put an "Import Texture" and "Export Texture" that will import/export textures from external bitmap files.

Here's how it will work:

-You open the ROM in TT64.
-Go to the level importer.
-Create a new level file (or open an existing one)
-Import an .obj file.
-Materials are listed.
-If the importer can find the texture files using the .mtl, those are imported and automatically associated with the Material groups.
-If the importer cannot find the external textures using the .mtl, blank/default textures will be used.
-You can then manually import textures into materials whether the textures where already imported or not.
-Save the level file.
-Save the level to ROM.

Now... it all seems easy until this problem arises:

The .obj data, all the importing parameters (scale, offset, banks etc.) and the texture themselves as well as their names are all saved into the .T64 level file.

The idea is that this file can be used to recreate the level inside another ROM, or if you want to update the .obj data for a given, you don't have to set all the import parameters all over again.

But let's say you open a level file where you manually imported textures. Once you open it, everything will be fine, the textures will be automatically associated with the materials etc. But what if you want to update the .obj data? You can hit the "Import .obj" button and do that....but the default behavior will be to completely replace the current textures and materials with those found using the .obj and .mtl files, so you lose your custom textures and will have to reimport/associate each of them again.

I guess I can make a "keep existing textures" checkbox so that when you import an updated .obj you can keep those that were originally in the level file. But what if either the material or texture names have changed since the last import? TT64 won't be able to associate these textures and they'll become inaccessible via the interface.

Anyway, I'm not saying it's impossible to deal with these problems, but it certainly makes it more complicated.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 455/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-26-09 08:39:03 PM, in ToadsTool Suggestions

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by gamekrazzy
Yeah... I noticed that there is a radial around y axis for "Haunted Mansion" when it is flat world. So if I were to make an educated guess, I would think that the camera mode for that level would be still camera.

I have something else to say. from what I have thought up here, logically the camera type for levels are not located in the level script, because then the camera type would all be the same.

I am going to replace the picture level with a flat world, and test it to find out what happens. I will PM you the results.

There's many more camera triggers to be found when you replace the Haunted Mansion with flatworld.

In case you didn't know, I already experimented replacing all levels with flatworld (except the end picture) to test the cameras in each level.

And we already know that the camera triggers are not in the level script, that's why we're looking for them elsewhere.

As for "PMing" me the results... Why would you do that? This should be posted in the forum, just like any discovery, so that everyone here knows about it.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 456/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-27-09 04:16:52 AM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!) (last edited by VL-Tone at 04-27-09 01:18 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Gecko

This is probably caused by flipped normals. Only the top side of a plane can be assigned a material wheras the bottom side always is invisible, because you won't ever see it ingame, unless you leave the map boundaries, of course.
When opening the map inside Blender, I cannot see a flipped normal (invisible face), but let's see how we can fix this issue:

I don't think it has anything to do with normals. The 3d preview inside TT64 doesn't use them, they are generated automatically.

I opened the obj file inside another 3d program (Wings 3d) and textures show the same glitches at the same places. Note that you can't really see the glitches inside Blender because the texture scaling is so low.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 457/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-27-09 04:41:06 AM, in 3D Model importation explained

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Thanks RomanianGirl, there's a lot of interesting information there.

But Mario does have a skeleton-like hierarchy structure in the ROM. I had to modify it for the Luigi mod. Not only the body parts polygons were strectched, but also the skeleton.

And it is possible to replace Mario's body parts considering what we know now, and stretch the skeleton to accommodate the new body parts sizes. One of the early hacks I did was replacing Mario's head with Peaches.

The main problem we have is that we have to leave the skeleton structure intact, as the animation code depends on it. We can modify the position of body part joints, but not the number and hierarchy of body parts. That's why we can't directly use the Peach model, because she doesn't have legs, and she has a pony tail. Same goes for Yoshi, which doesn't have a matching humanoid body part structure.

And as you said, we don't have enough knowledge of Mario's animation code to make any drastic changes to it's body structure.

As for the vertex problem you highlighted, it comes from the fact that vertex items in the SM64 engine also contain vertex coloring/normals and texture coordinates. That means that while two triangle could use the same vertex located at the same coodinates, they might end up using two different vertex items because each needs to have different vertex colors/normals or texture coordinates. It wouldn't be that hard to fuse vertices using the same position so that they can be moved together.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 458/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-27-09 10:38:10 PM, in Meaningless Gibberish Theories (Formerly: Cake Picture... A level?)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Bob-omb8194
I read off of Yoshiman's site a while back that there was going to be 32 levels, but I can't find it now... Also, each opening screen video counts as a individual level in the Level Select. (The blank ones.)

From this article http://www.zeldalegends.net/index.php?n=interviews&id=1996-01-np080-miya-tezu&m=html

Power: "How much of the game is finished?"

Tezuka: "About 2-% of the mapping has been completed, but about 50% of the entire game is ready. Currently, we have 32 courses, but the final version may have more. Maybe 40 courses. That doesn't include bonus areas, of course." (Big smile. They aren't giving anything away, yet.)

Blank levels in the Level Select simply "reset" the game to the title sequence since their Level IDs are not found in the conditional jump list.

Originally posted by gamekrazzy
Yeah... after further looking into this.. Turns out there are plenty more level areas capable of being used.

You see each level has a conditional jump for it, so when looking through the menu level script I have found that there are indeed ones for other stuff. I believe there is a document on the level script in that case.

That brought to my attention. Yes, maybe we could add more levels in place of these seemingly unused levels, such as 00 - 03. And others... But then I realized. Those levels may actually pertain a use. looking back a few bytes from the conditional jumps, I found several more. These pertain to the times when the game wants to start from the menu. so after a Game Over, it wants to start a certain position inside the beggining menu area. Or when the game ends, this would be how it jumps to the begging level script.

We know since the early days of SM64 hacking that there are some unused level IDs. More recently I also found level table that sets some parameters for each one, and it does have some unused slots in it. You should read this post: http://jul.rustedlogic.net/thread.php?id=2794

Excerpt from the post:

At 0xE8D98, (which is incidentally inside the checksum protected area) you'll find this list of bytes:

00 00 00 05 04 00 06 08 01 0A 0B 03 0D 0E 0F 00 10 16 11 18 12 07 09 02 19 00 13 14 15 10 17 00 11 12 00 0C

You must know that each level has a byte ID, used for example by warps. The 0x0C commands you can find in the SM64MainLevelScripts.txt doc will conditionally branch to the corresponding level script when the "current level ID" variable is set by a warp command. The 8th byte of the 0x0C command refers to the level ID, and in the doc you can see to which level each command correspond.

Originally posted by gamekrazzy
Expiramenting with this I found that if I change the cake's conditional jump to a level it does not corrispond to, it starts from the begining(Unused). What this leads me to believe is maybe the unused levels are actually suppose to jump somewhere else, but have been changed so that instead of new levels there would be use of gameover and such.

There's no unused conditional jumps in the current game, all the ones that are found in the main level hub script are used by the game.

I'm not sure what you've done, but if you change the level ID of a level in the jump table to one which is unused, the game will simply skip over it.

Originally posted by gamekrazzy

Hmm... Does this mean that there might be Beta levels inside SM64's code somewhere. Or that there is suppose to be....?

NO.

Trust me, there are no Beta levels inside SM64. I know the ROM well enough to tell you that without an ounce of doubt. Believing that there are Beta levels inside the ROM is like believing that Luigi is in the original game. There's simply no way we could've skipped over some unused level data. All level polygons in the game are stored in their own individual MIO0 banks, and we know what's in every single MIO0 bank in the game since a long time.

The only unknown parts of the ROM left are some little blobs of data that may hold very interesting tables and other stuff, but none of them contain polygon data.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 459/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-28-09 01:57:41 AM, in Meaningless Gibberish Theories (Formerly: Cake Picture... A level?) (last edited by VL-Tone at 04-27-09 11:24 PM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

gamecrazzy:

What you're doing is essentially trying to explain in a confusing way what we already know since a long time, thinking it's a new discovery...

Sure we can insert a new 0x0C command with Level ID 01, 02 or 03 that will point to custom levels. We can easily create warps that will go there, simply by using the corresponding ID (0x01 for example). This is nothing we didn't know about.

But there's a few things that you forget or doesn't know.

Did you read the post I told you about in the Stuff inside the checksum protected area (Title Screen, etc.) thread? It's the first post.

Look at the table at 0xE8D98:

00 00 00 05 04 00 06 08 01 0A 0B 03 0D 0E 0F 00 10 16 11 18 12 07 09 02 19 00 13 14 15 10 17 00 11 12 00 0C

Interestingly, bytes 1, 2 and 3 of this table are set to 0x00. This is not a coincidence, except for the Castle Grounds, Inside Castle and Courtyard levels (which happens to have a value of 0x00), every 0x00 in this table corresponds to an unused level ID.

From the post you should've read:

00--01--Not in level selector

00--02--Not in level selector

00--03--Not in level selector

05--04--Haunted House

04--05--Cool Cool Mountain

00--06--Inside Castle

06--07--Hazy Maze Cave

08--08--Shifting Sand Land

01--09--Bob-Omb's Battlefield

0A--0A--Snow Man's land

0B--0B--Wet Dry World

03--0C--Jolly Roger Bay

0D--0D--Tiny Huge Island

0E--0E--Tick Tock Clock

0F--0F--Rainbow Ride

00--10--Castle Grounds

10--11--Bowser First Course

16--12--Vanish Cap

11--13--Bowser's Fire Sea

18--14--Secret Aquarium

12--15--Bowser Third Course

07--16--Lethal Lava Land

09--17--Dire Dire Docks

02--18--Whomp's Fortress

19--19--Picture at the end

00--1A--Castle Courtyard

13--1B--Peach's Secret Slide

14--1C--Metal Cap

15--1D--Wing Cap

10--1E--Bowser First Battle

17--1F--Rainbow Clouds

00--20--Not in level selector

11--21--Bowser Second Battle

12--22--Bowser Third Battle

00--23--Not in level selector

0C--24--Tall Tall Mountain

The second column is the level ID, and the first is the byte in the 0xE8D98 table that correspond to this level ID.

There's only 5 slots left in this table, which has a fixed length. ID 01, 02, 03, 20 and 23 are unused.

We can't put add more than 5 "new levels" because of that, unless we find how the ASM code use this table and extend it.

Also, we don't know yet where are the parameters referred by each bytes in the E8D98. They do correspond to the level names order you can find in the Text Wrangler. For example, the value in the table for Hazy Maze Cave is 0x06, and its name is sixth in the level name list. The blank level name is attributed to the Cake Picture level.

But there are other parameters that are selected by the table values other than the name.

Even if we did use the 5 empty slots for custom levels, there would be a lot that we wouldn't be able to control, like the names and many other parameters. If you keep the 0x00 values in that table, they'll simply behave like the outdoor castle levels, with no way to exit the level by pausing, and no way to set the level name.

Edit:

Ok so you edited your post and added this:

Originally posted by gamekrazzy

Ok... I did a little more research. Guess what you can replace the title, mario's face, and even the game over so that it will go to a different location. The last 2 bytes of 16 bytes hold the answer. A little while ago I did an expirament. After swapping those bytes with other levels. I went and activated that situation.

The order for those bytes via level normally go:
02 38
02 48
02 58
02 28
02 68

What I did is I changed it so that it went like this:
02 28
02 38
02 48
02 58
02 68

The results were as suspected.
So now, I believe if we simply find out what these bytes have to deal with the level, we will know how to change them to where we can add levels to the unused levels. That is if we know where the conditional jump is at.

Seriously gamekrazzy, we've been hacking SM64 for like 3 years now? Don't you think we know how the conditional jump table works? How do you think that TT64 decodes levels? Magic Ponies?

Maybe you should spend more time experimenting by yourself before posting about "mysterious" bytes that we already know about...

2ABE8C/01EC:  0C 0C 02 00 FF FF FF FF 15 00 02 38 --End Screen

The last four bytes are the jumping offset: 15 000238

0x15 is the bank number, 0x000238 is the offset in that bank. If you had read the Main Level Script document more carefully you would've known that these commands are already inside bank 0x015 so it's simply a matter of going down a few lines to find the destination:

2ABED8/0238:  01 10 00 0E 00 4A C4 B0 00 4A C5 70 0E 00 00 00

See that 0238? it means that this line is at offset 0x0238 inside the current bank, which happens to be 0x15...

The 0x01 command will load data from 004AC4B0 to 004AC570 into bank 0x0E then jump into offset 0x000000 of bank 0x0E. At 004AC4B0 you'll find the ending screen script...

If you look at the destination offsets for the normal levels, you'll find that they lead to 0x00 commands found just a few lines bellow.

For example:

2ABF58/02B8:  0C 0C 02 00 00 00 00 09 15 00 [b]04 58[/b] --Bob-Omb's Battlefield

Leads to:

2AC0F8/[b]0458[/b]:  00 10 00 0E 00 40 5A 60 00 40 5F B0 0E 00 02 64

The level script for Bob-Omb Battlefield is at 0x00405A60. Yes we can change these address so that they point to custom levels, and that's exactly how flatworld worked and how the importer will work. We could also insert new 0x0C and 0x00 commands to use other level ID while keeping the original levels, but I already explained that there are other problems with this.

Edit:

I could've spent the last hour or so working on TT64, but instead I just had to explain what is already known since 3 years or so...

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 460/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-28-09 03:08:29 AM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!) (last edited by VL-Tone at 04-28-09 12:08 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Gecko
I'm having a hard time reproducing the error and determining the cause for it in Blender after having changed the material file to a hi-res one. Could you tell me where exactly these/one of these glitches appear at?
There could probably be overlapping faces if they appeared at one of the ledges (the lower platforms in front of the skyscrapers).

Here's the glitches, circled with some awesome yellow paintbrush

Now, I think I've found the cause of the problem by investigating more:

The glitches happen because of the "Triangulate" option, which doesn't seem to correctly triangulate the UV map after it's done, looking at the UV map of the triangulated export, it seems that one triangle out of two on the side of the skyscrapers is buggy (those pointing down, in a "V" shape).

To fix that, triangulation should be made inside Blender before the export (I think it's ctrl-t?), and before you edit/create your UV maps.

But that's only for to the glitches on the sides. Those happening on the little path on the bottom right really seem to be because those weren't assigned UV coordinates in the first place (it also happens in the non-triangulated .obj version) and they essentially happen on every triangles in the non-triangulated version (there's only a few triangles).

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 461/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-29-09 04:18:14 AM, in Using Blender

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Gecko

The test maps from Mario 64 DS (video link) give a good overview on the texture attributes and ground types. The player reaches these at about 1:30 in the video where you will see those kanji on the ground.
Are these attributes already connected to the existing textures in the game or do these always have to be applied anew when assigning textures in a newly imported level?
The first point would be the easier way, because that would mean once one's importing a new texture he could be asked which attribute to apply to the texture instead of having to change attributes whenever he's applying a texture to a vertex/material group when importing a new .obj file.

In the SM64 engine, terrain attributes are defined by the collision map, they're completely independent on texture and materials.

It was originally planned for 0.6 that you'd be able to set the terrain attribute for the whole level (Shown in the interface as "Collision Terrain Type"). In version 0.7, I wanted to allow setting the terrain attributes for vertex groups and even individual polygons.

But with the new direction 0.6 is taking, I think it would make more sense to set terrain attributes for materials instead of groups. That would make it so much simpler for the users. And if you really want two areas that have the same texture but two different terrain attribute, you could always create two materials with a different name and a different file name for the texture, even though the actual bitmap would be the same.

Originally posted by Gecko

With regard to your container based level file system (.T64 level file), that will be the best option. Will you be able to extract all files from your level container once it has been created (extracting .obj and material files and so on)?

It was not planned, but it's a good idea , I'll probably implement it, though it may be in 0.6.1 or another future version.

Originally posted by Gecko

Assuming that I'd like to load a level from the ROM without having any of its original data, because that level was created by someone else, for instance, will it be possible to create a container from a ROM level file by which I mean reversing the whole process? If that reversed process would mean too much programming, maybe it could be useful having a copy of the container (.T64 level file) inside the ROM making it possible to extract it easily if intended.

Well it wouldn't be simple to reverse the process.

Also, you shouldn't use a level from someone else without having his permission, and if you have to ask, you might as well ask for the original .T64 file. Mod creators could also bundle their .T64 (and .obj files) with the ROM patch if they choose so.

The limitation is not there because of these reasons, I didn't willingly implement some kind of copy protection, but I think that in "normal" situations, not having the ability to extract a .T64 from the ROM won't cause any major problems.

As for including a copy of the .T64 file in the ROM, it would end up taking too much space.

Originally posted by Gecko

Reassociating textures to a vertex/material group from the .obj file will not be too much work since there will be just as few as maybe 15 textures inside a level.
I think that attributes, scale and so forth could be connected to the texture which will finally be associated from the ROM. As soon as you are assigning that texture to a vertex/material group again, its attributes will be applied.

1. import obj
2. assign "grass" texture to "material group 2"
3. scale, rotate it... for instance there will be the following values: "scale 3", "rotate 167"...
4. save .T64 level file.

Now these attributes "scale 3" and "rotate 167" will be connected to the "grass" texture inside the .T64 level file.

5. open .T64 level file
6. import an updated obj overwriting the old one - now all materials will have to be reassigned
7. assign "grass" texture to "material group 5"
8. user will be asked to apply existing attributes

As soon as the "grass" texture would be assigned to more than one material group, both attributes would have to be saved into the .T64 level file. When the user updates the object file and applies the "grass" texture onto a material group he will be asked if he wants to adopt the first or second (or third or fourth...) attribute data with the possibility of previewing each settings.

This will only make sense as long as there will not be 130 material groups of which 25 would be assigned the "grass" texture.

This is getting too complicated. I'll have to think about it like tomorrow, I'm getting tired and can't wrap my brain around a simple solution...

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 462/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-29-09 07:48:06 PM, in Using Blender (last edited by VL-Tone at 04-29-09 04:48 PM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Gecko
Maybe it would be easier having TT extract all textures from the ROM saving them numerized (first texture is named 001.png and so on) inside "ToadsTool/Materials" folder allowing to use these for the creation of levels.

While creating a level with an editor (e.g. Blender), the user would take all materials out of the "ToadsTool/Materials" folder.

When TT then imports .obj and .mtl file, it would not matter if the .mtl file included absolute or relative paths, because TT would just import the image files from the "ToadsTool/Materials" folder.

I will just leave the main idea the way it is in order not to make it too complicated until you think it would be realizable.

TT64 already includes a feature to save all textures into a folder. I don't think I'll integrate this process into the importer.

Before anything else, I want the thing to be able to import textures directly using the obj/mtl file. The only requirement will be to put the texture files at the same directory level as the .obj file. Absolute/relative paths won't matter, since I'll only extract the file names from the .mtl file, not the rest of the path.

Being able to manually import textures will only be a bonus feature, I will encourage people to manage textures in Blender or their favorite 3d program instead.

For now I'll focus on making the basic functionality actually work. The actual .obj importer code still wasn't ready to use the new multi-level feature, nor multi-texture models. Last night I managed to make it work for the first time, using your model as an example, though there are still some bugs, like texture coordinates being messed up (even though they're now perfectly fine in the 3d preview). I'll post some screenshots and probably some video when I resolve these issues.

Something I discovered while testing your model in the game, and it was something I already thought would happen, is that the SM64 collision engine is pretty buggy, there were a few places in your level where Mario simply fell through the ground. I'm sure that the original levels were tested again and again to get rid of these kind of issues (even modern games are throughly tested for holes/problems in the collision map).

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 463/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-30-09 05:34:28 AM, in Using Blender

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Ok I've fixed most of the texture problems I had with in-game textures. Turn out that your texture coordinates included negative numbers, and the SM64 drawing engine requires positive numbers. A temporary fix was to find the lowest negative value, then substract it from all texture coordinates so that their minimum is zero.

It fixed every texture problems except one, that you can see in this screenshot:

It only affects the brown texture found on the side of the hills. While those display perfectly in the TT64 3d preview, they do that in the game...

One thing to note is that while Blender and the .OBJ format provide U,V texture coordinates, the N64 engine uses S,T coordinates. I have a hard time finding on the web any clear explanation of the difference between the two formats and a straightforward way to convert between the two systems. I managed to convert the S,T coordinates into U,V coordinate in TT64 to display levels and models in the editor, but it was by trial and error and I'm still not sure how I've done it (it's some very early code in TT64 that I haven't touched since it worked).

I've found some pages that seem to say that UV and ST coordinates are the same thing, while other seemed to say that converting between them was a complicated process.

Anyway it seems that a direct use of UV coordinates works for all textures in your model except the brown one. Did you do anything special to that texture in particular (some kind of special scaling maybe?). Maybe it has something to do with the unwrapping process, as those particular polygons are mostly vertical, and they're unwrapped differently (flat on their side) in a way that makes them incompatible with S,T coordinates?

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 464/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 04-30-09 07:18:24 AM, in Using Blender (last edited by VL-Tone at 04-30-09 04:20 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Well that didn't work, the textures are as messed up on the sides, and now a few triangles on the other textures on the floor as messed up too

Maybe we could try with a very basic shape like a textured cube, so I can try to debug the thing manually. It may well be a bug in my code, or maybe observing the data up close will enable me to find how to convert the UV textures correctly. For now there are too many polygons for me to pin-point where the problem is.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 466/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 05-01-09 06:21:06 AM, in Using Blender (last edited by VL-Tone at 05-01-09 03:21 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Ok forget about the S,T/U,V translation problem, that had nothing to do with it.

There was something definitely screwy on TT64's side. Because of a mistake, the N64 polygon command encoder was using ridiculously large texture coordinates numbers (in the range of 50,000) but somehow it worked for some range of values like the ones used in floor polygons.

Here's the result with the bug fix:

This is with multiplying the provided texture coordinates by 50. Using a lower number will result in lower texture density, and using an higher number results in higher density, except that going over about 50, some texture on the sides begin to get screwed much like they were with the other bug.

It seems to have to do with the fact that these texture repeat much more in a single polygon than the floor textures, maybe it's a limitation of the N64 drawing engine, and that there's a maximum number of times a texture can get repeated on a given polygon. Or maybe again it's a bug in TT64.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 467/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 05-01-09 01:46:22 PM, in Using Blender (last edited by VL-Tone at 05-01-09 10:54 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by Gecko
some texture on the sides begin to get screwed much like they were with the other bug.

This must be an error in my level. Have you tried importing the latest obj file into Mario64?

The former obj file included some faces with scaling issues like on this screenshot:
...

If you look at the top, there's a face with a wrongly scaled face next to the "entrance" of the walk-in skyscraper. I had created an uv map for each of the wrongly scaled faces and they had different scaling values.

The latest .obj should have most if not all UV map problems fixed.

I did use the newer version and I did notice that the old one had some UV coords errors. But the bug happens precisely when I scale the textures over a certain amount, even with the new version.

But if the multiplying value is 50 or lower, all textures are perfect (there are still like 3 little triangles on the floor that are messed up, but I'm pretty certain it's a little mistake on your part, is these show in the 3d preview and in Wings 3d).

Originally posted by messiaen
(In reply to VL-Tone's last post)
Looking really great! It seems that Mario64 collision just fails on certain angles. The lightning ingame looks a bit weird, are the vertex normals correct?

I think that the normals are correct, by I may be wrong, the axis may be swapped or something. The floor on the left of Mario seems a little messed up, but it's because of that lower ground part (which is in front of the little bridge). Another thing, it seems that the texture setting I'm using is used for "flat shaded" polygons, and I should turn on "smooth shading" (aiming at making it a parameter that you can set for each material in TT64.)

It is somewhat dark though, I actually had to brighten the brown texture because it was turning out to be too dark on the sides.

But there is some other weird lighting bug happening when I offset the level geometry on the horizontal plane by a certain amount. Every texture becomes tinted with dark orange light. I really don't understand why the level position could result in this problem?

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 468/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 05-01-09 02:14:53 PM, in SM64 Sound Hacking (last edited by VL-Tone at 05-01-09 11:16 AM)

Link

Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42

Originally posted by messiaen

I'm almost certain the sample rate is constant, what changes is just the pitch of the sound produced. For instance, all Mario ingame sounds are transposed two semitones down.

There is no automatic way to rip the sounds in the right pitches because this information is a very complicated set of data, basically in the same format as the sequenced music but called " on demand" for each individual sound. The control.h isn't of help here.

Unless you use some Fourrier transformation to be able to change the pitch while keeping the sound length constant, changing the pitch of a sound is equivalent to changing the assumed sample rate of the sound.

The sound engine more than probably has some base sample rate matching a particular base note on the scale. Probably C or A. So playing a sound with note C at some octave will be equivalent to playing the sound at the base sample rate (which may be 16khz or 22khz, I don't know). If the sound is played at an octave higher than that, it is functionally the same as assuming that the original sample rate is doubled (like 44khz for example).

The original sample rates of the different samples may not all be the same, but the sound engine compensate by playing them at different pitches, even as the original sample rates values may well not be in the ROM.

So RicoElectrico, to answer your question, you'll have to find yourself what was the original sample rate of each sound, and change it using a program like Audacity (which I'm pretty sure can change the assumed sample rate).

____________________

Register - Login
Views: 99798778	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	05-03-22 06:12:28 AM

Query execution time:	0.205189 seconds
Script execution time:	0.106536 seconds
Total render time:	0.311725 seconds