SceneNavi - A simple Ocarina of Time level editor

[haddockd]

xDan,

 

You KNOW I LOVE putting in try catch blocks. Plus I always avoid using arrays and use lists instead. The only exception is if you have to reference the list element by index instead of iterating through the list. (OR a better idea is using LINQ to search the list for what you are looking for)

[mzxrules]

But you can reference C#'s Lists by index just like an array, and actually you can do it with any custom class if you implement an indexer http://msdn.microsoft.com/en-us/library/6x16t2tx.aspx

[Airikita]

Use associative arrays perhaps... those are quite useful depending on what you do.

[haddockd]

But you can reference C#'s Lists by index just like an array, and actually you can do it with any custom class if you implement an indexer http://msdn.microsoft.com/en-us/library/6x16t2tx.aspx

I know but anytime you try to access the array/list elements by their index, out of bounds are possible. I was just giving xDan crap about those out of index errors. No worries

[petrie911]

Moving waterboxes and moving actors really need to be separate options. I've had so many times where I try to move the camera while moving actors and move a waterbox instead. Which, combined with the lack of undo, means I have to reload the map.

 

Could you make it so that I don't have to close a scene before opening a new one? Also, a hotkey for opening a scene would be nice.

 

Would it be possible to have the program look for the room file in the same directory as the scene file? Right now, if I open a scene in a different directory from the last one, when it pulls up the room dialog box, it's still in the old directory.

[xdaniel]

Still missing features and fixes requested/suggested here, but because I finally want to get a new build out (after what, four months?), here it is regardless... As usual, find it via Beta 8's update function or the Update page. Would very much like some feedback for the GLSL combiner, and from Intel graphics users, in particular.

 

v1.0 Beta 9 ("You've Got Shaders In My Fixed Functions!")

• Added new GLSL-based combiner emulation, still missing certain rendering details (ex. automatic texture-coordinate generation for reflections)
• Added support for anti-aliasing and mipmapping in renderer; can be toggled from menu
• Changed application configuration to use Nini library instead of .NET Properties.Settings
• Fixed various bugs; combiner inaccuracies, display list caching, Scene TreeView generation, mesh header types, etc.
• Added experimental help system, displays help string in status bar when hovering over menu items; still needs work
• Various other OpenGL-related changes and additions (ex. extension checks)
• Various minor GUI changes (ex. status bar appearance, Options menu arrangement)

Need to really get back into things, implement various things ex. petrie requested, get the source out onto Github, and so on... I guess I'll start with that last point very soon?

 

Edit, source code now on GitHub: https://github.com/xdanieldzd/SceneNavi

Edited April 6, 2014 by xdaniel

[Xenix]

Got this:

It goes away upon clicking "OK", but I'm worried about possible problems.

[xdaniel]

It goes away upon clicking "OK", but I'm worried about possible problems.

Ah, a GLSL error, I kinda expected those to happen... I'm still a bit of a GLSL n00b, so I'm not yet familar with a lot of pitfalls there are with it, which include some drivers allowing certain code while other drivers don't. I did learn more about this while working on the OoT 3D model viewer, but hadn't improved SceneNavi's code based on that...

 

Anyway, in the meantime, try using the ARB combiner ("Options" -> "Combiner Type" -> "ARB Assembly Combiner") which should work on most reasonably modern, non-Intel graphics chipsets.

[SoulofDeity]

Finally, shader support!

 

 

Btw, if it helps any since you stated you're a little new to GLSL, here's an easy way to visualize how OpenGL3+ works.

 

 

 

• An framebuffer object is a container for a viewport to which you attach renderbuffer objects or textures to for the color, depth, stencil, or accumulation buffers.
•  
• A renderbuffer object is a single frame of a FBO that uses an internal pixel format. Unless you're doing off-screen rendering, you should attach these to your FBO instead of textures.

 

• A vertex array object is a container for vertex buffer objects. By default, you should always have at least 1 for static drawing.
•  
• A vertex buffer object is the declaration of a vertex structure. Each VBO has a set of attributes that are assigned to certain slots. Think of a VBO as a C struct and the vertex attributes as the members of that struct.

 

• A vertex attribute array is the declaration of a member of a VBO.
•  
• A uniform is a piece of data that is shared between both the application and it's shaders. Think of it as a public static member of a C++ class.

 

 

 

So pretty much, the process is:

• Create a FBO
• Create and attach RBO's or textures to the FBO for the color, depth, and stencil buffers.
• Create and compile shaders (but don't link)
• Create and bind a VAO
• Create VBO's

and for each frame when rendering an object:

• Bind the VBO that this object's vertices use.
• Bind the buffer data of the VBO to your object's vertices
• Bind your vertex attribute and uniforms locations
• Link and use the shader program
• Draw arrays
• Unbind your shader by using a null program

 

 

 

I hate how most tutorials just throw code at you without explaining what each object does...

[xdaniel]

First, SoD: Yeah, I think that'll be helpful once (or for SceneNavi, if) I go full-on OpenGL 3+; right now vertices, texture coords, etc. are still pushed through using glVertex & co. instead of VBOs. I ought to learn some more modern OpenGL, but old habits die hard

 

Also, I put out a quick bugfix release, mainly to fix complete breakage on lower-end hardware. Note that the update function in Beta 9 and below will tell you that "v1.0 Beta 2305" is available - not a bug, but a change in versioning that those build can't cope with. It'll be Beta 9a once downloaded

 

v1.0 Beta 9a ("My First Hotfix")

• Added additional sanity checks to prevent potential EntryPointNotFoundException and NullReferenceException, especially on lower-end hardware
• Changed versioning code to allow for hotfixes

Haven't yet fixed the GLSL bug Xenix is getting, that's next on the proverbial list.

[SoulofDeity]

Haven't yet fixed the GLSL bug Xenix is getting, that's next on the proverbial list.

 

I'm getting the same error as well; not just with the experimental opengl rendering, but with the ARB one as well.

[xdaniel]

I'll really need to fix the shader code, huh... Will do so later during the day; 1:15 am right now. The reason you're getting it with the other combiner types is that many known combiner setups (or rather, their ARB and GLSL interpretations) are precached, which caused quite an FPS increase with the ARB combiner - not sure if that's even needed with GLSL. But regardless, the shader code will be fixed as soon as possible.

[xdaniel]

Check the update function or the latest release on GitHub:

 

v1.0 Beta 9b ("Hotfix Redux?")

• Fixed generated GLSL shader code somewhat; should fix float conversion error during shader compilation
• Changed combiner emulation initialization; should now only try to initialize a combiner type when selected by user, not all on every startup

This should take care of that float conversion error Xenix and SoD got, I hope...

 

Edit, just for fun - a visual history of viewers:

 

 

(Dates range from taken from Readme files/About boxes, to guesstimates based on forum posts and datestamps)

 

Experimental N64 Object Viewer v0.45 - August/September 2008 - the hacked up NeHe sample:

 

OZMAV v0.8 - late 2008 to November 2009 - the Win32 API behemoth:

 

OZMAV2 v1.0 - February 2010 to late 2010/June 2011 - the console-based cross-platform attempt:

 

SayakaGL v0.2 Public - January 2011 to April 2011/mid-2012 - the first steps in C#:

 

SorataVSE v0.0 - late 2012 to February 2013 - the failed all-in-one:

 

SceneNavi v1.0 Beta 9b - May 2013 to present - the simplified and proper one:

 

 

[Antidote]

Got that when attempting to load a ROM.

[xdaniel]

Got that when attempting to load a ROM.

Looks like it's happening here, and because the RAM segment this rooms header command is trying to load its rooms from, isn't set up at this point...? A case of "shouldn't ever happen, so why bother with error checking? ^__^", I guess.

 

But it is odd that this is occuring... What ROM are you trying to load, standard MQ Debug or something else? Already modified or vanilla?

[Antidote]

Standard MQ Debug ROM, no changes.

[Rinku]

Hello,

I have a quick question: Is it intented that Special Objects and Soundtracks can't be saved yet?

Sorry if this has been asked before.

 

Thank you for reading!

[xdaniel]

Super-late reply, although for a while I wasn't sure if I would drop SceneNavi or not... anyway:

 

Antidote: I still don't know why that happened for you. I'll add some sanity checks to the code I mentioned back then, which won't help with the problem, but I really can't think of anything.

 

Rinku: I'm pretty sure they should save, code for that is in place. I'll have to double-check if it actually does save, tho, or if I messed up somewhere...

 

The replies aside, as implied I haven't dropped SceneNavi, and actually pushed a small commit to the repository yesterday: Table editor changes & versioning - References to "exit table" changed to "entrance table", entry numbers added to both tables, more tooltips; versioning code fixed for non-hotfix builds (i.e. without letter suffix)

[haddockd]

Nice to see you are still working on this xDan!

[xdaniel]

Aside from a future combiner rewrite, to properly support fog as mentioned elsewhere, there's one tiny thing I changed today: the camera's field of view.

 

The actual game VS SceneNavi's new FoV:

 

 

...pretty close now, aren't they? And that very minor difference in angle (barely visible unless you switch back and forth between the two screenshots in another tab or something) comes from a not 100% identical camera position between the game's debug camera and SceneNavi.

 

(Also, mainly as a note to myself: OpenGL camera position = -(in-game camera position * OpenGL scale))

[Three_Pendants]

Looking pretty good! A nice change I would say.

[Airikita]

Oh, shader support? (soz for late reply)

 

I would need to test that, shaders are notoriously nasty on N64... Check 80001FF0 for errors when running shaders plz, just in case. I mean, I'm sure you have the right shaders, but I know from Majora's Clock that it can be picky.

[xdaniel]

I mean shaders as in, actual vertex and fragment shaders on the PC side of things, used to emulate the N64's color combiner. Not the sets of display list commands in OoT that people call "shaders" for some reason. But if I ever do implement rendering of ex. GI objects (or more than just maps in general), I'll make sure to run those commands.

[Airikita]

Oh alright, perhaps I was thinking of something else for some reason... lack of sleep makes me mix up things.

[Antidote]

It's the same thing with GC/Wii and TEV, TEV is very similar to the N64 combiner in many ways: You basically configure the pipeline in a relatively fixed way, but it allows for many different ways to combine textures into one (hence "combiner") that is actually far more flexible than the early programmable pipeline, which is why the GC/Wii and N64 are able to do things that are otherwise difficult using traditional pre-SM 1.0 rendering techniques.

 

While the N64 and GC/Wii don't have actual shaders, it's ability to be "reprogrammed" in such a way is very analogous to Shaders, so the confusion is understandable.