Originally posted by VL-Tone
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 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. 
Originally posted by VL-Tone
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.
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)?
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.
Originally posted by VL-Tone
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.
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. |
