Feature requests: keyboard shortcuts, resource grouping, mesh preview


#1

I have a few things that for me would make Napkin a lot faster to use. See how you guys feel :slight_smile:

  • The ability to group resources in “folders” would do a lot to keep them visually organized and would make the list easier to work with. Instances can be organized into entities, but nothing like that exists for resources. Note that as far as I’m concerned this can be a pure editor feature; I have no need to include path structures in my calls to ResourceManager->findObject()

  • A helpful feature to allow mastering Napkin would be keyboard shortcuts to edit the next value in the property editor, create and delete resources, create and delete entities and add and delete components to and from entities.

  • In the property editor, it would be very nice if the panel would not scroll back up after each value change. When I’m working with a long list of uniforms on a MaterialInstance for example, I have to scroll all the way back down after each value I update, which can get really tedious.

  • Finally, the ability to preview a mesh would be helpful. I am currently working with a large number of meshes, which have been exported from a single FBX file. In exporting, geometry names are not applied to file names, and so it becomes an unwieldy task of figuring out which mesh is which. Yes, whoever supplied the FBX can also supply the numbering, but a “quick look” option would still be a nice to have for me.

I hope these make sense!


#2

The ability to group resources in “folders”

TL;DR
This is (again) a very good suggestion and would be fairly trivial to implement, but our architecture doesn’t allow for an immediate solution.

Longer story:
Like this one. we’ve encountered several instances where we’d want to remember editor-only-data, but as our file format has been designed to be as light as possible, while still being human readable, so we’re reluctant to store this (say, folder data) in the run-time json file.
That said, we cannot ignore this and will have to come up with a solution for this situation that is as future-proof as it is fool-proof (for example, a editor-meta file may go out of sync).

More keyboard-oriented workflow in Inspector

A replacement for the current inspector with proper tab-focus and keyboard support is underway. It’s not quite ready yet, so please bear with us :slight_smile:
As for the other key support; most of the editor actions can be embellished with hotkey support, Can you make a ticket, describing which existing hotkeys you’d like add for existing actions?
There might be different ideas about which hotkeys to use, but let’s have at it!

Property editor scroll back issue

Yes, this is very annoying and is currently being worked on. (Data signaling is being refined to be more directed in preparation of instance property support and the new property editor)

Mesh preview

We’ve been brainstorming about embedding a 3D view into the editor, which is going to be a lot of work. But what we could do beforehand, is to make a seperate NAP executable that will take any fbx file and allows for a quick zoom/pan/tumble preview. Napkin could then invoke this to make this an [almost] seamless workflow. @cklosters what do you think?

This is really good input, much appreciated, Ralph!


#3

Thanks for your response, Bas.
Note that these points are in no way urgent, just suggestions :slight_smile:

Regarding key combinations to trigger editor actions, for me creation and deletion of items is the most occurring action, and so shortcuts to that would be most helpful. I imagine that they could be the same key combo for all types of items, but depend on the context of where your current selection is. I.e. if you’re in resources and hit create it makes a resource, if your on an entity and hit create, it makes a child entity, if you’re in or on a uniform list, it creates a uniform, etc.
Deletion would then obviously apply to whichever thing is currently highlighted (using delete or backspace for this makes a lot of sense).
The only thing is that I’m not sure how to approach creating vs adding items. Hitting create on an entity, does that create a child entity or add a component to it? And adding a uniform, is that creation or addition?
Oh and one other thing regarding keyboard interaction: it would be really really helpful if you can use the arrow keys to navigate within the pop up list, e.g. to select the type when creating a resource or uniform. At the moment, you are forced to use your mouse to pick one.

Finally, for mesh preview I like your idea of a simple viewer. Maybe it could take .mesh files rather than FBX files?

Again, these are all nice to haves, and I suspect others will have opinions on some of these as well, especially keyboard shortcuts. I’m not a UX designer, but these are my two cents. Use them as you see fit!


#4

I like the idea of a 3D viewport in the editor or otherwise stand-alone. I can discuss this with Jelle and Ritesh, see if they have any thoughts on this.

It should in my opinion be used to display a single .mesh file as a material / mesh combination as defined in json in your app structure. Probably creating a simple scene on the fly that uses a RenderableMeshComponent to render the .mesh to screen using a provided material. If no material is provided a default material is applied.

I don’t think it’s impossible to get this running inside napkin, but it makes napkin always depend on mod_naprender, which is currently the case anyway (if I’m not mistaken). QT has OpenGL window support but the implementation is rather hairy, as I’ve used it before to display meshes coming from a different game engine.

Another good approach would be indeed to make a standalone viewer app, this app can be called from within napkin (RM -> display mesh), where you can select your material next, if no material is given (skip) a default material is applied.


#5

+1 for grouping resources in folders!

An additional reason why this is a good idea is that it makes merging (using Git) much easier when multiple team members are working on a project, since with the current “huge flat array” approach it often happens that Git ends up splitting objects in half all over the place because it is difficult to differentiate between old and new objects/properties. This makes merging a bit of a nightmare, frankly.

This implies that objects in the “Entities” list should also be grouped/nested properly in the JSON, for the same reason.


#6

Grouping in Napkin would be purely cosmetic and would not affect the json layout.
I’m going to defer to @cklosters when it comes to file format changes, I have a feeling this might not be that easy.


#7

So it’s not really a folder, but something more like a ‘resourcegroup’ ? And if I understand correctly, this is not about storing resources in separate files, more a json group that includes resources in an array?

I don’t think this is hard to implement and I can see why this improves the ability to merge, as groups tend to be serialized in a consequent fashion. To not break current functionality it would be good to allow ‘no groups’ but have the option to specify a group?

How does that sound?


#8

I believe this would indeed only apply to resources. So we’d introduce an additional (optional) nesting level at the root of the json file.

Something like this?

{
    "Objects": [
        {
            "Type": "nap::Shader",
            "mID": "Shader1"
        },
        {
            "Type": "nap::Shader",
            "mID": "Shader2"
        },
        {
            "GroupName": "FirstGroup",
            "Objects": [
                {
                    "Type": "nap::PlaneMesh",
                    "mID": "MyMesh1"
                },
                {
                    "Type": "nap::PlaneMesh",
                    "mID": "MyMesh2"
                }
            ]
        },
        {
            "GroupName": "SecondGroup",
            "Objects": [
                {
                    "Type": "nap::PlaneMesh",
                    "mID": "MyMesh3"
                },
                {
                    "Type": "nap::PlaneMesh",
                    "mID": "MyMesh4"
                }
            ]
        }
    ]
}