JeffR

Hey, that's pretty slick-looking.

Quick question: do the banners have any kind of animation to them? Like, bones, or vertex color for wind simulation?

Mango's probably gunna have the best idea of what's required to get it up to speed, as he was the one spearheading the occulus work before.

I think he'd made a mention of looking at updating it once DX11 is rolled out, but I don't remember if that was a plan, or just musings. Either way, at minimum he'd be the best bet for posting a few pointers on what parts would need touching up to get it to hook with DX11.

Got the FPSGameplay module pushed up on the basegametemplate branch last night, forgot to comment here, heh.

Few issues I'm already aware of, but I think it's most all of the way there not. FPSGameplay module is the default included with the basegame template, can remove that and dump in the SpectatorGameplay module for the empty-template style setup, or for a true barebones, strip everything out except the shaders folder and drup in the BlankGame module.

Issues I'm aware of: the generated textures for terrain are hardcoded to art/terrains/, so I'll have to remove the hardcode on that. Also note that the default postfx settings seem to be a little weird with the HDR/Bloom on the blank terrain map. Outpost, with it's own postfx preset works fine though.

Beyond that, I believe the FPS gameplay is functional. Giver 'er a whirl and lemme know if you spot any other issues with it.

Alright, had my friend grab the binaries and run the full template on his Win10 machine. He loaded up outpost and didn't note any issues.

Does it at least generate a log file when it fails to launch?

Alright, fixed a few more general issues, and got the initial chunk for the FPS Gameplay module up there. Not 100% but it spawns the player via the DeathMatchGame game mode as per the level info setting, and it loads off a module-independent level list now, mirroring the datablock list.

Still need to wrap bugfixes on the fps module, namely the inventory isn't intiailized yet and the like, but it's almost done.

It's trickier than flatly rendering each object, but not excessively so.

I have an example of cramming geometry data into as few buffers as possible for rendering here:

https://github.com/Areloch/Torque3D/blob/BrushEditorToolTesting/Engine/source/T3D/BrushObject.cpp#L656-L725

That loads an arbitrary number of brush objects from a file sorts them by material and then stuffs them into buffer sets(vertex and prim buffers). If it'd overrun the max buffer size, it splits off a new one.

You may not use this exact approach, but you'd probably have something in the same ballpark.

You'd have an object to act as your 'master', which would act as the rendering object in this case. So in the kerbal example, you'd have a 'space ship' object class, and then when you add a part, you'd submit the part's geometry to the spaceShip class. It regenerates it's buffers by running through the list of parts, sorting by like materials and packing everything into as few buffers as possible. Then at render time, you just run through the list of buffers and push the render instances.

That'd be the high-level idea, anyways. There's a few ways to approach this, of course, but that approach should be simple enough to try and start with and you can refine it/make it more robust as you go.

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.