SceneNavi - A simple Ocarina of Time level editor

[xdaniel]

SceneNavi v1.0 Beta 3

 

Changes since Beta 2:

• Support for ROMs with z64tables hack
• ROM loader error handling changed; now allows access to exception details for reporting
• Human-readable actor names now read from ActorNames.xml instead of individual actor definitions
• XML data files rearranged; removed AddressTranslations.xml and address translator class, added more versatile hashtable reader class, also used by actor names
• Object names are now version-independant, using the hashtable reader class mentioned above
• Added collsion rendering with two different highlighting modes (all white, or approximately by ground type)
• Actor definitions changed to use hexadecimal values for rotation

Collision editing as shown above will be in Beta 4; it's still not very well tested and missing a lot of GUI features, so it's not available in this build.

 

[Three_Pendants]

It is so nice to have human readable actor definitions, and the hex versions of rotations is much cleaner and concise. Keep up the great work and I am looking forward to the next update!

[xdaniel]

I was gonna post a short progress report, but first...

 

So, uh, no other feedback? Airikita, Antidote, !Tommy, do you still get the errors you've been getting, and if so, what do the details say? Anyone else with any bug reports, ideas, etc.?

 

...now for the progress. Dunno if it's dedication or foolishness, but I've worked through the night - literally, it's 7:45 am here - to get mouse-based actor and waypoint movement working. And yeah, I did get it to work. Holding the right button down on such an object allows dragging left/right/up/down (or on X and Y axis with neutral camera), while holding the middle button allows dragging forward/backward (Z axis neutral). The left mouse button is purely for camera purposes. Also rewrote parts of the picking code, added a VSync option to limit the FPS, and did some tiny changes and fixes to the GUI.

[haddockd]

But my mouse only has two buttons

[xdaniel]

What? No clickable scroll wheel or anything? How old is that mouse? Uhm, I guess I'll add a modifier key that, when pressed, changes the right-click function into the middle-click one... like, hold down ex. Ctrl and the right button drags the object forward/backward, instead of up/down/left/right.

 

EDIT: WIP, more details about the changes later:

 

Edited July 16, 2013 by xdaniel

[Antidote]

Oh sorry, was so busy working on STB i forgot to check it out XD

 

 

Again mono, how are you handling paths?

i have the rom located at /home/antidote/OoTDebug/z64_debug_copy.z64

[xdaniel]

Hm, the only Path.Combine calls in the ROMHandler's constructor are for creating the paths to the XML files, thus the actor definitions, name tables, etc. "Illegal characters" can occur if you try to load a ROM with the wrong byte order, as the program ends up reading the game ID incorrectly, which is needed as part of the path.

 

Can you read the ROM header if you open the ROM in a hex editor; the title "THE LEGEND OF ZELDA", etc.? If not, try byteswapping and opening it in SceneNavi again. Gotta add some exception handling for that kinda situation...

 

[Antidote]

AHAHAHHAHAHAHAHAHAHAHAHHAHA

 

Nice call XD

 

It's easily fixed, i have a utility that can unscramble it.

[xdaniel]

Yeah, that should explain it. I'm adding some byte order detection and swapping code to the program; it'll detect if the ROM has the wrong order, then ask the user if it should swap it and where to save the resulting ROM, and finally reload the now correctly ordered file.

 

[Antidote]

Well, i can confirm that I've fixed it on my end, it seems that my file has each WORD in little endian.

There may be files where each DWORD is little so check for that as well.

 

Also it's in desperate need of a frame limit, zooming around at 300+ FPS is kinda odd and difficult XD

[xdaniel]

The next version will allow switching the OGL control's VSync on and off, so unless your monitor does a 300 Hz refresh rate, it should be much easier to navigate scenes with that enabled   In the meantime, try holding down Shift while you move around, that slows the camera's speed down somewhat while Space speeds it up.

[Antidote]

ah thanks for the tip lol.

[haddockd]

OH. I didnt know the wheel was considered a middle button...D'OH!

[xdaniel]

Heh, well, the key modifier's still useful for those with laptops, where the touchpad usually only has two buttons, so no harm done Still surprised you didn't know about the wheel, tho maybe that's just me as I use the button for scrolling at times.

 

[haddockd]

I always use it for scrolling but have never pressed it as a button. My bad

[xdaniel]

Progress report time; turned out a bit long but might be interesting to read:

 

As I've said before, mouse-based movement of actors and waypoints is now implemented, although I've since changed how it works. There's now three mouse modes, similar to UoT and SayakaGL: camera mode (only allows camera movement, no selection or movement of "things"), moveable objects mode (allows selection and movement of actors and waypoints) and static objects mode (allows selection of, so far, collision polygons). You can switch through the modes either by using the menu ("Tools" -> "Mouse Mode") or by clicking on the mode label on the (now actually used!) status bar, in the lower left corner.

 

Moving things is done via the left and/or middle mouse button: hold the left button to move the thing up, down, left and right (meaning, X and Y axis with neutral camera position), hold the middle button OR hold Ctrl on the keyboard plus the left button to move the thing forward or backward (Z axis w/ neutral camera). Also, moveable objects have a context menu that's displayed when you right-click them. The menu allows you to rotate the thing by 45 degrees in both directions on any of the three axis. This function is only enabled for things that actually have rotation values, so waypoints cannot be rotated, and only the axes that are supported by the thing can be changed, so ex. treasure chests can only be rotated on the X and Y axis.

 

The status bar, as mentioned, now actually does something. Besides the mouse mode, it now displays the camera position, as well as some information about the currently loaded scene or room, like its name and actor counts. Minor addition, but might be useful. The menus have changed a bit, too: the collision highlight option has moved to the new "Tools" menu, which also contains the aforementioned mouse mode option, as well as one to reset the camera position. There's also a new VSync toggle in the Options menu to limit the FPS - the FPS is now also only shown when VSync is disabled, as otherwise it'll mostly be around whatever your monitor's refresh rate is anyway.

 

Speaking of FPS, one thing that really destroyed the performance previously was the collision rendering. I've added some caching via OpenGL display lists, so the collision overlay is now only re-rendered if it changes, ex. when you select a collision polygon, or when you change something in a polygon type. Once something changes, the collilsion overlay is flagged as dirty, then deleted and recreated on the next frame and cached again until another change occures. What does that mean for performance? Screenshots in the spoiler, showing the Fire Temple, which is one of the more demanding ones to render (along with ex. Water and Spirit, I believe).

 

 

Before, Beta 3:

 

After, Beta 4:

 

 

EDIT: Oh, and before I forget, I added some more housekeeping stuff regarding OpenGL extensions, texturing and combiner emulation. This'll meant that, hopefully, people with not-so-good graphics cards, that do not support the extensions required for ex. the combiner, will at least be able to use the program, albeit without textures.

Edited July 18, 2013 by xdaniel

[Antidote]

That is a considerable improvement, also the UI is starting to have that UoT feel, which I gather is what you're going for to some extent.

[xdaniel]

UoT's certainly been an inspiration for a lot of things in SceneNavi (and SayakaGL, and OZMAV2, and "Old OZMAV"). It has a solid UI, although I feel like it's rather messy - or maybe it's gotten messy over time, can't remember its original incarnations very well. I guess I'm trying to take what I feel is good about its interface - ex. the mouse controls -, while at the same time making it cleaner and more... adhering to design conventions, I suppose? Like not having colored, underlined text and silder/trackbar controls in the status bar. It's those tiny things that look out of place, that I hate about UoT. And that some older version of it killed my Forest Temple by ruining the transition actors...

 

[Antidote]

Makes perfect sense to me, UoT definitely had some good qualities, but it also had it's really bad quirks, It's good to use it as an example both to learn from and to model after.

[haddockd]

Nice work xDan. Cant help but feel being left behind

 

That's OK though, the program is coming along VERY nicely!

[xdaniel]

 

Think I'll leave the UI for collision editing like this for Beta 4. I will add more, separate options for exit triggering, damage, etc. in later builds, but for now this'll have to do. Also aiming for a release of Beta 4 soon-ish, maybe Sunday or so.

 

[Antidote]

Looks good, I think it would be a good idea to go ahead an leave the collision stuff so it can be thoroughly tested.

[petrie911]

So, I hate to sound like a broken record, but working with individual map files would be really helpful to me. I mean, due to the way that I've been working with my hack, not having individual file support largely prevents me from using your tool.

[xdaniel]

petrie911: Trying to implement it right now. The way I'm planning it, you'll still need to open a compatible ROM beforehand - as a lot of data will still be loaded from it, and I really don't want to change this - but afterwards you can open a separate pair of scene and room files to sort of "override" the ROM. They will stay active until you close the scene/room pair from the menu. Not sure if this'll be in the next build, but it's looking good, I guess. Hope this'll work for you.

 

In other news, I came across the update-checking-sample-demo thingy I posted in one of haddockd's Master GUI threads again and decided to add such a function to SceneNavi. Starting with the next release, you'll be able to check for updates to SceneNavi by using the "Check for Update" function in the "Help" menu. It'll either tell you that you already have the most recent version, or be able to direct you to a download of the newer one.

[Antidote]

Nice, I've been meaning to add one to Wiiking2 Editor, but I just haven't gotten around to it yet.