JeffR

Wow, that's looking pretty rad, guys. Sorta reminds me of a bit brighter, less depressing STALKER :)

@rlranft That's pretty much *exactly* what I was looking at doing, yep. Though the plan was to have a tree view for easier module management as well. The R&D test pass ended out with something like this: http://ghc-games.com/public/AssetBrowserWIP.png Obviously not truely functional, but it proved the basic concept well enough. With it having the tree view of the modules and THEN broken down by asset type, it would make it easier to do the 'move an asset to a new module' by simply drag-n-dropping on the module it needs to move to, etc. It'd also have the search and tag filtration stuff like what you've got there(the eye button would bring a pop-up for filtration of types and tags).

If you move an asset into another module, then it's a chore, yeah. Assets are usually given IDs like so: %spriteObj.setImage("AssetModule:TheImageAssetName");So if you move the asset to another module you'll have to do a search/replace of that... yeah. Yeah, having to manually change assets like that is a pain. I'd already started some R&D into an asset browser/manager to help deal with that kind of stuff without having to touch on it manually. Simplifying the import and export process, as well as being able to move an asset into a different module and have the editor tool propagate that change will be huge timesavers.

PBR is the big one,yes. However, we're also looking at stuff like assets as opposed to direct paths to art files and the like, which would impact existing levels and datablocks. Been talking about how to make the import process for assets nice and easy, but it would still require some conversion work with existing projects.

Hey everyone! Figured I'd make a post on the status for 3.9, as we're getting pretty close at this point to RC'ing it and getting a release out there! Quite a bit of work's gone into 3.9 so far - Linear texture color, proper Deferred lighting and then DirectX 11 support, shorting up lots of parts of OpenGL and work to stabilize Linux, among a lot of other minor improvements and fixes! The tentative lock-in date to start testing the RC is the end of the month, with a few features to add in yet, such as fixing Linux's lack of file dialogs, and getting my Entity/Component work added into the engine behind a experimental flag(so people who are curious can begin playing with it, while not distrupting any existing work with the standard game classes) as well as a thourough run-through of any other bugs and improvements we can cram into it. So what's next after 3.9 is out? Excellent question, Bold-Text-Reader-Stand-in! From there, we begin to push towards 4.0. Yes, I know, these are version numbers, not decimals, and we could just as easily have 3.10 if we wanted ;). But the numerical roll-over reflects something we've been planning for version 4 for quite a long while now. With 4.0, we're going to be making big changes, and some of them are going to be breaking changes for existing projects if one doesn't update to match. The break in backwards compatibility in some areas - the art pipeline most specifically - means that it's a sort of line in the sand of 'If you don't really want to deal with porting these big changes, then 3.9 is safe, but after this there may be some large shifts'. An example of this is the overhaul of the base template I've been working towards to make it less hardcoded and easier to drop in content and packs. Another would be Dropping DirectX9 support. Yep, that's going the way of the dinosaur. It's important, because that frees up a LOT of options that DX11 and modern OpenGL provide, as well as being able to restructure some DX9-oriented parts of GFX to make it less....well, DX9-oriented. This would make it MUCH easier to begin looking towards DX12 and Vulkan, as well. Another huge one would be switching over to PBR-based rendering. This is another pretty hefty change to the art pipeline, because it impacts materials and rendering in quite a significant way. So all in all, 4.0 should end up being a pretty huge jump forward for T3D. It'll be bumpy for existing projects if they wanna jump up with it, but I'm fully invested to documenting and making whatever wiki pages or the like needed to make it as smooth a transition as possible. Just wanted to throw down some info-bits as we move in on the kill for 3.9, and give some light detailings for what to expect for 4.0. If you've got any particular inquiries, feel free to toss them in here :) Peace out, -Jeff

Yeah, I tend to get a bit envious of people that have such a solid grasp of the maths like that. They can put out some really elegant code. Keep us updated about how it goes, spherical terrain is always cool to see in action.

This just recently got posted in /r/gamedev and it looks super awesome: https://github.com/sp4cerat/Planet-LOD "This is a simple example of how to render a planet with spherical LOD in less than 100 lines of c++ code"

Very cool. I'll have to give this a whirl soon.

Got any particulars on the crash, like a console log? It shouldn't really CRASH on really old hardware, just, you know, run poorly.

Not sure what problem you're seeing deathbravo, but that page loads for me, though I grabbed the exporter by downloading the project from the github page, so if the page still isn't loading for you, you can try that. And yeah, I recently gave this a real look and it works perfectly. Good find!

DX11 got merged last night, but otherwise Az is correct. Deferred/Linearization saw some changes to the shaders, and a few more changes for DX11, and then the soon-to-be-merged new base template will see a few more changes. The new template should be nothing especially drastic from the shaders side(more or less just removes the hardcoded "shaders/common/" pathing in place of a global var to indicate where the shaders are stored.

@TorqueFan By all means, if you've got code you think would be worth getting into the engine, toss a PR up for it :D Contributions are ALWAYS appreciated.

Hm, not sure I'm following, unfortunately :) Do you have an example of that this would do in practice? As in, what the end result would be?

Probably worth tracking this down as a hotfix for people utilizing the empty template(crashes are bad). Will note though that the new BaseTemplate will soon be rolled in(final testing at this point for any flaws) to replace it, so if it's not a major pressure thing you could wait on that.

Skipper: Nice find. I've been aware of the steps for photo sampling grass and stuff before, but it's never been as one single, solid tutorial. Good find.

Hey guys, It's not quite ready yet, but I wanted to put a heads up out there for anyone using blender and having problems getting your animations to bake/export right when using IK controls(such as with my Red Guy rig), I'm writing an exporter script specifically for exporting collada animations. https://github.com/Areloch/Blender_Collada_Anim_Export Again, not ready yet, but I figured I'd notate it here. What this'll do is when you go to export a selected armature with it, you'll pick one of 3 export modes: 1) Current Action Only, where it exports only the currently set action on the armature to it's own file 2) All Actions, Single File, where it exports all the actions on the current armature, but appends them all into a single file 3) All Actions, Separate Files, where it exports all th actions on the current armature, but each action gets it's own file What it'll do is it creates a new temp action on the armature, and copies the action(s) into it. Then it runs through each frame of the temp animation and does a visual keyframe of position, rotation and scale. This uses the world transforms as opposed to local offsets, so it accounts for bone constraints like IK and the sort. Then, with the visual transforms of each frame baked, it exports the collada as normal. After that it clears out the temp action which will be cleared when you close blender. This'll let you use IK controllers and other bone constraints and be able to just simply click to export, rather than needing a bunch of additional steps to get it out there. It should be rig-agnostic, though I'm testing it with the Red Guy rig I created. If you've got any ideas or suggestions, feel free to toss them in here, I'll be keeping updates on this as I go. It won't be blisteringly fast progress as I mostly work on this during lunch at work, but I want this for my personal pipeline, so it'll get done at some point :P

Pretty similar. I used a good bit of it as a starting point(like the core folder), it just extends further to utilize the modules system to make it easier to drop in/out module packages and the like.

Nice, those menus look very clean. Did you re-write the settings backend, or are you piggybacking off stock and just using a different UI? As for the phone lines, dunno if this'll be helpful, but it may be useful at some point: http://humus.name/index.php?page=3D&ID=89

Lookin pretty sexy there. Only complaint I could really level at it is the aliasing issues on the phone lines and stuff. Beyond that, it's looking good :)

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.