FANDOM


I wanted to put this into a blog post, to summarize the current state of the project, without having to force people to dig through a huge wall of updates, since I first created that forum thread a month ago. In addition, I'd like to talk a bit about what's in store for the upcoming update, and plans for the future with this project. Obviously, since it isn't live, here yet, the viewer I speak of is the one currently on my test site.

The State of the Viewer

How it works

At the time of writing this, the viewer itself is completely integrated into the wiki, making use of a drop-down menu/button. This button appears immediately below the main infobox image, with the text "View in 3D" (once data has been loaded). Clicking, or choosing an option from the menu, will result in a pop-up window, similar to the gallery in size/position. This is where the model will load and display. The button will always load the "default" choice - for weapons, that means the "world" model, for armor, it would be the male version. The menu will contain any other display options for that particular item. This includes female variants, weapon mods, and 1st person variants for all weapons that have one. Each weapon variant that has a 1st person version, will have an eye icon on the right end of each line of the menu.

This button/menu will only appear on pages that have the "model" parameter added to its infobox template, which takes the GECK editor ID for the item in question.

Data, and what it supports

In order to make adding a viewer to a page, as automatic and easy as possible, it was necessary to store some of the data seen in the GECK (ESM files). As it's those files which contain all the information which ties in-game objects, to the models and textures it uses. However, there's a balance at play here. Add too much data, and the length of time between page load, and viewing the model becomes far too long. Add too little data, and it limits what can be supported.

So, currently this data supports nearly all objects in the "Items" and "Static" sections of the GECK. Armor and Armor Addon sections are mostly supported, however, it's still missing the information that ties the two together (for instance, gloves/hand armor), as well as the information regarding what parts of the character's model is "replaced" by a particular piece of armor.

This also means, that there currently is no data for NPCs, characters, or other things outside the scope of the viewer (i.e. interior/exterior cell data).

Utilities

One of the primary goals of this project - beyond the obvious, is to make sure that the day-to-day operation of it, doesn't depend exclusively on me or the staff. It should work like any other feature of the wiki - something that can be used, and contributed to by anyone. If someone wants to add a picture to an article, they don't have to contact the staff - they just upload, edit, and publish. Well, ideally, the model viewer should work exactly the same way.

So with that in mind, a couple of utilities were necessary to make that possible.

AssetLoader

Due to the fact that I can't just upload random files to this site, all nif (models) and dds (textures) files, have to be stored in a very...odd fashion. It essentially uses normal letters and numbers to describe the individual bytes that make up the file, so it can be stored as simple text. However, due to limits on how much can be on a single page, larger files need to be split up across more than one page. Finally, it uses slightly different letters than normal base64, because random normal letters will eventually spell out words that trip Wikia's spam filter. Like for instance, one model when encoded to base64, spelled out P*RN.

Since doing this all manually, would be horrifyingly obnoxious, I created AssetLoader. Simply drop some of your extracted textures/models into the pretty box, and it will identify the files, determine where it should be saved, check if it already exists, and automatically post them to the correct location(s). Currently it supports all Fallout 3, and New Vegas .dds and .nif files.

AssetLookup

AssetLookup is currently in very early development, but even at this stage, it's still useful as is. The main goal for this utility, is to be a one-stop location to get all the model viewer related information about a particular option. Including what models it uses, what textures, which ones are available, and which need to be uploaded. In its current state, the only thing it currently does, is allows you to search for an item by name (as it appears in the GECK), and will give you the infobox parameter for that item, so you can copy, and paste it on the page itself.

What I'm Doing Now

...other than writing this novel, of course. You might've noticed that it's been about 6 days since my last update on the forums, which is a bit more than can be considered "a few days". Part of what I'm doing has to do with that, which I'll explain a bit more below, but there's also some other stuff that needs to be sorted out before going forward.

The Problem

First off, so we're on the same page - so you don't think I've been hanging out with Aliens for too long, I'm going to do a brief primer on how a character model (in this case armor) works. If you already know, feel free to skip to the next paragraph. Anyway - like all models, it's basically a mesh of triangles, that meet at points called vertices. A texture gets slapped on those triangles, and that's what we see in game. Like real people, characters also have bones, which are animated. However, since unlike real people, they don't have muscles, the mesh has to bend and stretch to the bones, based on how much each point, is influenced by each bone. For instance, a point on a character's elbow, would be influenced by both the upper arm bone, and the lower arm bone, while one on the top of the bicep (upper arm muscle), would be influenced entirely by the upper arm bone, and so on and so forth.

So anyway, here's the problem: For the most part, the different parts of an armor model, are positioned the way they would be, if they were applied to the bones. But...not always. So the only solution in this case, is to do exactly that - apply the mesh to the bones.

So a significant portion of the last several days, has been planning out how to implement that - basically a combination of starting with the technique itself, and figuring out how to translate the nif data, to something compatible with the 3D library.

The Plan

As this project moves forward, I'm finding myself getting ever closer to a wall of sorts, so before I run into that wall, I need to work out a way of effectively knocking it down. This project started out as an experiment, to see if it was feasible to create a model viewer, on a hosted wiki. While the experiment was certainly a success, it's original focus was to do one, small thing. Every feature, or ounce of flexibility that's been added since, has been merely tacked on to a one-trick pony, and that pony is starting to buckle under the weight.

So long story short, it's time to dig through the viewer code, and restructure it, so it becomes a strong foundation to build off of, as new features are added. This way I'll be able to concentrate more on implementing the features, and less on how to balance it on that poor pony.

The Future

Obviously, at some point - hopefully not too long after what I'm working on now, the viewer will make its debut here. But that's not exactly what I mean by "the future". Rather, I'm talking about features. When that point finally comes, where the viewer is live here, the test site will continue to be used in much the same way it is now. Namely, for testing out new features, and changes without adversely affecting the "live" version, or Nukapedia itself. Think of it as a sort of live developer preview.

As far as future features go - one of the first will be the ability to load multiple models at once, and merge them together using a common set of bones. This will allow the loading of character parts, the character models themselves, as well as armor pieces (i.e. gloves). On the UI side of things, supporting more than one editor id in the model parameter of the infobox, would help a lot with armor pages, that also include helms or other objects. This would result in view options from subsequent items, appearing below the first one's entries in the button menu.

From there, we move onto the holy grail - characters and NPCs. I've only done some brief exploring with the facegen system, and how it's implemented, as well as the api for the 3D library, but it seems that it should be possible. It will take some time however, to implement, as it will require understanding the related files (tri, egm) and how to translate over to the library.

While it would be nice if, at some point, rendering of game map cells would be possible - the sheer amount of model/textures required would be excessive for the methods required to store the data. While it's not a question of whether the average user's computer could handle it, the length of time it would require to load up all the individual models and textures, especially split over multiple pages, would cause load times that were far too long for the benefit.

Conclusion

It's already come a long way in the past month, and hopefully within the next, it should make its debut here. I do plan on, likely soon after the next update, to write up a guide/landing page - to explain everything a user would need to know about how to use it, complete with pictures. This guide's talk page should also be a good spot for help, as well as reporting bugs with the display/parsing of models. Due to the way nif models are structured, there's no feasible way to handle every last "block" type ahead of time. So my only option is to identify any files that fail to parse, and use that information to add support for any missing types. While that should be pretty rare, the possibility still exists.

At any rate, as on the forum post - if you have any questions, suggestions, concerns or opinions - either regarding what's in this post, or from seeing the current state of the viewer, I'm happy to hear them, and respond.