SceneNavi - A simple Ocarina of Time level editor

[HeavyZ]

Ah ok I unchecked it and the graphics are rendering just fine now. Thank you xdaniel, I've been looking forward to using this for a while now!

[xdaniel]

Alright, good to hear it works now

 

This also seems to be an example of how some hardware or drivers lie about their capabilities. The program uses the list of supported extensions, as reported by the OpenGL implementation, to determine if everything it needs is supported on the system it's run on. If a required extension is missing from the list, the program gives an "Extension Warning" message and disables combiner emulation, otherwise it should run with full texture and combiner support (multitexturing, etc). Apparently, tho, this Intel chip/driver says "Oh, I can do all that! Don't you worry!", but when the time comes to actually use those features, it just goes "Hey, wait, what? What're you asking for? glActiveTexture? glBindProgram? Uh, I... uhm... let's, uh, just ignore that and keep going. I mean, what could possibly go wrong... right?"

 

[HeavyZ]

Haha yeah it has definitely been a pain trying to use other programs. I'll never go back to Emachines again.

[Mallos31]

I'm sure some of you remember my old computer's problems with OpenGL. It said it supported OpenGL 2.0, but after running a lot of tests, it supported only 1.1 and below. E-Machines used to be okay, but they have actually started lying about their specs. I work at walmart, and see gamers trying to get them all the time because they are inexpensive and "powerful" and either bringing them back, or me just telling them not to get it, and to save a little more money. Also, never get a computer with Intel Integrated Graphics. They have MUCH lower specs than they say they do. You want something with a separate card, or an expansion slot for one. 

[xdaniel]

Know what? I just added a function called CheckForIntel to my OpenGL helper classes, which is now run just before the already existing OGL extension checks. If the program detects Intel-based graphics (by checking if the OpenGL vendor string contains the word "Intel") it tells the user that...

 

"Your graphics hardware has been detected as being Intel-based. Because of known problems with Intel hardware and proper OpenGL support, combiner emulation has been disabled and correct application behavior cannot be guaranteed."

 

...and, as stated, it just preemptively disables combiner emulation altogether, so as to avoid bug reports from Intel users I couldn't fix anyway, because Intel has such shitty OGL support. Should probably change the "correct application behavior" part, tho... something like "correct graphics rendering"? Because the program itself will run after all, but it'll not look as good.

 

[HeavyZ]

That's cool. I slightly feel like I've had a part in something big now haha and yes to correct graphics rendering

[xdaniel]

Changelog for Beta 6 so far:

• Fixes to Ucode interpreter to not reset certain parameters on display list calls (DL, BRANCH_Z); fixes missing textures on ex. Death Mountain
• Removed some unnecessary OpenGL function calls; gives notable FPS increase in many cases, such as certain temples
• Added more fallbacks for lower-end hardware, added detection of Intel graphics hardware to disable combiner emulation regardless of the hardware's reported capabilities
• Fixed room display list caching; now no longer re-renders rooms on every scene change, even if a room has been cached before with the same settings (i.e. textures en-/disabled)
• Slightly rearranged Options menu

Todo:

• Implement saving for individual scene/room files
• Fix borked texturing on Water Temple's first room's walls (works in OZMAV2!) Added LoadTextureBlock macro workaround from OZMAV2; now also tries loading textures after SetCombine command, in case macro detection alone didn't work properly
• ...probably more...

Edit: Finally started working on the Scene Metadata tab, can just change the BGM so far:

 

Edited July 25, 2013 by xdaniel

[Antidote]

Nice, keep up the awesome work xdan, sorry I didn't see the edit, was busy with my own project yesterday.

[xdaniel]

Got a bit sidetracked from the Scene Metadata stuff; added mouse-based picking of rooms, so, when in static objects mode, you can just click on a room to select it for editing (room actors, etc.), instead of having to browse through the treeview. This doesn't play very nice with collision polygon picking tho, so it's optional and disabled by default ("Tools" -> "Allow Room Picking" to toggle). Might change this behavior before the next version again, maybe have the program ignore rooms during picking when collision rendering is enabled or so...

 

Will add a few more options to Scene Metadata tomorrow or so, test everything I changed since the last build, then push a new one out in a few days. Probably won't get saving to individual scene/room files in just yet - more rewriting work than I thought - but I'll keep working on that too.

[HeavyZ]

You should make it so that it's possible to customize more with the music, like if it plays only at night, only in child, or adult era. If it has sound effects in it like howling wind, and ect.. You know, junk that isn't in the InstEd haha

[xdaniel]

heavy: I'm far from done with the Scene Metadata stuff, plus the infos about ex. howling wind were only posted a day ago by Strati, I didn't know about those. Of course I'll look into working that into SceneNavi

 

Also, I changed room picking the way I mentioned it in my last post: In static objects mode, and if collision isn't being rendered, clicking will select the room you click on. If collision is being rendered, rooms are ignored and collision polygons are selected by clicking.

[xdaniel]

Sanguinetti shouted a link to his HT tutorial about transition actors some 2 to 3 hours ago. I haven't actually watched it to be honest, I just skimmed through, but it still got me thinking: How can I, on my end with SceneNavi, make transition actors easier to understand as well? Well, the result is this:

 

 

First, for the two possible triggers on a transition actor, there's now one drop-down list for each to select the target room from, and secondly, SceneNavi now uses a double arrow to display transition actors instead of an actor cube. In conjunction, I think that those two things - as well as slight renaming of the options in the transition actor definition - will help with visualizing how a transition works. Well, at least with upright transitions you walk through, as opposed to ex. room-changing planes you drop through (think Deku Tree, 1F to B1F), but anyway.

 

For example, in the screenshot above, the pointy end of the arrow points to the "next room" or "where you're going", in this case the Deku Tree's main hall, while the flat end is the "previous room" or "where you're coming from", which here is the room containing the Fairy Slingshot. Does that make sense?

 

[haddockd]

Holy balls Batman! This is nice! I was wondering about easy transition actors and which room they are assigned to...I swear....

[xdaniel]

Current changelog for Beta 6 (italic are things changed since the last changelog listing):

• Finally added Scene Metadata tab, so far contains a few sound-related settings (daytime BGM, nighttime SFX, reverb); more settings to come
• Changes to transition actor handling; added drop-down lists for rooms to transition actor editing, renamed some options for clarity, changed transition actor model to double arrows
• Added mouse-based selection of rooms in static objects mode; only works when collision rendering is disabled; selects collision polygons as usual when enabled
• Fixes to Ucode interpreter to not reset certain parameters on display list calls (DL, BRANCH_Z); fixes missing textures on ex. Death Mountain
• Added texture loading macro workaround to Ucode interpreter, now also tries to load textures on SetCombine command; fixes a few missing textures, ex. walls in Water Temple's first room
• Removed some unnecessary OpenGL function calls; gives notable FPS increase in many cases, such as certain temples
• Added more fallbacks for lower-end hardware, added detection of Intel graphics hardware to disable combiner emulation regardless of the hardware's reported capabilities
• Fixed room display list caching; now no longer re-renders rooms on every scene change, even if a room has been cached before with the same settings (i.e. textures en-/disabled)
• Some refactoring to the program's internal data storage (i.e. which scene header is active and what it contains, which room header is active, etc)
• A few object picking bugfixes; ex. some erratic behavior when selecting things via middle-click
• More status messages, ex. for ROM loading and saving
• Rearranged Options menu

[haddockd]

I am not kidding when I say this is making me consider doing another full mod.

[Strati]

Knowing where is the front and where is the back could be worked in not just for transition actors, but actors and in general.

 

You can always learn the rotations, but here are my suggestions:

 

Have 2 different color shades in the green axis, one for the front and other for the back;

 

Having the axis center at 1/3rd of the axis line, so the front would get a longer line and the back a short one.

[xdaniel]

Been playing around with the actor cubes and axis markers. One thing I did was change each axis' color, because apparently X, Y and Z usually are represented by Red, Green and Blue, in that order. I had it as XYZ = GBR or somesuch before.

 

Now, second, I tried adding a "front indicator" to every actor by modifying the axis markers, and, well, it worked, but there's a tiny problem...

 

 

 

 

This looks fine, right? Clearly indicates the "front" of the guard; the gate itself and the signpost next to it also appear like one would presume regarding the "front". However...

 

 

 

 

Consider what should theoretically be the "front" of a treasure chest. The side from which you open it, right? Nope. The "front" appears to be exactly the opposite here. Also, while probably less of a problem, this works exactly contrary to the "where you're going" analogy with transition actors:

 

 

 

 

Ugh... any advice besides dropping this and reverting to the double-arrows for transitions, as well as dropping the "front indicator" for everything else?

 

[Strati]

This thing with the chest is indeed strange. I will even check that mini-dungeon I made to see how are the chests set there.

 

I thought that you would still use the transition doors arrows together with the axis, not discard them in favor of the cubes from before.

 

About the speech bubble pointer, I still think the different shaded back and front would be more simple to work with.

 

I'm just looking the pictures now and it appears that each cube side has a different color. I was with the image of Sharp Ocarina spawn points, that are just blue pyramids.

 

Guess I ended seeing a problem where didn't really exist one after all.

[Arcaith]

Since you have actor definitions, you could theoretically implement a 'front offset' variable for the actor for cases when the front isn't actually the front.

[xdaniel]

*facepalm* I DO have the actor definitions, yeah! The one thing that sets SceneNavi apart from other editors for the game, and I forget about it! Man, sometimes I'm pretty stupid <.<

 

Yeah, I could add variables to them, like a "front offset" in degrees (a double from 0.0 to 359.9 or something), maybe even a "render type" that determines what model to use (actor cube, something akin to a door, etc)... the latter of which I think is also like what Antidote meant on the shoutbox yesterday or so, not true actor rendering as I was thinking initially... or whoever it was and when. Anyway, guess I got some work to do later... when it's not 4:40 am...

 

...also, note to myself: Look at the bigger picture more often. And don't obsess about something if it's the dead of the night.

 

[Antidote]

*facepalm* I DO have the actor definitions, yeah! The one thing that sets SceneNavi apart from other editors for the game, and I forget about it! Man, sometimes I'm pretty stupid <.<

 

Yeah, I could add variables to them, like a "front offset" in degrees (a double from 0.0 to 359.9 or something), maybe even a "render type" that determines what model to use (actor cube, something akin to a door, etc)... the latter of which I think is also like what Antidote meant on the shoutbox yesterday or so, not true actor rendering as I was thinking initially... or whoever it was and when. Anyway, guess I got some work to do later... when it's not 4:40 am...

 

...also, note to myself: Look at the bigger picture more often. And don't obsess about something if it's the dead of the night.

 

That's EXACTLY what i meant 

 

EDIT:

On top of that, if you make it load Obj files or something, people could, theoretically, load those particular models by converting them from F3DEX display lists to obj's and use those.

[Kargaroc]

Never remove the arrows for the room transitions.  It's just about as good as you can get from a visualization stand point; the room transition should be a separate arrow from the actor arrows.  It makes it less confusing that way.  You can be sure you're modifying a room transition just by glancing at the window.

[mzxrules]

I mentioned this in another thread, but actor definitions should really have their actor number as part of the definition, not the file name

[â–²ChriisTiianâ–²]

I don't know if this can help, but anyway, it will be nice if you add something like this (from OVZMAP):

 

 

(Sorry for the buggy models, i don't know why happen this)...

 

 

 

So, you can use this as a guide when you are editing: NPC, Chests, Enemies, etc...

[xdaniel]

Bunch of comments to reply to...
 
Antidote: An .obj loader would mean another component to take care of regarding bug reports, etc. And while I already have a rather capable class for that, it's still not guaranteed to work right with every .obj thrown at it, considering how different modelling programs and exporters create different files, how loose the standard appears to be... There's also the, well, issue I suppose of users editing actor definitions - adding new ones is great and encouraged, but I don't know how I feel about editing existing ones... like when you update the program; someone might accidentally overwrite their changed definition with the vanilla one coming with the update, etc. Your idea is something I'll keep in mind and think about some more, tho.
 
Kargaroc: I'll make sure to have a, in some way, clearly separate model for the transition actors, no matter in which direction I'll go from here.
 
mzxrules: I dunno about that... What would the advantage be; would it just be "cleaner" or is there something else? Seriously, I don't know and am curious - this is more or less my first foray into XML documents, for one. Regardless, it would mean rewriting part of the actor definition reader, plus what should the definition files be named instead?
 
â–²ChriisTiianâ–²: That would be the "true actor rendering" I mentioned in my last post, and it's something I've decided against. Here's a post describing the reasons for not doing this in (my failed project) SorataVSE, which are also valid for SceneNavi, the first reason in particular.

 

Hope I didn't forget anyone or anything!

 

Edit:

 

Red side is that of the previous room, green side is that of the next room; arrow also points towards the next room. How's that work?

 

 

Also an example of some new actor definition properties, this one is...

 

<ActorDefinition DisplayModel="ColoredDoor" PickModel="Door" FrontOffset="180.0">

 

...with DisplayModel and PickModel being the names of models stored in a new StockObjects class.

Edited July 30, 2013 by xdaniel