JeffR

Az and bloop did some testing and didn't note any major issues here, so it's been merged in.

Heh, yeah, they're separate(though obviously you could conceivably embed the node/web graph uis into a window in the mainEditor.

And yeah, the idea of it being a good framework/backend for all the window management stuffs, and then you just handle the children controls inside it as normal was the plan. Would make control of the overall editor much cleaner without complicating the tools' ui code itself.

For the near term, I agree that the node/web graph uis are probably more important, but feel free to muss with the editor one if you think itd be useful :)

Lemme know if you've got any questions or ideas on the code.

Mud asked me about making a topic to discuss the editor, node and webgraph UIs I'd been working on to cover how they work currently, and what work needs done on them, so here we goooooooo.

First, the current repo:

https://github.com/Areloch/Torque3D/tree/NodeGraphUIs

There are 3 new ui controls in here.

guiMainEditorCtrl, guiNodeGraphCtrl and guiWebGraphCtrl

I'll cover the basics of each one

guiMainEditorCtrl

guiMainEditorCtrl was a test into creating a modern, floating/dock based editor UI.

You may remember it from my dev blog, but here's an image or two:

http://ghc-games.com/public/hmm2.png

http://ghc-games.com/public/hmm4.png

http://ghc-games.com/public/hmm5.png

Basically, you have floating windows that can be dragged and docked by dropping them into hotspot areas.

You can create the UI easily enough like so:

%editorUI = new guiMainEditorCtrl();

Which spawns the blank slate main panel. From there, you can spawn a window:

%editorUI.addWindow("Window Name");

This spawns a floating window in the main view. Clicking and dragging the window's tab will let you move the window arround, and you'll see white region guide lines. moving the window into one of the quadrants will preview what the window would look like if docked there. Releasing the mouse button will dock the window.

Clicking and dragging the tab will break the window out of the dock, allowing it to be moved around again. You can spawn another window and find that the windows themselves can act as dockable spaces, so you can easily nest windows in complex layouts this way, while still being able to quickly rearrange everything.

The intent would be that the windows are proceduralized via the guiMainEditorCtrl, but then you'd have regular gui controls in the main view area, such as the game view, a scene tree, or whatnot. This control just manages the main layout and drag/docking functionality.

Todo would see the docking finalized, including being able to dock to a window's tab bar, adding it as a tab rather than a split sub-view, and allowing various customization including color, dock guide sizing, and exporting the layout settings for customization reasons.

guiNodeGraphCtrl

guiNodeGraphCtrl is a little more complex than the main editor one, but still follows the same basic design idea to proceduralize the gui stuffs.

It's purpose is to do a nodegraph layout that's usually used in visual programming and the like. An example of the end result would be like UE4's blueprints:

Like the main editor, spawning is easy enough:

%nodegraph = new guiNodeGraphCtrl()
{
   extent = "500 500";
};

And from there you use the script commands to add nodes, and sockets to those nodes.

%nodeGraph.addNode("NodeA");
%nodeGraph.addSocketToNode(0, 0, "In");
 
%nodeGraph.addNode("NodeB");
%nodeGraph.addSocketToNode(1, 1, "In");

You can then click nodes and drag them around, click-drag to select multiple nodes, and if you click-drag an out socket(sockets on the right side of the node) you can drag to connect to an 'in' socket on a different node.

guiWebGraphCtrl

guiWebGraphCtrl like the nodegraph, only it's in a web arrangement. In the end it'd be used for state machine editing, and look something akin to this:

http://answers.unity3d.com/storage/temp/14180-mecanim+1.png

Like the others, spawning is easy enough:

%webgraph = new guiWebGraphCtrl ()
{
   extent = "500 500";
};

And from there you use the script commands to add nodes, and sockets to those nodes.

%webgraph.addNode("NodeA");
 
%webgraph.addNode("NodeB");

Then you can create a connection to another node like

%webgraph.createConnection(0);

You'll see this creates a white line from the originating node to the mouse. Clicking onto a second node establishes a connection and draws a wire arrow to inform you the direction the connection goes.

I've got more scripts at home that do pop-up menus I'll get uploaded when I get home tonight, but this should work for a good starting primer for the UIs.

Sounds like an interesting idea!

If you're starting from scratch, then it may be worth you looking into the proceduralized UI I was messing around with a few months back, in this branch: https://github.com/Areloch/Torque3D/tree/NodeGraphUIs

Specifically, the gui/controls/guiMainEditorCtrl files.

If you don't remember, it was the one that was set up like this:

http://ghc-games.com/public/hmm.png

http://ghc-games.com/public/hmm2.png

http://ghc-games.com/public/hmm3.png

http://ghc-games.com/public/hmm4.png

http://ghc-games.com/public/hmm5.png

It was intended to have the flexible docking/floating windows that more modern editors use for their interface. The window/docking stuff is procedural, but you'd nest regular gui controls inside them as needed, was the plan.

Not an obligation, but may be useful. Feel free to grab it, poke it, and/or ask questions about it. I'd be glad to help :)

Yeah, that's basically what I was looking at for the EditorTools.

You never leave the world editor(short of something COMPLETELY different, like the shapeEditor), and just do a WorldEditor.setActiveTool(myNewTool);

This makes myNewTool intercept the input events(mouse down, mouse up, input key, etc) and piggybacks the render event. The tools can even be set to filter what inputs they'll intercept. So you could leave the RMB to control the editor camera, for example.

Because of the way it's set up, it'd be easy to implement simplistic tools in pure script, if you wanted. You could easily rig up a simple object painter tool purely in script with this because the intercepted inputs trigger script callbacks.

It'd also go a long way to solve the weirdness that people have encountered with stuff breaking/overlapping when switching between editors, because there'd be fewer moving parts.

As for separating the editor out to be independent, I'm either way. Both integrated and independent have their pros and cons.

It'd be an interesting experiment to rig up a very lightweight editor(just the world editor, for example) as independent to try it out, and if it seems like it'd be workable, it could have all the other stuff layered over top.

Also, I love utility scripts :)

Yeah, definitely good points.

Well, it'd be fairly easy to have some stuff that handles the editor camera stuffs contained into the tools folder specifically. We could also expand out the editor settings menu to flesh out stuff like keybinds, mouse sensitivity in the editor, etc.

This way, the editor will be consistent, regardless of what kind of game you're making.

Also agree about the editors having self-contained guiProfiles.

It's just that there's so many controls in the tools it's gunna take a bit to do, haha.

If you're going to be stepping back and approaching the work with a Lite version based on the current editor, it may be a good time to present something I'd been working on as you may have a use for it there.

Basically, rather than needing separate, full, custom gui controls for each editor, we'd approach it from the single world editor that then enables a tool class that intercepts the inputs to operate.

https://github.com/Areloch/Torque3D/tree/BrushEditorToolTesting

So, for example, rather than needing a guiRoadToolEditorCtrl, which acts as a total replacement of the world editor, including replication of all the base editor functionality, you'd have RoadTool like the BrushTool as i've got it in that branch. When active, the world editor continues to operate exactly as usual, but the tool intercepts the input calls and can also render it's own stuff on top of the world editor view.

This keeps the tool code a lot more minimalist and minimizes how much crap can break when trying to switch tools around. Figure you may have some use with it with all your editor work, so I thought I'd mention it ;)

Keep up the excellent work dude!

Maybe you need to render a shape or small demo scene in the Gui, since the Gui itself does not seem to be affected by the brightness settings.

Oh, that's actually a good idea, I think that may work.

I'll give that a shot this evening. Thanks for the idea dude!

The graphics layer would need an OpenGLES or Metal implementation in order to do the renderstuffs, but the SDL implementation SHOULD pave the way from a platform layer side of things.

@elfprince13

Yeah, SDL should be defaulting to on if you utilize cmake. Also, just for simplicity's sake, could you toss a link to the PR you did in here?

I'd mentioned it in the chat, but I pushed an update that should fix the shader error. Make sure you do a recompile.

And yes, one of the known issues is the brightness menu UI not adjusting to reflect the changes. I'm trying to think of a way to fix that. It does work in-game though.

And the defaults button should only impact the particular menu(controls, graphics, audio, etc).

Also, the latest update has an example of the alternate, module-oriented layout. Give it a look an tell me which you think is better!

I started playing with the new BaseTemplate, it look much better than before.

The only things I'd change for now is the PostFX folder in data/scripts/client. Maybe there's a reason I don't know but shouldn't it be better if placed inside the core folder. How I'd like the core folder to work is that when something got changed in the template about shader/gfx/postFX, I'd like to simply be able to replace the core folder with the updated version.

So, I guess I would also suggest to place the Shaders/ folder in the core folder. (But again, I don'T know if there's a reason for adding it in data folder)

EDIT: As personal opinion, I would not place the datablocks file under scripts but keep them like we are used to under art. Also I started using a new system for datablocks because I hate it to have the datablock of the player for example under a different folder. My solution was to add a check for *.db.cs files when loading the datablocks, so you can place the datablock beside the art it related too. Some are still in their original place but I find it usefull for specific shape datablocks like Player, Vehicles, AI, etc. I'm not suggesting to use it for all datablock but maybe we could add a similar system in the loadDatablocks function so anyone could use it if they feel it's suitable.

EX: Right before loadDatablockFiles( %datablockFiles, true ); you could add:

 %filePathScript = "data/art/*.db.cs";
	for(%file = findFirstFile(%filePathScript); %file !$= ""; %file = findNextFile(%filePathScript))
	%datablockFiles.add(%file);

 

Also I hope I'm not out of topic... Cause I haven't read the goal of this topic which I will do now...

EDIT2: Well I seem to be out of topic since I'm talking about adding scripts, right? Sorry for that, I can move it elsewhere since I think it's pretty usefull and could be add to any template/project simply.

Nah, suggestions for useful base utility scripts is always welcome :)

Regarding datablocks: The reason I moved them from art to scripts is because datablocks, themselves, aren't actually art, and are created and utilized through scripts, so it made more sense to bundle them together that way. The formatting of datablocks themselves is as a script-executed object even. The idea of having datablocks have a separate file extension is interesting though. May not be a bad idea.

As for the PostFX/Core thing:

Core is basically intended as "This is what's required to get the engine to run". Everything else goes into data. PostFX specifically, are very prone to be project-specific, so implementing the individual postFX as a project consideration made sense, as it'd let people add or remove postFX without having to worry about impacting the loading of the engine stuffs itself.

I'd contemplated moving the common shaders into core though, as those are less to change short of a project doing major customization work.

<3

Nah dude, go for it! Contribute what you want. :)

If you're unsure of how something should get organized(like under Art, or Scripts in the case for 3ds max scripts or the like) then feel free to ask for suggestions, but the idea of the wiki is being able to go in and add in stuff you feel is useful.

For the max scripts themselves, I'd say probably under the Artists section, and yeah, there should probably be some sections on the artists page for Blender, Max and Maya for people to add in pages for easier browsing there.

As for the visibility of the wiki: do you mean having something alongside the Quick Links and FAQ buttons at the top of the forums?

That probably wouldn't be a bad idea.

Was using VS2013.

And yeah, I put it to the PhysXSDK path specifically from the grabbed repo and extracted folder. Pretty sure you don't have to restart Windows to get env vars to take effect, or at least I don't remember needing to do that...

Went to try testing this last night(sorry for taking a bit to get to it) and I went about grabbing the github build of PhysX, set up the environment variable, and then made sure I was using the latest of CMAKE. Ran through the config step though, and I got no errors, but it wasn't able to find the PhysX paths.

Any ideas?

No opinions on the layout ideas?

Sorry, I didn't mean "well just switch to 3.8 right now". Just wanted you to grab 3.8 so we could see if the issue went away in the newer version of the engine.

As it didn't, that implies it's an issue that hasn't been fixed, or an issue specific to your system.

Can you provide a bit more detail on why you think it ties to the live update? That lead sounds promising.

Anything in particular you'd like to see updated?

Little easier for someone to get started if there's some highlights you feel should get attention first. "Documentation and Tutorials" is a pretty big target area ;)

Alrighty.

Forest issue should be fixed. Screenbrightness default fixed. Started fixing audio/camera, but those are a little more involved because they don't have a simple autodetect function to call. Almost got those sorted though.

I'm seeing the values save when changed, so double-check that. If it still doesn't stick(make sure to press the OK button, not cancel or hit esc) then it may be a permissions thing with it not wanting to save the prefs file to the game's dir.

Az did provide a lovely function written up by Steve that gets the prefs path from the OS' user directory rather than the game dir, which could be in a protected path. It's not used yet, but the function is in there now and I'll be shifting the template to use it in the next update.

Also per Az's idea, the logo on the main menu will, when clicked, pop open the forums here.

The warning/faileds should be corrected for the level load now as well, this includes the testSound/cheetah_engine errors.

Fixed the 'need to press twice' for the editors buttons, and also for simplicity changed the world editor to open to the default blank level rather than trying to crack open the choose level menu in order to reduce hardcoding. If you're already IN a level, it'll just stay in that one.

Adjusted the size of the main menu buttons to fix the weird overlap. Uses a dynamic control array now.

The GUI editor also will load taml files now.

Ok, so, speaking of directory layouts, one final thing I wanted to bring up here for us to suss out before we lock this in properly. Namely, how to handle drop-in packages, such as art, gameplay kits, etc.

As-is, the current setup is better, as it should just be a matter of dropping the files in place and exec'ing them, rather than needing to worry about package overrides and the like, but it doesn't really handle overriden files that cleanly.

For an example case, say you have the base template, and grab a FPS starter kit, which has it's own art, levels, and menus. The art and levels aren't really a big problem, but the menus would likely include a main menu in place of the default one, as well as the playGUI and all that.

Replacing existing files isn't terrible, though a bit less than ideal. So the other approach that occured to me is utilize the modules approach more thouroughly. Figured I'd bring it up here, get peoples opinions on if it's worth it, or stick with the setup as it is now.

Basically, adjust the layout of the data directory to package like content into a module, such as UI stuffs, gameplay code and art, specialied client/server/level loading code, etc. This would make it a lot easier to take a art package or starter kit, and just drop it in and maybe have to add a little bit of glue-code, but it'd prevent the need of overriding files, and in the unfortunate event of deciding you don't like the package, having to manually rollback/uninstall the files associated with it and replacing them with the old ones.

To that end, the layout would look something like this with this approach:

The root game directory wouldn't see a change.

http://ghc-games.com/public/game_root_layout.png

The data directory would see a change though, with the stuff inside being compartmentalized to what package is to what

http://ghc-games.com/public/game_data_layout.png

Inside one of the package folders, it'd have a module file which is automagically indexed by the module system and the script file the module file calls to for it's create/destroy methods. This would mean that the installation of a art or gameplay kit package would be as simple as dropping the package's folder into the data directory and it's installed, you'd just need to handle the interop gluecode yourself(such as your gameplay code calling the UIs).

http://ghc-games.com/public/game_ui_layout.png

So, thoughts/opinions on this sort of layout? It seems like it'd make using packages/kits a lot easier, but I'll admit the layout like this feels a bit more "loose". It'd also be really convenient for mods for games that care about that sort of thing, as a mod could just have a package directory and poof, it's a thing.

So yeah, lemme know what you guys think about doing this layout, or if you've got an even better idea how to handle package/kits usage. Or just think the whole idea sucks dick and stick with what's there in the new template now. Once we figure on this, I'll lock in the directory layout and we'll just need to focus on bugfixing and handling the last little polish issues.

Yeah, I'll echo what Dwarf said. Go ahead and grab the latest and follow the same steps. That'll at least narrow down if it's something that changed between 1.2 and 3.8.

If I see that I only really see it when first connecting to the game. Are you performing any editor actions in particular when this is occuring, such as editing terrain or something?

@Johxz

https://github.com/GarageGames/Torque3D/pull/954 mentions an issue with that one where you can't paint the last pixels of the terrain. Do you see that happening, or does it work totally fine?

I'm not super worried about that, as at worst, they could crack it open and see what's in it.

The reason I figured for 'misc' instead, is it'd also work as a place to stick the white/gray/black, etc images and othe rmisc utility images.

@Janders

It's a possibility, sure, but at the same time, people still contribute PRs to Unreal as well, and there are lots of people that just toss stuff up for free to the Unity store, even though it's possible to sell it on the store instead.

Some people just like contributing. It's possible that major, shifting features could become less common in the face of the opportunity to sell it, but there's definitely people that don't especially care about that, and practically no one is gunna try and sell a bugfix or the like, so at minimum, fixes and minor improvements would likely be just as common as they are now.

That said, as a whole, I think it's probably for the better to at least have that avenue. For people that aren't as comfortable with core development, such as Duion, being able to pay a bit of money to pick up a game code starter kit would make perfect sense, and that isn't the sort of thing that's likely to be rolled into the core repo.

Same could be said for a programmer that could make the game code, but needs some art and the like.

The only potential hangup a store could see is pertaining to major features implemented in the engine code side of things, and as I said above, I'm not sure that it'll be as drastic a shift as some may fear it is.

Especially if we have alternative payment methods like being able to hook to funding campaigns like what Rich has going or tip jars.

But there will always be some people that just like contributing stuff for free, either because they like the challenge, or want to make it so others don't have to deal with some crap they had to put up with, etc.

@Johxz and @Azaezel

Yeah, the sub-forums thing Az kicked this off with is probably what we can go with as a compromise for the near-term until we can hash out the store enough that it works, since as I mention it's not there yet.

And even once the store DOES go up, those subforums can still be used to highlight products put up on the store, or freebie contributions/tip jar/buyout projects.

That's pretty cool.

Got a branch up for that? I'd like to play around with it as well.