haddockd Posted November 20, 2013 Share Posted November 20, 2013 FINALLY! Isnt this the first tool to support waterboxes fully? Nice work! Link to comment Share on other sites More sharing options...
xdaniel Posted November 20, 2013 Author Share Posted November 20, 2013 FINALLY! Isnt this the first tool to support waterboxes fully? Nice work! As fully as waterboxes are understood yet anyway, I believe, yeah. I'd like to break down that "Properties" field someday, but I think what's there - the room selection in particular - is good enough for now. Link to comment Share on other sites More sharing options...
xdaniel Posted November 22, 2013 Author Share Posted November 22, 2013 (edited) 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 November 22, 2013 by xdaniel Link to comment Share on other sites More sharing options...
Netsrac Posted November 22, 2013 Share Posted November 22, 2013 I'd say go for it if it isn't too much. Precise work is the best work. 1 Link to comment Share on other sites More sharing options...
haddockd Posted November 22, 2013 Share Posted November 22, 2013 +1. I remember being SOO frustrated in UoT because where I moved my mouse was NOT where I think the object should be moving. Pissed me off to no end. Link to comment Share on other sites More sharing options...
petrie911 Posted November 22, 2013 Share Posted November 22, 2013 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. Link to comment Share on other sites More sharing options...
xdaniel Posted November 22, 2013 Author Share Posted November 22, 2013 (edited) 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! 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 November 23, 2013 by xdaniel 1 Link to comment Share on other sites More sharing options...
xdaniel Posted November 23, 2013 Author Share Posted November 23, 2013 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 2 Link to comment Share on other sites More sharing options...
haddockd Posted November 24, 2013 Share Posted November 24, 2013 Holy shit man... Whats left to be perfected? This thing is clutch! Link to comment Share on other sites More sharing options...
â–²ChriisTiianâ–² Posted November 24, 2013 Share Posted November 24, 2013 Holy shit man... Whats left to be perfected? A Vertex Editor! A good vertex editor, so, we can move any texture from a place to other! Btw, no idea if XDan can do this... :< Link to comment Share on other sites More sharing options...
xdaniel Posted November 24, 2013 Author Share Posted November 24, 2013 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 More sharing options...
Mallos31 Posted November 24, 2013 Share Posted November 24, 2013 Does OoT use UVs? I've messed with UVs in like Maya and imported the models and they looked right, but I'm sure it probably calculates them differently. I'm sure an editor could be made in the style of Maya's Link to comment Share on other sites More sharing options...
Arcaith Posted December 3, 2013 Share Posted December 3, 2013 It does use UVs, but the range is x1024, rather than x1.0. It reads it as an integer rather than as a float. Link to comment Share on other sites More sharing options...
mzxrules Posted December 4, 2013 Share Posted December 4, 2013 [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 More sharing options...
xdaniel Posted December 4, 2013 Author Share Posted December 4, 2013 (edited) [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: 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 December 4, 2013 by xdaniel Link to comment Share on other sites More sharing options...
xdaniel Posted December 5, 2013 Author Share Posted December 5, 2013 (edited) 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 December 5, 2013 by xdaniel 2 Link to comment Share on other sites More sharing options...
haddockd Posted December 5, 2013 Share Posted December 5, 2013 Is this to be considered the "final" version oh great one? 2 Link to comment Share on other sites More sharing options...
xdaniel Posted December 5, 2013 Author Share Posted December 5, 2013 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? Hey, if anything I am not worthy to have such a good user base on here, and that's not meant sarcastically! Link to comment Share on other sites More sharing options...
Zeth Ryder Posted December 6, 2013 Share Posted December 6, 2013 Bug report Beta 8! Link to comment Share on other sites More sharing options...
haddockd Posted December 6, 2013 Share Posted December 6, 2013 Zeth..you know better Give as much detail as possible as to exactly how you came across the bug. It makes xDan's life much easier Link to comment Share on other sites More sharing options...
xdaniel Posted December 6, 2013 Author Share Posted December 6, 2013 Ah, in this case it's easy to come across it, as it's (presumably) messed up texture coordinates which I'm getting on my end, too, in that spot. Will look into that soon Link to comment Share on other sites More sharing options...
xdaniel Posted December 6, 2013 Author Share Posted December 6, 2013 Heh, that damn game... If I had a bug tracker, I'd close this as "not a bug" or something - or at least not a bug in SceneNavi: (And crap, I wanted to edit my previous post, not make a new reply <.<) Link to comment Share on other sites More sharing options...
Zeth Ryder Posted December 6, 2013 Share Posted December 6, 2013 Zeth..you know better 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 More sharing options...
xdaniel Posted December 6, 2013 Author Share Posted December 6, 2013 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 More sharing options...
Tsynk Posted December 6, 2013 Share Posted December 6, 2013 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 More sharing options...
Recommended Posts