|  Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes | Originally posted by xdaniel
With the fading in BK you describe, do you mean ex. the fade-out at the level edge that can be seen in the Bottles' Glasses screenshot you've posted above, http://img26.imageshack.us/img26/5456/clipboard01jcg.jpg ? If it's that, I'm pretty sure that this actually isn't created by the combiner, because Bottles' Glasses doesn't even emulate it (as far as I can see from the program's source that cooliscool released some time ago).
Also, something I've been working on for a few days now: http://z64.spinout182.com/index.php?topic=391.0 - it's a tool that allows experimenting with and previewing combiner setups. Might be useful if anyone wants to mess with the combiner or so 
btw, another multi-texturing experiment, this time using Flatworld as the base (which is way easier to work with instead of an imported Wavefront model in this case): http://magicstone.de/dzd/random/sm64_newcomb.png
I was talking more specifically about these parts:
 
Looking at the level in TT64, I can see (because of the flickering in those areas) that there are two polygon layers precisely on top of each other, with different textures. What you can see in the game and in these screenshots is that the ground fades smoothly between these textures in a similar way to vertex coloring. The version imported in SM64 only shows the top polygon layer.
Your program looks very interesting, it might help me understand this SETCOMBINE command better. I still don't have a suitable "transparent texture" header to be used in the importer, and I'm sure this command is involved in making the engine use the alpha channel from textures.
I might not include the transparency option in 0.6b, because I expect some big problems with mixing non-transparent and transparent textures. In SM64, parts of the level that are using alpha textures are drawn separately using their own 0x15 commands, which include a value that specifies the "drawing layer". Tree shadows, fences, windows on the castle, the rest of the levels are drawn on 4 separate layers. I presume that without this separation into layers, the engine will run into serious z-ordering issues. Shockwave 3d (the 3d engine used in TT64) has similar issues with transparent textures, but unfortunately no way to control the z-ordering at the polygon level (I mostly avoid these issues in TT64 by splitting the level into polygon chunks, but if you take a look at the Tick-Tock Clock level in TT64, you'll see that there are sill issues).
So to avoid these problems I would have to do a major rewrite of my importing code, as well as figuring out how to use this drawing layer value.
Now here's some progress update:
This is the latest version of the importer interface.
When you click "Save level to ROM" you'll be presented with this dialog box:
Before saving you'll have to choose in which level slot you want to save it, and which level in the game it will replace.
The "Manage Level Slots" button will present you with a similar interface, but will be used to change the replacing levels for levels already saved in slots.
The "Empty Objects Only" option will save your level with empty 0x24 objects. The number of objects can be set.
The "Keep existing objects" will keep the objects found in the slot you're saving to.
And lastly, the "Use Objects From File" will use the objects found in the current level file (the number of objects found in the file is in parenthesis).
By default, objects won't be saved in the level file. Automatic saving of the objects in the file had too many potential problems. While it's obvious that when you just saved a level in slot 2, that you want objects from slot 2 to be copied in the level file, if you open another ROM where there's another level in slot 2, TT64 would save the wrong objects. That's why you can only save objects in the level file when you check the option ("When Saving Level File Also Copy Objects") which btw has the checkbox missing in the screenshot. And when you do use this option, you'll be presented with a dialog where you choose/confirm which slots you want to copy the objects from.
It sounds a little complicated, but keep in mind that the only time you'll want the objects copied in the level file is when you want to move a custom level from one ROM to another (or from one slot to another), with its objects intact. You don't need a constantly updated copy of the objects in the level file for this purpose, and you can always go back to copy the objects even if you forget to check the option, because those are saved in the ROM when you edit them in the main level editor module.
Normally, what you'll want to use is the "Keep Existing Objects" option, so if you change your .obj file and reimport the level, the objects that were already in the level slot will remain.
Note: I just realized that the "Polys:" count in the screenshot is wrong, it should read 3136 polys (triangles) for this level.
____________________
|   |
|
|
