JeffR

Nah, it's not mine. But I'd found it many years back and nabbed a copy because I thought it was incredible(the creator was awesome enough to do the full source with it). Kept a copy of it just in case planet rendering ever came up. But yeah, definitely a lot of work to get something so big to render. Having ANY examples should help at least better hash things out though.

Alright, fixed a few more issues that cropped up(somehow forgot to copy the splash image?!?!?!) and almost have the FPS gameplay module locked in. Gotta make sure the gameplay mode properly initializes and it should be good. Should be all prepped and gold tomorrow for that part.

Hey Jack, as promised in irc, I dug up that old solar system sim engine I had a copy of. The code is oooooold, but it could give you some ideas on how to tackle things. You'd have to modernize the render code, but the basics for setup should carry across: http://ghc-games.com/public/iue.zip

The reason that occurs is because T3D doesn't currently have a static batching solution for separate objects. Nils brings up a good point about adjusting the instancing limit(any mesh under that size will try and use instancing to reduce API overhead, which is good for lots of simple shapes). Otherwise, when you have 46000 spheres, you're going to be seeing a lot of draw calls. The render bins render them by material groups, which reduces state switches to the graphics card, but you're still going to be seeing a ton of API calls which will hit performance. A similar subject came up last week, so I started doing a bit of R&D into an automagic static batch render bin, but that's not there yet. Once it does anything, I'll toss it up on github for sure though. Part of it boils down to "do you need your objects to move"? If they have to move, it gets a lot trickier, because you can't assume each object in a batch is going to move the same way, so you have to look into different means. The easiest setup is that the objects never move. These can be tossed into large static batches and handled in a few draw calls at once, and you get maximum performance. If the objects move, but are attached together, like, say, parts of a vehicle or the like, you could rig up a scheme to have each group of objects fold into a static buffer and be drawn that way. If the objects move and could potentially all be individual and dynamic, such as in Kerbal when a rocket explodes and all the components go flying, that gets tricky if you want to just flat draw all the pieces moving around. So the best approach for how to optimize would depend on how you need your objects to behave.

http://ghc-games.com/public/bodyisready.gif Seriously though, that is incredibly cool. Speaking of the anniversary, had you seen the Smithsonian was doing a restoration on the original model? Fancy Star Trek times for all!

Hm, haven't tried the precompiled on Win 10, but I can test it out and get back with you.

I'd say go ahead and PR it if you think it's a worthy change/improvement. As Timmy said, any improvement is welcome :)

Alright, that's fixed and I also corrected a few more linux compat notices.

Did some testing on that here. Does indeed add the bloom back in, but it looks like the bloom is on even at night time in the Outpost level. Probably an artifact of how specularity is calculated on the water than anything else though. Otherwise, seems like a solid fix. Anyone else noting any other problems? Because if not, this'll probably get rolled in in the next couple days if no one elses spots any issues.

Sad to hear, but hey, you do you. You'd best still stick around and hang out though >: ( Also the heck do they mean by "lack of commercial plugins"? Are they asking after something in particular? Or are they just pointing at some vague metric?

Ah, yeah. That's happening when SDL isn't active for the project. That class only really exists for SDL, so the editor code that initializes it is trying to activate a non-existant class. Pretty sure there's an easy way to check for that so that'll be an easy fix.

Alright guys, https://github.com/Areloch/Torque3D/tree/BaseGameTemplate I *think* I got the remaining issues squashed and this cleaned up. So everyone give this a pull and a test. If there are no remaining major problems, this can get PR'd in. BaseGame template now replaces the Empty template, and is the default template selected in cmake. Once a FPS gameplay module is finished, the Full template will be removed. In the Templates/Modules folder, there's a BlankGame module. If you drop this in the data folder instead of the other modules that are part of the BaseGame template, you'll get an ultra barebones game setup. It's enough to spawn a level and connect to it with a local instance and nothing else. As mentioned above, I'm working at an FPS gameplay module to replicate the contents of the Full template, which will also be placed into the Templates/Modules directory, as well as modules for the pacific art content and whatnot for ease of dropping in and going. So yeah, give it all a whirl, lets make sure there aren't any real problems remaining and we can get this rolled in.

Yeah, if you feel you have a useful addition or fix, feel free to toss it up onto github. Bit easier to test/review it that way, but also feel free to make a thread bringing attention to it :) I'll have to give this fix a go. I don't REMEMBER having problems with callOnChildren, but then, I haven't used it a ton.

Alright, sorry for the delay on this(had to get my car fixed which took my afternoons for a bit). Looks like we'll be going forward on the modular-based layout, so I'll spend the next few days wrapping that up and get her rolled in.

@razvanab Az means that in the Deferred_Complete_3.8 branch that we'll be testing to make sure the Deferred stuff is ready, he's merged in those OpenGL fixes that Lopuska made. Once this branch has been sufficiently tested though, yes, it will be PR'd and rolled into the main repository. So, if you'd like to see that happen sooner, feel free to grab it and do some testing :)

Yep.

Side note: this includes the color linearization stuff as well, so testing this tests that too.

The deferred shading work is actually already merged into Az's deferred shading changes, so testing that also tests this. For reference: http://forums.torque3d.org/viewtopic.php?f=40&t=533

Github branch: https://github.com/Azaezel/Torque3D/tree/Deferred_Complete_3.8 This implements the full deferred shading pipeline. As there's a few things that need fixing with the DX11 branch that Timmy's still looking into, for the moment we'll push forward on giving the Deferred work a test-over so it can be rolled in first. As far as I or Az are aware of, it's all functional, so it should just be a matter of pulling the changes into a build(preferrable a game build!) and testing everything to make sure it all behaves as one expects.

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.