JeffR

Yes that's an option. DM has several props with lower LOD materials; mostly with only the diffuse map and stripped all of the rest. The problem with that though is that the shadow side of the object will appear much brighter (with dark ambient settings) and switching from the higher LOD to a lower one can be painfully visible. Often I found that a high res imposter will do the job better in the optimization in T3D. Shadows for imposters can be set off, though it's either on or off for the whole scene ($pref::imposter::canShadow), having it per imposter material could be a good feature for the artist.

(The quality of the auto generated imposters need desperately improvement though, but that's another discussion).

Good point on the impostors. Also yes, the impostor generation needs to get fixed up. It's definitely not as good as it should be.

'Shadow Proxies' sound like a good feature to have; I totally agree. Perhaps even make it possible to use the collision shapes for that as well; which could do for particular props.

Hm, not a bad idea.

In large scenes, most objects like foliage and rocks etc. will be either brought into the scene via the forest tool or with groundcover (or procedural). It's already possible to turn on/off the shadows per groundcover object; perhaps it's an idea to do this for forest objects as well, giving the artist more control there.

Yeah, that'd be a good idea. Have it act as an override to whatever settings are on the forest item's material.

With dynamic lighting and time-of-day you'd want to have the shadows drawn by the terrain to be rendered much further then 200m. T3D doesn't have the possibility to handle those separately, sadly enough, so solely depending on normals :|

It's not as bad as you'd think, but yeah, having them go further is always a good thing if possible.

That said, doesn't the PSSM settings have an option for 'last split terrain only'? Or does that not work when you try it?

Yeah, that's definitely another optimization. Another is having a duplicate material on a lower LOD that just has the 'casts shadows' flipped off and the like.

One thing that came up we'll be looking at implementing is 'Shadow Proxies', ie, the option to define a submesh or submeshes as being used specifically to render shadows. So artists could author a model that has the same basic silhouette as the visual mesh, but far lower poly density(as unless you're right up on it, the shadows'll generally only need to be "good enough") which saves a lot of horsepower in the shadow pass.

As for shadow draw distance, I need to do more profiling with more titles, but the 200-ish seems to be pretty standard. That said, there are fewer 'lets make the GPU melt' PC-focused games these days, so there's a lot of compromising with consoles, but that number seems fairly consistent. I need to pull up games like Witcher 3 or some others for a good feel on how far out they draw shadows. Maybe the recent Far Crys would be another good sample-set...

Did a quick google search on MGS5 for an image with PC, and it seems like they selectively drop out lower profile meshes from shadowing(like the rocks) before buildings, but even about where you hit the main block of buildings in the town, it doesn't look like they're rendering shadows anymore:

Hmmmm.....

Yeah, you definitely don't want shadow pop-in for sure. That said, I'd been trying out several AAA games, and the shadows don't seem to usually be rendered further out than roughly 200m.

With the fadeStartDistance in there, you can control when the shadows begin to fade out to avoid any visual popping, too.

I'd say try cutting the shadow distance to about 200, and have the fadeStartDistance at about 150(so it gives an entire 50m for it to smoothly fade out, which should make it subtle enough that unless you're specifically looking for it, you won't notice).

Cutting back on the distance should give 2 boons: better performance because you're hitting fewer objects to be rendered in the shadowmap, and tighten up the space that each slice is applied to, which should help with resolution and edge jitter.

I'll have to take Andrewmac's vsm attempt and toss it in there too and see what happens. That worked pretty nicely in a broad sense, but had some blocky artifacting. I think getting PCF on there would smooth all that out and improve the shadows as a whole.

 

PCF and variance methods (VSM, ESM, EVSM) are not really compatible. PCF uses depth and VSMs store depth moments which you then use Chebychev's Inequality on to determine the probability of it being in shadow or not. Because of the "shadowed or not shadowed" nature of it you get hard falloff, or blocky artifacts as you put it. VSMs, however, have the advantage of being able to be prefiltered with a blur pass. You can't do with a regular depth shadowmap because when you blur a regular shadowmap you blend depth values into areas where there wasn't depth values and thus create non-existant surfaces. So yeah, if you want VSMs to be usable you just need to spend a day on improving the blur pass. Which should be very simple, its just a blur pass.

Regarding the linked code, its PCF 3x3, which is pretty good but can be better without being more expensive (which is a rare occurrence in graphics programming). If you spend a little time getting shadow samplers working in T3D you can do optimized PCF 5x5 which gives the same quality as 5x5 but with as many samples as 3x3. It's what Torque 6 and Unity are currently using. Here's an article on it if you're interested: http://www.ludicon.com/castano/blog/articles/shadow-mapping-summary-part-1/ It's the best quality to performance ratio I found of any of the shadowmap techniques.

Dang, I was afraid they wouldn't be compatible. Ah well.

And yeah, Az and Timmy poked and prodded on some of the sampler stuff and got hardware PCF functional, which is nice. Have to get that rolled in if everything checks out on it.

I can still remember back in the day when PCF just started being a thing and everyone was all 'oh man it looks so nice but ahrgrgaghgrgrhgh my frames!' haha.

@Nils

Speaking of shadows, what distance do you have for the visible shadows? The stock settings for the stock maps put the distance out to 400 which, honestly, is pretty freaking far. Most AAA games I'd been checking for comparison seem to max the shadow distance out to around 200m. Dialing back the shadow distance yeilds a better utilization of the shadowmaps' resolution, and helps cut back on the jaggies. If you're pushing a really high distance, I'd suggest dialing it back to 150-200 with maybe 50 of fade distance and see how that does to help combat the remaining shadow edge issues.

Sorta reminds me of a bit brighter, less depressing STALKER :)

 

The STALKER series are a piece of art and a big inspiration, so that's a compliment 8-)

I just started replaying CoP, amusingly enough. Hearing that makes me excited :D

Also, nice to see it in motion with the video. Pretty much the only complaint I could level at it is the lod/foliage pop-in, but that's not exactly an uncommon issue, even in AAA-scope games.

Beyond that it all looks rather solid. Keep up the excellent work!

Not entirely @Duion, but there were some changes that reduced the flickering effect.

The resource on this page should already be an improvement: http://pastebin.com/LfqdCC0B

!!!

I decided to give this a whirl real fast:

Stock:

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

With the PCF filter:

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

That absolutely CRUSHES the ugly noise from the current method. You said Tom authored that? I need to ask about rolling that into stock.

I will note that I did tweak the shadowmap settings from what's stock in the default levels. They're, to be blunt, kinda insane. The shadows have 4 splits, reaching out to 400meters, meaning each 1024 map has to cover 100 meters of distance. It's no surprise that we see aggressive aliasing and peterpanning with that setup. I think I'll make a PR to dial back the shadows to a more 'normal' configuration like what I've got in my above test there that's closer to the distances we usually see shadows in play most games. That does a lot to deal with the aliasing and peter-panning, as said.

I'll have to take Andrewmac's vsm attempt and toss it in there too and see what happens. That worked pretty nicely in a broad sense, but had some blocky artifacting. I think getting PCF on there would smooth all that out and improve the shadows as a whole.

Anywho, rambling aside, thanks a bunch for bringing that bit to my attention :D

I lasted untill the small ones showed up, and then they finished me off, haha.

Still, pretty neat :)

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).

So it is like an auto replace operation? I'm already used to it, since if you use the full path name to the asset, often you will need to update it, if you move assets around, so you have to search the whole object and replace all the path names in the objects used then.

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.

What changes are there that would break the art pipeline? Only thing I know so far are the PBR textures, but this can be solved with a slider to adjust roughness and metalness for each texture, it is not as good as a roughness and metalness map, but it should work, right?

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 :)