SceneNavi - A simple Ocarina of Time level editor

[xdaniel]

It's been a while since the last actual progress, so here's what's happened over the last few days to a week.

 

First and foremost, there's preliminary support for Majora's Mask:

 

 

This is still pretty early work-in-progress, as I'm still in the process of "generalizing" things - I never intended for MM to be supported, so there's a bunch of OoT-specific logic, like the reading of scene table entries, as well as GUI code that need fixing. You can follow the progress in code form on GitHub.

 

Something else I've been messing around with, which is related to SceneNavi, is a redux of DLViewer's RDRAM dump rendering capabilities. You provide the program with a full 4 or 8 MB N64 RAM dump, as well as the start address of the "master display list", from which the program renders the scene like an emulator would do. Or, well, DLViewer would if it ever came close to fully simulating the hardware:

 

 

That's about what DLViewer spits out for a typical OoT RAM dump. Now, this new renderer/interpreter I've been working on is a lot closer to actual emulators at least - as opposed to the very abstract and simplified prior renderers of ex. OZMAV2, SayakaGL and SceneNavi -, and can simulate viewport changes and TMEM, uses the projection matrix, etc., etc. It is still far from being finished, tho. But once it's relatively free of bugs, and only in case it does fix certain rendering glitches that MM in particular exhibits in said prior renderers, it will replace SceneNavi's current "SimpleF3DEX2" rendering code.

 

All that said, finally, here's how that new program renders the above scene from OoT:

 

 

...but again, it's still far from finished. OoT looks alright, but other games' RAM dumps show some glaring problems, like Super Smash Bros and Sin and Punishment...

[SoulofDeity]

That looks so badass!!! I love it!! Is this gonna be a new way of editing the game through ram like ZAP?

[xdaniel]

Ah, no, editing in SceneNavi will likely stay a ROM-only affair, with no emulator involvement. The whole rendering of RAM dumps (instead of just, say, room models from OoT) is mainly just to have a sizeable set of commands that need to be interpreted.

 

With room models, for example, you can get away with just implementing the most basic geometry, texture/tile and rendering mode commands and still have it look good. On the other hand, with a RAM dump, you'll have to have cover matrix usage, more lower-level functions like setting viewports and RAM segment mapping, light positions and color, etc. for the frame to look the way it should, i.e. how it looked in the emulator you made the dump with, when you did it. The more commands to support, the more complete the renderer gets, the more universally usable the renderer will be, thus not just for Zelda.

[john_smith_account]

Ah, no, editing in SceneNavi will likely stay a ROM-only affair, with no emulator involvement. The whole rendering of RAM dumps (instead of just, say, room models from OoT) is mainly just to have a sizeable set of commands that need to be interpreted.

 

Whatever tool comes after ZAP2.5 will aim to do this.  I pitched the idea of making the ZLE2 series' successor an open source, co-operative effort.  One of the ideas is that ZAP3 will attach to tools like Scene Navi, or UoT copy the values out, and load them in game to preview the setups.

 

Thats if I can get back to coding.

[oddMLan]

xdaniel, not sure if this is of any help for your project but there is a N64 Video Plugin that is 100% pixel accurate; it even simulates the N64 DAC VI filters like divot filtering, antialasing, gamma correction, reverse dithering... etc. The source code is here.

[xdaniel]

SceneNavi v1.0 Beta 10 pre-release. Expect Majora's Mask and potentially breakage. More detailed changelog here.

 

My motivation and interest in OoT/MM is going near zero, so before ex. the partial MM support just keeps collecting dust forever, have a build that should basically work, but might have undiscovered problems and such.

[mzxrules]

If it allows actor position editing, did you figure out how MM's actor spawn data is formatted, or did you just base it off of the OoT spawn format (which is very wrong)?

[xdaniel]

Based off OoT, only difference being that, in the actor definition, the actor number is masked with 0x07FF. As I said, support is partial and has potential (or, in this case, apparently definitive) breakage.

[mzxrules]

Ok, was just wondering if you knew anything extra. What I've observed is that rotation is stored as a byte rather than a short in MM, such that one unit = 2 degrees of rotation. Pretty sure that the rx, ry, rz variables are at least stored at the same offset into the data though.

[Ideka]

@mzxrules: By actor spawn data, do you mean the data that the 0x01 map header command points to? I might look into it then...

[Jason777]

I was thinking about vertex manipulation... should it actually be that difficult to implement? From what I can tell, you've got picking code already written (actor placement modification).

 

I know you aren't exactly working on SceneNavi anymore, I just want to you to confirm or dispell my belief that it shouldn't be that hard to implement.

[xdaniel]

mzxrules: Interesting, didn't know about that. I could at least try and fix the actor definitions to reflect the different rotations, tho I'm not sure if that'll be enough, if you say that one unit is two degrees of rotation...

 

Jason: SceneNavi more or less "prerenders" every room, by parsing every N64-side display list and storing all OpenGL commands used for rendering it in an OGL-side display list. For most frames rendered by the program, that display list is simply called and drawn onto the screen, which is quite fast. However, as you cannot add, remove or change any data in those display lists, they have to be recreated from scratch if you do want to change something in them. SceneNavi sets a "displayListsDirty" boolean after doing various things, such as changing the color of a vertex, switching to a different combiner emulation mode, etc., which then causes every GL display list to be disposed, then recreated on the next frame. (See MainForm.cs for displayListsDirty, HeaderCommands/MeshHeader.cs for display list generation).

 

The static nature of those display lists is what makes me think that realtime editing of vertices (i.e. dragging them around) is pretty much impossible with the current setup, which would cause the whole dispose-recreate cycle to happen every time a vertex is moved by just one unit. Granted, I have not measured rendering times or what have you, I just have this gut feeling that it'll lag far too much to be practical...

 

Rewriting SceneNavi's rendering system to use more modern OpenGL features, like Vertex Buffer Objects, would likely retain a high framerate and allow realtime vertex editing at the same time, but would also be rather time-consuming. Add to that that I'm not really working on SN anymore anyway, plus some game-related issues that Arcaith mentioned on the shoutbox a few days ago (viewport culling, multiple faces sharing vertices; can't really remember those myself, but ex. the culling does ring a bell)... that kind of rewrite is nothing I'd necessarily want to embark on.