Noesis Model Server

Noesis now comes equipped with a Model Server script. You point it at a directory, and it crawls through everything under that directory to generate a cache of converted models. You can then tell it to spin up a web server, which hosts an index of said models, along with the models themselves via an embedded WebGL viewer.

As part of this functionality, I added support for importing and exporting glTF files. The importer handles both version 1.0 and 2.0 files. I also took the liberty of implementing a Noesis-specifc extension in order to preserve some of the more common data that the latest specification still doesn't cover.

In order to use the script, as usual, just copy "tool_modelserver.py" from "optionalplugins\python" over to "plugins\python". The server is available from the Tools menu, but given the nature of the tool, it really makes more sense to launch it outside of a full Noesis instance. You can do this via the commandline:

noesis.exe ?runtool "Model Server"

This will launch an instance of Noesis without the GUI, which will stay running until you close the actual Model Server tool window. Once running the tool, you can specify a directory and let the script begin building the cache. After the cache is built, you can start the server, and connect to localhost:8080 to test it out. Additionally, some template files are provided in "scenes\modelserver". These allow you to customize the index and viewer pages. You can also switch over to whichever embedded glTF viewer you prefer. By default, the template embeds the Babylon.js Viewer.


You're also free to directly export anything you want to glTF, which you can manually upload/embed/etc. wherever/however you want.

As a side note, I was really hesitant to support glTF. The initial specification was quite monstrous, and while 2.0 offered a great deal of improvement, it still got so many things wrong. To name a few:

• The PBR implementation in 2.0 lacks decent support for reflectivity in non-metallic materials. This resulted in the need to go back and add an extension to address it. As part of this extension, glossiness was arbitrarily chosen in favor of roughness. This needlessly adds another layer of non-uniformity, which is why most engines don't make the distinction.
  
  • I came across some rationale for not making this part of the spec, which was along the lines of "it adds some expense", and this is quite wrong. It's hard to argue that an extra two channels is going to hurt anyone when your specification already forces the implementation to either compress textures on the fly or just live with a bunch of massive RGB(A) textures in memory. The BRDF is identical, which means that no branch is necessary, whether deferred or forward. All of that aside, even, a per-material specular color and perhaps a monochrome intensity certainly would have been better than nothing, and would have been on par with the proposed model as far as memory and ALU cost.
• The latest specification is still full of raw integers representing GL state/enum/etc. values. While mapping these values isn't difficult, it's so much more offensive to see this sort of thing in a JSON standard. It speaks to how unnecessarily GL-coupled the specification was to begin with.
• The standard for animations is still quite confused, with many viewers choosing to combine all of the "animation" objects in a given file rather than treat them as separate sequences. The official sample repository also still has some 1.0 files which encourage this behavior. The Noesis exporter has a -gltfoneanim option to hack around this, but it's somewhat disappointing that it was necessary.
• I am thankful that we are, at least, no longer going whole-hog on GLSL. However, because 1.0 was such a mess, 2.0 still suffers with a lot of the cruft that came from it. You could tie the above point about GL integers into this as well. The collective error here indicates that the decisions being made are not being given adequate forethought. In addition to the more fundamental missteps, you can see this lack of forethought in the little things too, like the fact that it took another revision to decide that the GLB spec should use a chunk-based approach. It all turns into more implementation cruft for anyone looking to support the full gamut of data, and the really unfortunate thing is that none of it should be necessary.
• I can already tell that compression is going to become a mess, and there are most likely going to be multiple competing standards for both lossy and lossless compression of assorted data types. I'd venture a guess that there are some serious flaws in the design methodology that was employed in drafting this specification, and I see a freight train representing its application to something as ambiguous and research-oriented as targeted data compression.

I could definitely go on, but the fact that this format is being advertised as the "JPEG of 3D" is really painful. It seems to inherently suffer from a narrow, GL-centric world view, and I feel that coming up with a true standard would best be done from the ground up at this point. Unfortunately, though, glTF is the thing that everything seems to be supporting, and I didn't want to deal with writing my own WebGL viewer for another format that no one will ever use. So, I became a little part of the problem. Such is the story of the ages.


Gentiana and Aerith, expressing stern disappointment in glTF.
In any case, whether or not it's an ideal specification given its lofty aspirations, Noesis supports it now. At least, the parts of it that were essential to the mission at hand. The Model Server script should also be a useful reference for anyone else looking to employ similar forms of automation. You could, for example, write a script which automatically exports a model to glTF and uploads it to some other site/service. The Noesis Python implementation is fully stocked with sockets/SSL/etc., so nothing should be stopping anyone from doing something like this. You could also get a lot fancier by invoking separate Noesis instances to process models, and farm out the cache building if you wanted the process to scale appropriately for massive data sets.

If anyone else decides to create the new 3D model standard of the future, give me a call first.

Comments

3 comments in total.
Post a comment

roni

January 11, 2022 at 6:33 pm (CST)
« [..] and I feel that coming up with a true standard would best be done from the ground up at this point. » What kind of standard will you come up with ? what features would be keys for you ? There could be so much different type of data in model files nowadays I wonder if we would required different algorithms per chunks-type. On a side silly note, I've been using glTF to export from old NIF recently and got astonished from the lack of half float buffer support.. well I see the GL-centric point of view now. I'll pray the spirit world for you to join Khronos ;)

chaoz_madoshi

March 2, 2021 at 10:33 pm (CST)
My translator works very poorly with such English (although usually there are no problems with the translation of the same marathonrecaps and its articles on FF Unlimited), but I still try to understand at least a basic understanding of noesis Are you its creator, or just writing guides on it? If the former, then it turns out that the presence of the Sephiroth model from Dissidia in Garrys Mod we owe you?: D

sixcentgeorge

January 12, 2020 at 4:32 am (CST)
the idea is very cool ..a webserver is a great thing that was cool at the time of xp ... it is something that will help cooperation between the map and model makers..

Post a comment

Name:


Enter the following (refresh if you can't read it):



Comment:

Stream Tags

Projects

Everything

Personal

Analysis

Indie

Technology

AVALANCHE

R-Cube Engine

Modding

Game Design

Commercial

iPhone

Pleasure

Recent Comments