Jump to content

SceneNavi - A simple Ocarina of Time level editor


xdaniel
 Share

Recommended Posts

General question: Would you prefer mouse-based movement of moveable objects (i.e. actors, waterboxes) to be one-to-one to the mouse position on screen?

 

What I mean is, currently, when moving these objects, their movement in 3D space is somewhat arbitrary and doesn't correspond your exact mouse movements. I believe I can make those objects actually follow the mouse cursor instead of just roughly going into the direction you're moving it. Of course, this would only be true for "horizontal" and "vertical" movement, and moving objects "into the screen" would keep working the way it currently does.

 

I already have this working probably 99% 85% (*cough*) perfectly in another program (an editor-to-be for an improved 3D model format for my Dreamcast project, which is to have a hierarchy and animations and all) so it shouldn't be too much of a stretch to implement this in SceneNavi as well.

Edited by xdaniel
Link to comment
Share on other sites

Well, there's a certain feature I'm interested in seeing (individual file saving). I know I keep going on about this, but it's actually preventing me from using SceneNavi. And man, I'd really like to kick UoT for good.

Yeah, I haven't forgotten and actually mentioned it a few days ago ;):

 

Unrelated to the WIP screenshot above, individual scene/room file support is mostly broken in the current build, because of the way I restructured the treeview compared to Beta 6; didn't catch that one before release. It's already fixed, tho. Also, petrie, I haven't forgotten about adding saving support in that mode. I'll make that a goal for Beta 8.


Also, about the object positioning changes I mentioned... that might've been a bit hasty. I can't seem to get this working reliably right now, as I haven't yet mastered those magical incantations for Project and UnProject and certain matrix operations. Will keep this in mind tho - not least because I personally want to have this feature in said editor for Frenda/DCEO -, but it's probably not gonna be in the next build.

 

Edit: Thinking about it, I probably should get another build out soon-ish, considering those bugs that Beta 7 has and how waterbox support is a new feature and is (mostly!) tested and working fine... Yeah, guess I'll look into individual file saving support, hopefully get that working in the next couple of days or so, then release what I have (namely the changelog I'd written down a few posts ago) as Beta 8.

 

Edit 2: Actually, looking over the code, individual file saving might be easier than I thought... just gotta change an interface's function to also require the byte buffer to be written to as a parameter, instead of assuming the ROM's data... brb! :P

 

Edit 3: Well, this should've worked! Changed one of Hyrule Field's waterboxes (thus in scene) and signposts (in room) inside individual files, saved the changes, then reopened everything in SceneNavi, saw no changes in the ROM itself but in the individual files, then pasted the changed files into a ROM, and ended up spawning in invisible water, looking at a weirdly rotated and floating sign! Still needs more testing, tho - I distinctly remember my Forest Temple and what UoT did to its doors...

Edited by xdaniel
  • Like 1
Link to comment
Share on other sites

Pending some response about something, Beta 8 might arrive in a few days. Thus, it's preliminary changelog time!

v1.0 Beta 8 ("Fresh Water Laced With Bugfixes")

  • Added waterbox support; allows changing of waterbox position, size, room number and other properties
  • Added saving support for individual scene and room files; still requires a ROM to be loaded beforehand, but saves changes to the separate files
  • Fixed loading of individual scene and room files; the changes to the treeview in Beta 7 broke header selection
  • Fixed SFX and reverb options under Scene Metadata being disabled; slight GUI changes broke this feature
  • Fixed ROM information window cutting off text prematurely if null byte is encountered in the ROM header's game title or ID
  • Improved update and version checking functionality; now displays release notes from remote RTF file

 

  • Like 2
Link to comment
Share on other sites

A good vertex editor alone won't help with moving textures around, tho. A vertex doesn't "know" what texture it uses, as the texture is loaded by other commands in the display list beforehand. Making a single polygon use a different texture would (potentially) mean recreating, or at least heavily rearranging the whole display list, and that's certainly out of the scope of this project.

 

Oh, and one more note for the changelog by the way; just fixed another little bug:

  • Added additional sanity checks to prevent unfixed "Stalfos Middle Room" (#120, syotes) from causing an exception on selecting its room

...and with that, I guess I'm off to bed (4:35 am)!

Link to comment
Share on other sites

  • 2 weeks later...

[23:12] <@petrie911> http://imgur.com/WREfhA2
[23:13] <@petrie911> this is what every OoT level editor does wrong

[23:19] <%mzxrules> so in that image
[23:19] <%mzxrules> you tried rotating around the y axis, but the box rotated around the Z axis?
[23:20] <%mzxrules> or was nintendo drunk when they coded actor rotations

[23:27] <@petrie911> nah, what happens is
[23:27] <@petrie911> scene navi rotates about the object's y-axis
[23:27] <@petrie911> the game rotates about the y-coordinate axis
[23:28] <@petrie911> all the rotations are about the coordinate axes
[23:28] <@petrie911> in the game

[23:42] <%mzxrules> is it that the x rotation is applied, then y, then z?
[23:46] <@petrie911> yes
[23:47] <@petrie911> it's worth remembering that rotations in three dimensions don't commute
[23:47] <@petrie911> so there has to be an order to apply them in

Link to comment
Share on other sites

[23:12] <@petrie911> http://imgur.com/WREfhA2

[23:13] <@petrie911> this is what every OoT level editor does wrong

...

 

Yeah, he mentioned that in a PM, as part of some feedback to a preliminary Beta 8 build I sent him (ex. for checking individual scene/room saving). That said, it appears to be fixed now - I inverted the order in which rotation is applied when rendering, from, as you noticed, X, Y and Z, to Z, Y and X:

 

uRLmPmh.png

 

I'll look over all the changes since the last build again, make sure nothing broke that shouldn't have broken, etc., then maybe get Beta 8 out later tonight or otherwise likely tomorrow evening.

Edited by xdaniel
Link to comment
Share on other sites

Time to check the ol' update function again:

v1.0 Beta 8 ("Fresh Water Laced With Bugfixes")

  • Added waterbox support; allows changing of waterbox position, size, room number and other properties
  • Added saving support for individual scene and room files; still requires a ROM to be loaded beforehand, but saves changes to the separate files
  • Fixed loading of individual scene and room files; the changes to the treeview in Beta 7 broke header selection
  • Fixed SFX and reverb options under Scene Metadata being disabled; slight GUI changes broke this feature
  • Fixed ROM information window cutting off text prematurely if null byte is encountered in the ROM header's game title or ID
  • Fixed and improved the actor editing GUI and underlying actor definition reader code slightly
  • Fixed actor rotation rendering; the order in which rotation was applied during drawing was wrong before
  • Added additional sanity checks to prevent unfixed "Stalfos Middle Room" (#120, syotes) from causing an exception on selecting its room
  • Improved update and version checking functionality; now displays release notes from remote RTF file
  • Added (temporary) program icon

Alternatively, as usual: http://magicstone.de/dzd/progupdates/sn-update.htm

 

Hope it doesn't have any bugs I'm not aware of... or rather any bugs, period...

 

Edited by xdaniel
  • Like 2
Link to comment
Share on other sites

Is this to be considered the "final" version oh great one?

Not yet 100% final, but I think I'm getting there. A few more options to add (ex. more in scene metadata, collision polygons/polygon types), maaaaaybe proper environment settings support, then it's "SceneNavi v1.0 Final" time. After that come additional features, like more tangentially-related stuff - resurrecting SorataVSE's actor rendering, maybe?

 

Wayne_s%20World%20-%20We_re%20not%20wort

Hey, if anything I am not worthy to have such a good user base on here, and that's not meant sarcastically! :P

Link to comment
Share on other sites

Zeth..you know better  :P

 

Give as much detail as possible as to exactly how you came across the bug. It makes xDan's life much easier

Sometimes a picture can say everything you need it to say. This shows what I had open at the time as well as the XYZ Camera coordinates when I came across the error.

 

@xdan - I also noticed that Scenenavi seems to lag a bit when switching from different fully displayed scenes (ex: Like clicking on the deku tree then clicking on the spirit temple). Is this normal because of its rendering every room in the scene? Also I wanted to ask about why you haven't added an option to dump the various rooms to obj?(or perhaps a better format such as collada .dae) With how far you've come since Ozmav I think it would be rather great to see proper dumps of the maps/collision of the scenes.

 

Edit: I saw your post, all I can say is Ugh. Ganon's castle is such a mess when it comes how they built it. From the countless seams all over the map and now a bad UV coordinate. -__-

Link to comment
Share on other sites

Yeah, it takes some time for SceneNavi to load and render every room if you load a scene that hadn't been cached yet, so it lags a bit while doing so. Has a scene been loaded once, its room display lists get cached until you disable/enable texturing or the combiner emulation, or you reload the ROM/load a different ROM.

 

Dumping models hasn't really been on my mind since OZMAV2, one reason being that the .obj format is too limited, another one being that I haven't yet looked into other formats very much - Collada seems promising, tho. However, dumps will probably never be 100% perfect as such, considering ex. the aforementioned combiner. Geometry, sure. Texturing and colorization? Unlikely.

Link to comment
Share on other sites

I don't know if it's me or not, but I created my own area title card for Fire Temple and I have imported it and saved it, but when I play OoT to see if it worked, every time the emulator (Project 1.6, Nemu 64) would stop or crash on me. I am using Rice to see the graphics correctly, I am also new to modding. Would it be a setting in the scene that I modified that may be causing that? I used the correct image format to use. 

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.