xdaniel

Tried something easier, an outdoor area - to be exact, the potential entrance to my dungeon-thingy above. Yet I don't know if I'll continue doing this... Trying to group things in SketchUp is a pain, and texturing - while maybe enough for, well, buildings for Google Earth - isn't much better -.-

SanguinettiMods: Treasure chest are scene-wide - with 32 or so possible chests per scene - as far as I know, not just per room. As for other actors, I can't say for sure, seeing how I haven't been dealing with actually creating maps much yet. Guess I need to read the Wiki page about switches myself

Zeth: I don't think I'll be adding that kinda feature to SharpOcarina itself, but I could make a separate command line tool or something that takes a ROM and scene number as parameters, and spits out a XML file from which you can take the waypoints and copy'n'paste them over to your SharpOcarina scene XML. Well, once waypoints are implemented in SharpOcarina anyway, they aren't yet supported after all...

Thanks for the info so far, pretty helpful! I managed to get some room models done, although the scale of some room elements isn't quite right, I have no artistic direction whatsoever besides "ruined temple-ish area", etc.

Now I'm the one needing help with imports Well, to be more exact, with actually modelling maps in SketchUp. I did manage to make a little test map myself, just to go wild with SharpOcarina's features, practice actor association with flags and triggers (switch + chest, etc.) and such, but that's about it: http://i.imgur.com/f4eWY.png However, there's some things I have no idea about. One thing is scaling things in relation to how they'll appear in-game, say space for a door. Making an outdoor field map isn't that much of a problem, but dungeons or houses are something else. Say, how big is a normal dungeon door? How to represent that size in SketchUp? Things like that. Or generally, what kinds of hints and such do you have for someone who's basically just starting out with modelling?

Switches are actor number 012A. They require object 0003, which along with 0002 shouldn't be loaded per room (like ex. the Stalfos), but are automatically loaded depending on what kind of scene you have - 0002 is loaded for outdoor areas like Hyrule Field, while 0003 is used in dungeons. In the case of SharpOcarina, this is part of the catch-all option "Outdoor Scene" on the "General" tab. You get a blue switch using the variable xx20, where xx is the switch flag. More about switches and how to use them to activate things is here: http://wiki.spinout182.com/w/Modification_and_Addition_of_Switches

Gazpacho146: You've got to add their respective objects to the room as well. On the "Objects & Actors" tab, press "Add Object", then double-click on the just added "0000" in the list, enter the object number - in the Stalfos' case 0032 - and press enter. That should be enough to make most actors show up. Bosses and the like are dependant on other factors, so you likely won't be able to add them to your map.

Just open the .obj in a text editor, preferably one that allows you to replace all instances of something at once (ex. Notepad++).

Ohhh, I think I don't even have to investigate much on this one because I tried importing that very same map before myself. It's an export from Banjo-Kazooie made using cooliscool's Bottles' Glasses - which assignes a new group for every vertex load in the original game. That amounts to 400-something different groups, if I'm not mistaken, which in turn means 400-something Display Lists that SharpOcarina generates. That's most likely simply way too much for the game, or maybe even the system to handle. Hacky "fix": Replace all instances of "g VTX_SEG_" in the .obj file with "#g VTX_SEG_", which comments them out, then add a single "g modelgroup" line right after "mtllib Spiral Mountain.mtl" near the top. That should make the map import correctly, although - since it's only one big group - you can't do much in terms of collision types, translucency, etc.

Gazpacho146: Remember that 0x035CF000 is also the default offset for the room, so if you're injecting the scene and the room to 0x035CF000, it's bound to not work. Try 0x035CF000 for the scene and something like 0x03700000 for the room; if it still doesn't work, it would be great if you could send the .obj model over. I probably won't get to checking this right away, tho. SanguinettiMods: Nice stuff

SanguinettiMods: Should be fixed now, mouse wheel appears to work in all cases again. SVN r11: Fixed mouse wheel usage not increasing/decreasing the position/rotation of actors, etc. anymore, also tweaked usability of related controls (value increments)

Gazpacho146: Anything from 0x035CF000 to the end of the ROM is free/unused, which is just over 10MB of space. Also, SVN status update, r10: - Improved preview rendering performance, started to improve waterbox property support (thanks again, DeathBasket)

SanguinettiMods: Implementing any effects depend on there being information about them, or me being able to figure them out, so no promises on any of those. I will see about getting spinout's header extension hack implemented sooner or later. As for spawn points, actor cubes, etc. not changing their position, I have this problem when I use the mouse wheel to change the values; using that doesn't commit the changes to the scene. Do the changes appear in-game for you? DeathBasket: Will see about implementing that for the next build, thanks for the info! Gazpacho146: When importing a level using SharpOcarina, you should best set the injection offset(s) to unused space in the ROM, not to the offsets of existing scenes. You might've overwritten something which is now causing the game to crash. As for scene 108, that's 117:ささテスト (or whatever it is when using a patched ROM) on the map select.

Arcaith: I've seen that before but can't consistently reproduce it. It could be related to the scene file's size, seeing how, out of the maps I have lying around, those with resulting scene file sizes of 8 or 10kb work flawlessly, while those with sizes like 22 or 56kb crash when you die and respawn... If that's really the case, I'd imagine this is another result of us currently just modifying the scene table, instead of doing 100% game-conform imports. Gazpacho146: http://wiki.spinout1...ings:_Debug_ROM - the number after each offset pair is what you need, so Hyrule Field, for example, would be 81. But remember, if you want to replace multiple scenes in one ROM, you have to change the injection offsets for each scene you insert, otherwise you'll just end up overwriting the previous one. Edit: Changes you can expect for the next build... SVN r9: Fixed preview of texture tiling and tiling mode selection, added texture size sanity check, changed .obj group naming to use the complete remaining line, improved error handling, cleanup of debug messages (ignored in release builds), upped version number in advance

What the hell, I think Google Code uploaded the wrong file or something <.< A second... EDIT: http://code.google.com/p/sharpocarina/downloads/detail?name=SharpOcarina-v04-b.rar <- if that doesn't work, I don't care for now. It's past midnight, I'll fix that later...

Damn it, redownload it again, -this- should've fixed that problem while reintroducing the potentially missing textures in the preview... If it still doesn't work, please stick with the previous build -.-

DeathBasket: Ouch, that didn't happen with the previous build, I assume? Still works for me with ex. the demo dungeon... As for the group names, they are being displayed and Mesh1, Mesh2, etc. are the group names...? Unless the modelling program you use uses that as a prefix or whatever, and the group name you define comes after a space or something? I'll just change it to simply read the rest of the line as the group name instead. EDIT: Please redownload the file; reverted the only thing I can imagine being the problem right now.

SharpOcarina v0.4/r6: http://code.google.com/p/sharpocarina/downloads/detail?name=SharpOcarina-v04.rar Changelog since last build: r6: Added exit selection to Polygon Type editor, changed logic for render mode setting generation (group alpha takes priority over texture alpha channels), other minor changes r5: Temporary fix to textures not showing in the preview, added to-do list (Notes.txt), upped version number in advance for next build r4: Calculation of collision normals fixed (thanks, DeathBasket!); render mode setting for textures with alpha channel fixed

haddockd: Huh... it shouldn't say that if it's an unedited MM ROM; try it using the console commands SanguinettiMods posted, tho I'm not sure if that'll help... SanguinettiMods: In OZMAV2? Press F3 once. F3 and F4 select which room to render, pressing F3 when rendering room 1 makes it render all of them.

Use OZMAV2, open the ROM with it and use the "extract" command. That's gonna extract all files to <OZMAV2 folder>\extr\<game name>\; mind you that it doesn't name the files anything other than ex. "0118_00D8D980-00D8F180", so it doesn't try to identify them or anything.

In SharpOcarina, "File" -> "New Scene", then add a collision model from the "General" tab -> "Collision Model", then add rooms from the "Rooms" tab -> "Add Room"; those two functions ask for the respective .obj model files. Edit: Bah, too late

http://wiki.spinout182.com/w/Zelda_64:_Collision_Format#Polygon_Types - although some of the descriptions are incomplete/not fully accurate (ex. the Z-buffer-related notes, those glitches happen only when the scene is missing the requested environment setup).

I don't know all that much about waterboxes, to be honest, but I assume it has something to do with their properties. Looking at the example properties on the Wiki, I'd imagine the second byte (or maybe last digit alone) controls in which room the waterbox appears, I have not yet tested this, tho.

The code determines which combiner and render modes to set in this order: If the texture has an alpha channel, set modes for that; else, if the group alpha is set to something less than 255, set modes for that; else, just set modes for normal, opaque surfaces. I could switch the first two around, so that group alpha takes precedence over the texture's alpha channel. That would mean, if you set a group alpha value and your texture has an alpha channel, the texture's alpha would be ignored instead. Any thoughts?