messiaen
Catgirl
Level: 68
   
Posts: 957/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
New release with some major improvements!
Level Importer v14
New features/changes:
- Set Lakitu Camera Presets for each custom level
- Disable some hardcoded camera settings (ROM settings menu)
- Custom music management tools: insertion, extraction, changing instrument sets
- New star positions (Bully Bosses, Boo Bosses, Eyerock, Penguin, Klepto, Wiggler, Mr. I, Treasure Chests, Piranha Plants, Peach Slide)
- New trajectories (Moving carpets, Checkboard Platforms, Metal Balls)
- Set peach slide timer limit
- Fixed problem with Fog colors
- Fixed restore option
- .Obj files with up to 6500 faces are now supported (previous limit was 6000) |
messiaen
Catgirl
Level: 68
Posts: 958/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
YoshiElectron has done some codes to modify the coins colour, you can see what it modifies in RAM and search that in the ROM.
Never looked at the grayscale textures, but the colours are probably part of the vertex data (will dig up some information on that later). |
messiaen
Catgirl
Level: 68
Posts: 959/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
N64 textures often use the 16-bit RGBA 5551 format Joe described, however polygon colors are actually 24-bit, so it's actually easier to modify.
Here's a guide how to find and modify any color using Toad's Tool script dumper. Warning: this will only work on grayscale textures and colored polygons (such as those used in Mario body parts, Goomba's, etc).
1 - Go to Preferences -> Script Dumps to start the script dumper.
2 - Go to Polygons and choose the object (in this example, the Red Coin).
3 - Find all 0x04 commands, which are used to load the vertex data:
00AB9D64 / 03007958 [ 04 30 00 40 03 00 57 40 ]
00AB9D8C / 03007980 [ 04 30 00 40 03 00 57 40 ]
00AB9DB4 / 030079A8 [ 04 30 00 40 03 00 57 40 ]
Since they are the same, our work will be simple.
4 - The relevant part is the last four bytes: [03] [00 57 40]. The first byte (0x03) is the bank number and the last three bytes (0x5740) the offset.
5 - There is actually just one Bank 3, a huge bank which contains objects shared by all levels. We know that its ROM location is 0xAB240C (either by finding a level which contains that object/bank or by looking at VL-Tone docs)
6 - Now we add 0x5740 to 0xAB240C to find where that vertex data is on the ROM. Before we proceed, let's look back at that 0x04 command above:
04 [30] 00 40 03 00 57 40
This second byte (0x30) tells how many vertexes are loaded. Rule: Sum up 0x10 bytes to that value.
7 - Now open your hex editor, go to 0xAB7B4C (0xAB240C + 0x5740) and look at the next 0x40 bytes of data:
FFDD 0000 0000 0000 0000 07C0 [FF00 00FF] (vertex 1)
0023 0000 0000 0000 07C0 07C0 [FF00 00FF] (vertex 2)
0023 0046 0000 0000 07C0 0000 [FF00 00FF] (vertex 3)
FFDD 0046 0000 0000 0000 0000 [FF00 00FF] (vertex 4)
Each vertex entry is 0x10 long. The last 4 bytes are what you are looking for: 3 bytes for the RGB value and another one for alpha. |
messiaen
Catgirl
Level: 68
Posts: 960/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Originally posted by Me-me
This helped a lot, and now I've successfully changed the colours of all coins 
While greyscale textures uses the same 0x04 command lines,
3D objects have different ones, like the bowser key (offset 0xAB240C):
[list]
Well... what do I do? There are multiple references.
You'll have to experiment changing each one. There are more references because the polygonal structure of the key is much more complex (the coin is a simple square, the texture combined with transparency gives the illusion of a highly detailed object).
A reminder: the offset is actually 3 bytes, not 2:
04 F0 01 00 03 [01 56 F8] (0x156F8) |
messiaen
Catgirl
Level: 68
Posts: 961/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
There is no easy correlation between the size of a MIDI file and the .m64 output, it depends how the data is laid out. As for the size problem (14k being the limit of a .m64 file currently), that's because bigger sequences overflow the destined area in RAM (not ROM) and end up corrupting nearby music data.
I have been trying to get them to load into extended memory, which would overcome this limitation, however so far it has proven to be a very complicated task because there seems to be a specific memory pool for music data. |
messiaen
Catgirl
Level: 68
Posts: 962/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
To Me-Me: nothing has changed in the last version when it comes to handling texture coordinates.
The thing is, since Google SketchUp lacks better material mapping options (texture scaling mainly), you'll have to adjust your modelling so that the textures don't repeat themselves too much.
The first big modelling error is to create a big plane to get an idea of the total modelling area and then applying a texture which will be repeated multiple times. If the textures repeats way too many times, erase that plane, create a MUCH smaller one (zoom in!) and apply the texture again and see how texture repeats themselves in a much more natural fashion (when it comes to the N64).
I have watched countless videos on YouTube where this happens: textures are repeated too much, and even if the texture is mapped correctly, if the plane is big you can see as mario walks away that the textures in the "horizon" became a mess of pixels.
Go play the original levels and you won't find big squareish-areas, instead there are small polygons to simulate some more natural terrain. Also, in case of large walls/grounds, textures are very strechted.
To sum up, texture coordinates are something to handle in your modeller, unfortunately the N64 precision is very limited (don't expect spheres or hi-poly objects to be mapped correctly) so just respect these limitations and you'll be fine. |
messiaen
Catgirl
Level: 68
Posts: 963/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Originally posted by Me-me
Ok, I'll try something completely different.
I'll make the model in Sketchup and then import it into Blender and do my texturing there.
I'm sure it'll work, because the problems started when I changed to Sketchup.
That's a good idea. Perhaps apply the textures in SketchUp, then do later corrections in Blender, tell us if that works well. |
messiaen
Catgirl
Level: 68
Posts: 964/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Concerning texture coordinates in SketchUp: you should ALWAYS start modelling with 32x32 textures, DO NOT apply textures using the default materials, because they are much more hi-res than the game can handle. Even if the importer actually resizes them, they are still mapped using the original, bigger texure as reference.
Using appropriate textures will ensure that what you see is what you get. It's all a matter of developing an eye for what works and what won't and testing things before making a whole level.
I will see if I can update the documentation as soon as possible to include those simple modelling guidelines, perhaps with some pictures. |
messiaen
Catgirl
Level: 68
Posts: 965/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Originally posted by RDX
Hmm? Sketchup has texture scaling. It's under the edit tab, I believe.
Thanks, totally missed that (actually, I haven't used SketchUp much, except for creating very simple test levels). |
messiaen
Catgirl
Level: 68
Posts: 966/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
| Looks interesting Meltfire, but I need to rant about texture scaling. The first two screenshots are fine in that respect, but the last three repeats the textures too many times in constricted spaces. If you change that I think your levels will look much better. |
messiaen
Catgirl
Level: 68
Posts: 967/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
| Probably even simpler than that, seems like the game is just using Bob-omb's camera. |
messiaen
Catgirl
Level: 68
Posts: 968/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
| Gazpacho: First post of this thread should help. Read also the behavior thread. |
messiaen
Catgirl
Level: 68
Posts: 969/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Originally posted by Dudaw
27 26 00 00 08 02 39 6C -- animation command; change last byte every 4 bytes to get the proper frame
(edit: Just a correction, you are not changing "frames", but rather using another animation type)
That's a good trick, however it may cause problems if used on other behaviors, or even with some animations in this one. This command is a segmented pointer to an array containing pointers to the animation data itself. The Pink Bob-Omb has only one animation entry, or at least, just one that is used. Let's say it uses entry 0, if you add 4 bytes, it will use entry 1 instead. Now if the new animation pointer contain a null pointer in entry 1 (yeah, it happens) the game crashes.
That's more likely to happen when exchanging animation pointers for more complex objects. For instance, if you use the Goomba animation on Bowser, it will look for some invalid entry which will crash the game.
Not sure if that's clear, still that's a good trick on very simple animated objects, simpler than tracking down the function that exchanges the current animation.
Ops: whoops, double post  . Sorry! |
messiaen
Catgirl
Level: 68
Posts: 970/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Well, your idea isn't wrong, however there are much more direct ways of looking at the camera problems, that piece of information isn't very useful.
What happens in that code is that even if the level changes, the game still thinks it's on another level, so it uses that camera. However, if for instance we place a read breakpoint in the "Level ID" global variable, there will be dozens if not hundreds of code snippets reading that, so it's not very useful. Better is to place breakpoints on the camera data, especially now that we have located a handful of information about the camera.
Changing a bit the subject, there is another interesting camera discovery I forgot to post here. Some of you may have noticed the "Disable hardcoded Lakitura camera settings" on the last version of the Level Importer (v14). What this option do is to NOP the call to function 0x8028EEB0, which seems to be responsible for many hardcoded Lakitu camera settings, even for instance the top of Bob-omb mountain.
In some levels the effect is remarkable, in others one not so much. Next version of the importer will include a more complex hack in which you'll be able to enable/disable this function on a level basis. |
messiaen
Catgirl
Level: 68
Posts: 971/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Originally posted by Gazpacho146
can i set the animation for just 1 specific object?
Only if you modify an existing behavior (ie, for an object you surely won't use) or if you add a new one (that's more complex and will require more hex editing). |
messiaen
Catgirl
Level: 68
Posts: 972/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Water box placement has changed since v13, now it requires a pair of coordinates, the other system was just incorrect.
Originally posted by Level Importer page
Water box positioning requires a pair of coordinates. Open your level in TT64 and use the "Top View" camera
mode to place two opposing points of a rectangle, as in this diagram:
(Point 1)
x--------------
| |
| |
|-------------x (Point 2)
Remember to keep them at ground level, otherwise perspective will trick you.
So, it's not complicated. Someday I'll post some pics or do a video tutorial in order to clarify it. |
messiaen
Catgirl
Level: 68
Posts: 973/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I'm sorry, for some reason textures don't look correct in TT64. Just forget about it for now, since they work fine ingame.
On the other hand, if there are missing polygons (TT64 has a limit on graphic commands and the Level Importer exceeds it) use the "Collision" function to get a view (untextured) of the entire model. |
messiaen
Catgirl
Level: 68
Posts: 974/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
| MinyaKang: I have answered your question in the Level Importer page, in the section Troubleshooting/FAQ. |
messiaen
Catgirl
Level: 68
Posts: 975/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I finally decided to test a bit on the "invisible walls" problem and this led me to really major improvements in the importer. Since most my test maps were much simpler than that, I hadn't experienced this problem yet.
I made a model using simple shapes, since I was sure this kind of collision would work without problems. Indeed it did, but than as I gradually increased the face count I started finding the "invisible walls". Since the collision actually did show up in TT64, the most logical explanation was a memory problem. Moving stuff from segmented pointers to elsewhere is usually very straightforward, but when stuff is dynamically allocated in a shared memory pool, the only way to go is to trace exactly how and where this is done.
Luckily Cellar Dweller notes cover some of the solidity functions, so I had some starting point. Well, turns out that the game has a limit of 2300 collision triangles in each level. That means that whenever you import a model with more than 2300 faces (and the current version of the importer allows up to 6500 faces!), you'll run into invisible walls each time you step on a collision triangle which exceeded that limit.
But the news is that I got rid of this limitation and my model with more than 5000 faces imported correctly! I will soon release an update to the importer, since this is a dramatic improvement.
By the way, just as a reference, here's an aproximate polygon/solidity count for some levels in the game:
Haunted house - 2158 [*]
Inside Castle (Area 1)- 2144 [*]
Hazy Maze - 2080 [*]
Bowser Level 3 -1410
Tall Tall Mountain (Area 1) - 1392
Rainbow Clouds - 1352
Peach Slide - 1136
Cool Cool Mountain - 1067
Bob-omb Battlefield - 1060
Pyramid 1 - 968
Snowman's Land - 894
Wet-Dry World (Area 1) - 839
Lethal Lava Land - 816
Whomp's Fortress - 640
The levels marked [*] use the "room" system, and looking at the polygon count it becomes clear why. |
messiaen
Catgirl
Level: 68
Posts: 976/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Originally posted by Metal_Man88
Amazing. So I'm guessing this means levels can get much fancier with their collision than SM64 itself did? 
To put in another way, it means that people won't be mad at me anymore because the fancy level they spent hours modelling didn't work, and I won't be mad at them anymore thinking they were just modelling it the wrong way .
Now I have to try again something similar with the music stuff, though this so far has been more complicated to deal with. |
