Any suggestions for editor improvements?

[Chris Friesen]

I would like to hear suggestions for editor improvements to make.  I recently made a little quick menu.  I would like to hear peoples suggestions for improvements.   I have in the works an object browser for instancing objects faster.

There are 2 groups of problems. Picking stuff from the file system and moving things in the editor.

Here are the tasks that I would like to improve for picking things.

Instance Objects/"Prefabs"

Selecting Textures/Materials/Techniques

I think we can improve that process by adding components like:

Material Browser

Texture Browser

Prefab Browser

Make more things drag'n drop-able

In general the editor relies more on the file system and less on its internal resource paths/packages.  I feel like there is some natural impedance by abstracting the file system into the resources but then forcing the file system as the means of getting stuff done.  My little project has an additional non-default resource path which is out of band of the source for urho.  I structured it that way to keep everything clean but the editor does not lend well to multiple resource paths.  If we made the editor more centric around resources then people can drop packages in and the editor will behave the way the games behave and it could be a nice way of sharing components/techniques/etc...

Here are the tasks I would like to improve for moving things in the editor.

Moving things more accurately

I think we can improve this process by adding the following components:

Configurable editor viewports with isometric cams

A toolbar for accessing settings like snapping and a more discover-able method that doesn't rely on keyboard shortcuts for switching tranlsate/rotate/scale.

These tasks will take me quite a while (months) and I would like as much as possible to have any work benefit as many urho users so I would like to do work that is likely to get merged and fits the maintainers vision.  So if an idea is out of line or just sucks it would be good to know!

If you have read this long you should probably checkout this bad boy because it is an awesome feature i didn't know about:

    cache.autoReloadResources = true;

There are file system watchers that will reload script objects/textures and a bunch of other things.   I run the my editor, text editor, and the game simultaneously and enjoy real time updates to code.

Thanks,

Chris \m/

[Lasse Öörni]

Excellent ideas.

I sometimes wonder if the Urho3D editor should have "play" / "edit" modes like Unity, but the structure of an Urho3D application isn't constrained enough to make that work in a 100% solid manner. In Unity everything (including the main program script) is inside a scene object, while in Urho you also have the application script or program outside the scene, and you're able to define several scenes etc.

[Raster Ron]

Great stuff. In relation to the snapping tool, I would suggest the following with templates/profile feature:

* Decal Editor (similar to 08_Decals demo) for Terrain/Mesh

* Billboard Objects (ie. Grass) Paint or Scatter to Terrain/Mesh

* Scatter 3D Mesh (ie. Trees) with offset Y adjustment setting

BTW, where do I place the cache.autoReloadResources = true; will this be on the editor/game or both?

[Alex Fuller]

I've got a few things :)

I think perhaps an easy way to add extensions to the editor would be great. For example, instead of just file load/save, maybe a way to check in/out using your favourite external executable a bit like how importing models work with a call to AssetImporter.exe would be great, (like an svn checkout/commit or git update/commit, etc.) but I think it needs to be fairly general-purpose for customisation of a given pipeline, so maybe have it as an event and an easy way to make a subscriber which runs the right external program or angelscript function.

Multiple window support, I know SDL2 is designed for that but I think Urho3D needs some internal changes for this to work? It would be great to detatch the different editor windows (and I guess they only render the GUI in these separate windows not the scene itself). Also different views like orthogonal views a bit like the 4-pane view in Blender/Maya/DCC apps would be great too.

Extending the extensions idea, if you've ever used Maya or Houdini there's a concept of a shelf which lets you easily make an icon and attach a custom script to them. A shelf of sorts would be an amazing addition to add custom tools.

Custom controls for the editor to a config file would be great as well. I'd like to bind the new ctrl+space to tab so it works like Nuke/Houdini, and use alt + left/middle/right mouse for camera control... :)

-Alex

[Chris Friesen]

cache.autoReloadResources = true;  is already in the editor.  if you put it in the game game start section it will make updates from your filesystem live inside your game while you play it.

[Raster Ron]

got it, thanks.

[Alex Fuller]

Reading about data pack management from your first pose, my plan for bringing assets into the editor was to have a current repo using git-annex which constantly updates based on approved/committed and pushed assets as the main data pack, and an additional wip pack which overrides anything in the previous one which is local to the user. That way it's simple to work locally without affecting anyone else, and when ready, submit the results to git or svn which then can be integrated in.

I'm not too sure, but does Urho3D's resource cache work a bit like physfs or quake 3 paks where the last cache attached if the file has the same name it uses the one that was 'mounted' last?

I'm really glad the MIT edition of mongoose is in Urho3D now, I have some really cool ideas to integrate this with Tactic ( http://community.southpawtech.com/ ) to query asset statuses or change them. Failing that, calling python externally could work too.

-Alex

[Chris Friesen]

The editor already has snapping more or less.  It is in the preferences/settings.  It isn't quite a grid but it is kind of like one.  It doesn't turn on/off easy which is why i though adding snapping to the toolbard would be nice.

The filesystem is already abstracted but it isn't obnoxious in the slightest.  It is very lightweight and hacker friendly.  It maps a folder/zip literally within the application.

I agree that unity is too abstracted.  I never liked coding in it regardless of the fact that i am very proficient in both c# and javascript.

I had tried to make a focus action but i could not properly deconstruct the cameras model view projection matrix to position a camera  with an arbitrarily sized object.  /MATH FAIL  It would be really easy to make the camera look at something however.  I don't know if it should always look at something with Z forward or Y down or where the camera is presently.

[Chris Friesen]

Keybindings i think are a pretty easy win.  I like the idea of being able to run scripts on buttons.  I think we can solve a good number of problems by scripts rather hard coded functionality.  Attaching a script object to a button could be kind of cool.  I'll have to dig into that a little to see what it would look like.

[Alex Fuller]

In Maya you usually just make some small 'scaffolding' script code which tells the gui which icon it has and what script it should point to and any arguments, and maybe extra logic if you choose to do a right-click on it instead like some drop-down menu. I think this could be achieved by having a directory or environment variable set of paths which have consistent angelscript subclasses inside, and the gui representation being a BorderImage that points to some kind of icon image.

For the camera focus by hitting F <THIS!!!! That would be excellent. For the 'logic' perhaps if you raycast to the object's bounding box center point or the bounding box which encompasses the selection of objects, move the camera to the nearest hit, and then do a lookat to the center of the bbox, that would get what you want?

For snapping, it would be great to have it so you hold down a key and it does a 'grid' snap or a 'vertex' snap, in Maya you hold down v and move an object and it will snap to the vertex which is under that cursor.

This might be way out of scope for the editor as it stands now, but a generic finite state machine class which can be built using nodes (or 'logic bricks' to not conflict with the scenegraph 'node' name) in a similar manner to UDK's kismet or Blender's logic bricks could be a very powerful tool to build AI logic or animation states which could later be saved to xml. Maybe for just defining animation states easily would be great.

-Alex

[Lasse Öörni]

On Monday, September 16, 2013 5:06:27 AM UTC+3, Alex Fuller wrote:

Multiple window support, I know SDL2 is designed for that but I think Urho3D needs some internal changes for this to work? It would be great to detatch the different editor windows (and I guess they only render the GUI in these separate windows not the scene itself). Also different views like orthogonal views a bit like the 4-pane view in Blender/Maya/DCC apps would be great too.

Multiple window support is potentially messy and maybe something that would be best implemented in a separate editor application written in C++. For example you would need multiple UI roots, and also multiple render context management is something not-nice (check eg. Ogre3D code)

One way to circumvent multiple render context requirement is to actually render the extra windows to an offscreen buffer, copy the pixels to the CPU and then (on CPU) blit to the external window, but this naturally has a large performance penalty so you would only use that for something that updates on demand.

[Alex Fuller]

Hmm, perhaps another approach is to use the networking and spawn separate urho3d executables which connect to the main session which can then send/receive events. This might work well with just simple events and get/set attrs from the different windows. There would be considerable memory overhead having each window instance run their own set of textures/scene data so having multiple viewport windows probably wouldn't be so good, but making the attribute editor window and only loading in the UI data would be ok I think.

Thoughts? This might be a decent approach. :)

-Alex

[Chris Friesen]

What are multiple windows?  I don't know this ui paradigm?  Is it just shoving a 3dview in a resizable window?

[Alex Fuller]

Pretty much yeah, but I thought just for the UI items like the hierarchy, attribute, material editor windows, and they only have the UI resources loaded, no scene replication they only send/receive events.

[Chris Friesen]

That sounds like a nice way for doing play pause.  Point the play pause to a script.  There would need to be some code bootstrap to setup the network serialization.  A dummy script can be distributed.

[Chris Friesen]

I have been trying to get some play/pause stuff going.  I was thinking attaching a ScriptFile to the scene node would be a nice way to bootstrap the game logic.  I am having a hard time getting a ScriptObject out of a Scene though.  The scene inherits from Node but the scriptObject and GetScriptObject methods are not exposed to the scene.  Is this by design?

Thanks,
Chris

[Lasse Öörni]

On Monday, September 23, 2013 2:29:28 AM UTC+3, Chris Friesen wrote:

I have been trying to get some play/pause stuff going.  I was thinking attaching a ScriptFile to the scene node would be a nice way to bootstrap the game logic.  I am having a hard time getting a ScriptObject out of a Scene though.  The scene inherits from Node but the scriptObject and GetScriptObject methods are not exposed to the scene.  Is this by design?

The convenience access was just missing from the script bindings of Scene, as usually that is not done. You could have done it the hard way by accessing the ScriptInstance component, but anyway it should be committed now.
 

[Chris Friesen]

I have started work on a resource browser.  I have a question about enumerating those resources though.  There are 2 approaches I have found. 

1. cache.resourceDirs  -- which will not include packs (or so i think) 
   
2. cache.getAllResources -- not exposed to the script.  I have no idea how this method works.  It looks like entries get registered on the creation of the cache.
   

After i get a list of the resources it is hard to determine the type of a resource based on the filename.  There is ambiguity in xml/bin.  The 2 ways about it that i see.  I don't see the editor favoring storing lots of metadata in weird files so determaining the type is a matter of filename/path convention.

1. We can enforce the use of the standard folder structure
   
2. Propose a new filename convention by including the name of the resource type as an extension scene.xml, material.bin

Both of these methods can coexist happily as well.

By breaking the items into strict categories of their types we can do cool things like offer thumbnails of materials, models ect.

The alternative is to have a more file browser approach which is less opinionated.

Importantly is not as much how but the result of workflow.  Lasse if you have a say so as to the direction I would love to hear it.

Thanks,

Chris

[Raster Ron]

Having an Asset Browser for the editor like with UDK, Torque3D, Unity, etc would be great. As for the resource type, I would settle for the old filename extension checking approach for now and improve it later on. Another way I see it would be parsing these files. You can check the xml root node for identifying the type of resource or signature id if binary:

Post Processes: <renderpath>

Materials: <material>

Scene: <scene>

Objects: <node>

Particles: <particleemitter>

Models: UMDL signature

Package: UPAK signature

etc...

I think there's a Script API to manipulate XML files but I have not checked that out yet.

[Lasse Öörni]

Hi,
for an editor resource packs should be unimportant, these should be used only for final release builds, so you can go with only the resource dirs. I haven't wanted to invent different file extensions when the file itself is xml, so to parse the beginning of the xml file for the root element like Raster Ron suggested should for now be sufficient, if possibly a bit slow. Actually if you want to protect against weird situations, like someone naming an animation file .mdl, you also would need to check the signature from the beginning of the binary format files. It would be preferable to not require a rigid directory structure.

[Chris Friesen]

Thanks.  It seems pretty clear to me.   I will right the abstractions in a such a manner that improvement will be easy.  I'll see how  parsing performs.  If its bad we may need to write a dumb scheduler so keep the interface from blocking.

Another question is how to hande duplicate resources.  If there are 2 Material/Brick.xml in 2 different folders how should the editor respond to that?   Presentation is pretty easy to distinguish but resolving to a path which would not refer accurately to 1 or the other resource.

Thanks,
Chris

[Lasse Öörni]

If the engine has 2 different resource paths registered, and both contain Material/Brick.xml, the resource cache will use the first registered resource path to load that resource. As far as the cache is then concerned, the second copy doesn't exist and can only be loaded manually, ie. constructing a blank resource and calling Load on it with a file that points to the second path.

[Chris Friesen]

I saw the method for manually loading a resource but what I was trying to say is that I don't know how to take care of that problem for the user.  Since everything stores paths there is no way to specify a specific resource and doing so would undermine the ability to easy override the resource.

[Lasse Öörni]

Since the engine doesn't support multiple resources with same path sensibly I would say the best thing is to instruct users to not do it. In general, having multiple resource paths (with the exception of the CoreData / Data separation) should be an exception and I'd discourage it. If you compare eg. to Unity it always has only one project loaded, which has a well-defined root asset path.