JeffR

The first thing, is I'd point out that ShapeBaseImage is primarily intended for use as mounted weapons. If you were trying to mount "real" objects, such that may have collisions or the like, you'd want to use a different class, such as ShapeBase, or the like. So for example, you have here: https://github.com/GarageGames/Torque3D/blob/7bba3ee2de610c2757bc70eba10db869bab72a85/Templates/Full/game/scripts/server/vehicle.cs#L98 Which mounts the player to the vehicle at a given node slot. For your traincars, you'd Shapebase or the like for your cars, and mount them like the above call. Then as needed set their mountPos and mountRot fields to tweak their position(assuming you don't have a special node to mount them to specifically). These are added to the parent's transform. This way, when your vehicle moves, they will move with it.

Some of those aren't really OpenGL, persay, but yeah, definitely need to be addressed. If you and anyone else running Linux have more details, like logs, or video/screenshots of stuff happening, then we can get all over that. It's hard to debug stuff we can't reproduce, after all :)

Were you just noting the outstanding issues list(which does need some pruning, now), or have you noticed some issues in particular when testing?

As well as: How'd you generate the project? Sounds like it didn't filter the files correctly, there.

Yep! I'll start working on some wiki pages/tutorial bits, but the first thing you need to do if you want to start playing with it is activate it in cmake and compile it in. You can do that by turning on the advanced flag TORQUE_EXPERIMENTAL_EC, generating and rebuilding. That'll build the engine stuffs with it included, and if you run the install project, it'll install the associated files/tool bits for the full template as well. From there, when you go into a level, you can find the Entity class type to spawn it under the Level folder in the creator. If you select an entity, there'll be a drop-down that lists available components that can be added to the entity. Any components on the entity will be show up in a special sub-item in the Scene heirarchy tree called 'Components'. In there you can select the components, modify their properties, etc. You can also save a Entity to be a 'game object', which is pretty much a prefab with an associated script, by right-clicking on an entity in the scene view and clicking the associated command. Any Game Objects will show up in the GameObjects folder in the scripted tab in the creator. This way, you can build up, say, a player object(the included example GameObject is an example of how a player object for a third person game may be configured), save it as a Game Object with a unique name, and readily spawn it via the editor, or the console command spawnGameObject(%gameObjectName, %addToMissionGroup); Once it's been created via the editor, it'll have a script generated alongside it you can add code to affect the game object as a whole, or modify/create new components for particular behavior. As for the DX/GL, az answered that one above.

Stuff like this is always nifty. I'm looking forward to progress on this :D

Hey everyone! After a bit of a delay off the original estimate(due to trying to squash some bugs that kept on cropped up that we wanted fixed), the release candidate is finally here! You can grab it from the github page for it, here. Source code, Windows and Linux binaries for the release are there. Several new things are in play, like the proper deferred renderer, DX11 support, the experimental Entity/Component stuff, proper file dialogs on Linux and a multitude of other fixes, improvements and additions. The release candidate cycle will probably run until the end of the month so we can make sure to really hammer in any bugs that may have squeaked through the cracks unless everything goes really smoothly, and then the full release and a breakdown of plans for 4.0! In the meantime, we'll keep an eye out on any other bugs, and I'll wrap up the port of the old GG demos to go out with 3.9 on release.

If you've still got the code, I wouldn't at all mind having a gander at it. I've been mulling on getting baked lighting back into the fold for 4.0-ish, so anything that'd jumpstart on that would be incredibly useful.

Yeah, I think linux just has much stricter handling for 32/64 bits. I'd read somewhere you just have to have 2 builds and use the appropriate version based on which archetecture you're running. I'll look into it some to see if there's a sidestep. As for the SDL static and gtk stuff, can you test this? https://github.com/GarageGames/Torque3D/pull/1627 That statics SDL, and also hooks the file dialogue usage to TORQUE_PLAYER. If you flip on the TORQUE_PLAYER flag, which implies it's intended for end-user players and thus the tools won't be needed, it'll basically drop the file dialog stuff from the project, so that you don't need to install gtk to simply run the game if you're an end-user.

Looked into this, and the issue is that the Vehicle class doesn't actually hook into the physics plugins so they exist in the physics sim. As such objects that operate via the sim don't know it exists and can't collide with it. Fortunately, Timmy's got some code that registers a physics body for the vehicle which should remedy that, and I'll test plugging that in tomorrow/PRing it if it works.

Yeah, GTK is used for the native file dialogs in Linux to render them. For release projects, I'm adding it in so if you disable the TORQUE_TOOLS flag in cmake, it'll not include the file dialogs(since those are only used in the tools anyways) so that endusers don't need to make sure gtk is installed. For anyone wanting to use the tools with the file dialogs though, you need to have gtk installed on Linux. I thought I updated the wiki page, but I may not have. Anywho, getting the gtk package with 'pkg-config --cflags --libs gtk+-3.0' should get it installed for you. I'll make sure the docs are updated and get the tweak to cmake pushed tonight(as well as making static SDL the default :) )

Nah, you're fine, they can get used kinda interchangeably sometimes. Are you using any of the physics plugins(bullet/physics) or is it just the stock Torque physics?

When you say mounting, do you mean the player mounting to the vehicle so you can drive it? Or are you just trying to attach other objects onto it, like particle effects?

The biggest issue with morph targets is that lots of art pipelines don't support them at all anymore. Assimp doesn't support it, for example. Torque had some nominal support for them, but I haven't personally tried it myself. Most current games I've looked into for this sort of thing seem to have largely shifted to bones, with bone scaling and clever rigging to change the character shape. For example the Sims 3 and 4 do this. For a basic breakdown in how both approaches would work: For morph targets, you would create a series of shape keys, or separate models with the different adjustments you'd want(such as, say, the nose being bigger). You'd export these out and load them into the engine and basically store the vert positions as a separate type of animation rather than bones which stores the positions of the verts at their modified placement. When you'd go to blend on the shape key animation, you'd handle those separately from bone animations by having your 0-1 value dictate how blended between the 'unchanged' and 'totally changed' you want for that shape animation. You'd do that for each of the morph targets to get a final blended position. I think the main reason this has phased out is with the shift to instanced meshes. Instancing require the verts to be in the same position, so in order to morph targets on TOP of hardware skinning the bone transforms, means you'd not only be passing up the transforms for all the bones to affect the model, but you'd also have to pass along vert permutation info. You can potentially chew up a good bit of bandwidth hocking all that data around and it also complicates the shaders some. Not impossible, but less than ideal, which again may be why it's less common now. The other approach, which seems to be the main way these days, is using bone positions and scaling. This method doesn't require any special pipeline handling, and doesn't change anything about the rendering/shaders in regards to instancing/hardware skinning, which is most likely why it's favored. The basic idea with this is that you would, when rigging your character as normal, add in additional bones that are children of your regular rig bones. Various parts of the model are skinned to those bones, so they animate normally, but when you adjust their position, or their scale, it influences the look of the geometry of the model. For example, you could have a bone in the nose, and if you move it up or down via a simple offset value(or a blended animation), this moves the nose up and down on the face. If you scale the bone, the nose gets bigger or smaller, etc. I don't know at a glance what Mixamo Fuse uses, since they don't need to do optimizations for realtime rendering while editing the character, it's possible they went with morphs, but if they did end up using the bones approach, you can see if those bones are exported along with the model. If they are, you should be able to fairly readily utilize them to have similar customization. If you're rolling your own character from scratch, you'd naturally need to add those bones yourself. Once the bones exist and are rigged to the mesh though, adjusting them via blended anims or code is fairly straightforward.

Yep, the plan is for them to go out when 3.9 is fully released. We're wrapping up any issues that really annoy us and then 3.9 will be put up as a Release Candidate, and I plan to take that time to put a wrap on the demos. That said, the pacific demo content has been out for a while now, and can be grabbed off the wiki, here: http://wiki.torque3d.org/main:downloads :)

I would also note that while @rlranft is right that any changes the source code will necessitate SOME kind of recompile, you can also download the precompiled binaries from the last major release via the wiki, here: http://wiki.torque3d.org/main:downloads#toc4 That'll have the exe already and you can using the scripts and gui/world editors to work on stuf/test stuff out before needing to worry about diving into the source code. Given that the internationalization stuff seems to mostly operate out of the script/gui editor side, the precompiled binaries should be sufficient to at least test things out.

Wow, he does NOT look happy.

Oh man, this thing is incredible. Thank you so much for the find.

Paul: Are you able to compile the current devhead without any unresolved externals? Not sure if you're running into DX11, or the VR stuff. May help to take a step back and affirm that devhead compiles and runs well, then we can see about walking through the merge of the WIP VR branch. And as mango said, if you can get a copy of the errors/unresolved externals, that'd be a major help.

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. Hm, not a bad idea. Yeah, that'd be a good idea. Have it act as an override to whatever settings are on the forest item's material. 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.

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.

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