JeffR

Kinda.

This part of a video from UDK shows it off a bit:

iAvupgMlvKE

One of the advantages this method offers is a single material, but nearly infinite variations in surface. This is especially useful in cases where you have a bunch of prefab parts to make buildings. Obviously if you just used the same peices with the same textures, it becomes really repetitive, but having a bunch of different textures uses more memory and adds draw calls. So you could go in there and using one material, paint grime in various spots, breaking up the repetition without tons of additional memory use and draw calls.

The thing that separates it from a simple texture overlay is you can use the normal maps as a contributor, so as the video shows, is when he paints the sand/water, it accumulates in between and at the edges of the tiles first, which is more realistic, and then the flat surface areas. You can also mix and match a few different materials, or have it offset the verts in the very shader to have sand accumulation actually raise off the surface for more depth, etc.

It's a pretty flexible technique.

It's similar to how the terrain texture blending works. In fact, that's one of the most common ways to control which textures are where on the terrain - by changing the vertex color values - and is similar to what we do with our terrain.

For more specific examples, it allows you to do stuff like having, say, a brick floor material, and then additional texture maps/materials that blend in as needed like, say, water and snow.

So you'd have your brick floor on your ground, and then by painting vertex color values, can dictate spots to have water and snow accumulation, letting you pick specific parts of the ground to have water puddles, or snow piles.

This can be extrapolated to practically anything. Stone wall with greenry growth or grime, cracks in concrete, etc. Because you select what parts of the surface have the various blends, it allows you to take a common material, and apply minor changes via the blends, adding lots of detail as needed and also helps combat the 'repeating texture' effect. All in all, a very powerful tool for artists to work with to make their scenes unique and interesting.

Haha, no worries!

You can either make a thread here on the forums, or you can make an issue on the github page, just noting it's a feature request so it's easier to organize.

You needn't worry about getting in trouble for suggestions :)

Good to hear!

Over the next day or two, I'm gunna go in-depth on the particulars of the assets, entity/component and game object stuffs in my workblog thread, so feel free to keep an eye out there for more details on how this will all get utilized :)

Sure!

https://github.com/Areloch/Torque3D/tree/BaseGameTemplate

That's the current build of it. It's a bit behind to devhead, but i plan on updating it soon. It has a module that contains all the current Full template's fps/gameplay stuff, so if you started working on something now, you could port it over to that module without a huge amount of hassle.

If you wanted to look at how the assets and entity/component stuff works, you can nab my R&D branch https://github.com/areloch/Torque3d/tree/RnDBuild

Where I do all the testing and building for the modules/assets/entity-component and all that jazz. If it's in my workblog posts, it's in the RnD branch.

I do plan to put together documentation explaining how you can port to 4.0(while existing game classes like ShapeBase, Player, Item, etc will be deprecated, there will be entity/component versions that come with 4.0 that do the same thing, so you don't need to start from scratch or anything, merely port over).

Let me know if you had any specific questions :)

Hey man, no worries!

3.10 is largely fixing bugs and some quality of life improvements, but we also wormed some new features in. It's not exhaustive a list(that'll come with the changelog for the release) but here's some highlights for 3.10:

• Added MacOS support
  
• Updated some of the libraries, like bullet, vorbis, png, and recast
  
• Various fixes to D3D11 and OpenGL, which help stability and performance
  
• Ipv6 support
  
• OpenAL-Soft audio support(better than the old OpenAL)
  
• Replaced OpenGl's epoxy with GLAD, which is cleaner and simpler for building out the GL feature list.
  
• OpenVR support, which allows you to use the Vive
  
• Hardware Skinning support
  
• A bunch of fixes and tweaks to lighting stuffs to make it all play better with the linearized lighting

And as said, a crazy number of other fixes and tweaks aside from these(So far, we have 105 PRs merged in for 3.10, with a few that'll go in before release yet)

For 4.0, it'll be a pretty gigantic update and improvement in a lot of areas. I'd suggest poking through my workblog thread for some ideas on stuff I've been working on my side of it in line with it all. Important highlights are:

• Dropping D3D9, allowing us to modernize the GFX stuff for OpenGL and D3D11, which should help bring a lot of performance improvements and new features like compute shaders down the line
  
• Full switchover to a linear color system, specifically utilizing sRGB textures internally, which are a) better performing because the hardware does the dirty work, and b) all colors to be very consistent and correct across platforms and tools/workflow.
  
• PBR(Physically Based Rendering) for the primary material lighting model. This will allow materials to look much more realistic, and have far, far better integration with modern toolsets with less effort.
  
• Updates to HDR and tonemapping, which will perform better, look better, and behave a lot more consistently.
  
• Hardware PCF shadows, which will look nicer AND run faster
  
• A drastically slimmed down gBuffer, which will help the engine run better on older hardware
  
• A new base template that has all the cruft trimmed out, so it's easier to use, change and loads faster.
  
• The new template will also heavily utilize the new Module/Assets system, as well as make the Entity/Components system the standard for game classes. The huge monolith classes like Shapebase will be deprecated, and down the line removed. This will MASSIVELY help cut back on iteration and testing time, allowing people to focus on gamedev rather than fussing.
  
• Updating the stock Torque physics to hook through the Physics abstraction API, so game code is consistent regardless of if you use, Torque's physics, Bullet, or PhysX
  
• Drastic improvements and updates to the tools and editor suite, including visual editing of shaders, state machines, more benchmarking tools, etc.
  
• Shift all the platform code to utilize SDL, letting us get rid of a lot older, platform-specific code and make things a lot more consistent
  
• Big expansion on included starting examples, as well as better documentation and tutorials.
  
• Code cleanup, including making sure files are adhering to the coding guidlines, and removing a lot of unwanted cruft, excessive includes which drag down compile times, and not-errors-but-not-right code which can cause bugs and irregular behavior, which should help stability of the engine across the board.

I think that covers the major highlights of what the plan for 4.0 covers. I said earlier I'm working on a proper Roadmap/Master Thesis breakdown of the plan for 4.0, and thankfully while that list looks daunting, a huge amount of the above is either actually done, or rather far along already, just waiting for us to get 3.10 out the door so we can start merging stuff in.

Lemme know if you have any other questions ;)

Hah, that's really cool.

It's back up. They poked their host and got it re-established.

As for why they host, it's because they're pretty nice dudes that like us :P

RC2 is up: https://github.com/GarageGames/Torque3D/releases/tag/3.10rc2

Mac and Lin binaries will be in soon. 1 or 2 definite PRs that'll still go in for 3.10 official, but if we can spot any other oddball things to try and shore up, that'd be good! Keep up the excellent work on testing, guys :)

May be a server issue again. I pinged at the maxgaming guys to try and see what's up.

Worst case, we just set up a new host if the host they were using tanks on them.

Hey guys, hope everyone's holidays went well!

Got a few more PRs to test and merge, but the plan is to get RC2 put up tonight.

For the guys that noted a slight performance decrease from 3.9 to 3.10. We did some profiling and tracked it to the change in HDR format handling.

In 3.9, we had a thinner HDR buffer, RGB10A2, which has lower cost to fill out for the HDR postFX compared to the fatter RGBA16F buffer in use for 3.10 at the moment. The reason for the shift is that, with the linearized lighting introduced in 3.9, with HDR enabled you could get color banding, as the RGB10A2 texture didn't have the bit depth necessary for smooth colors in some lighting situations, specifically dark ones.

So for 3.10, in the interests of more accurate colors/reduction in banding, we upped to the fatter buffer texture. This unfortunately means that HDR has a slightly higher cost.

Post-3.10, we're dropping Dx9, and switching over to sRGB and a much leaner gbuffer(timmy's already got this all sorted, we just need to drop it in, basically), as well as some improvements to the HDR effect. All that together sees far, far more accurate color handling, with a performance increase as well.

For 3.10 though, if you're willing to deal with a bit of possible color banding in darker areas, you can roll back the fatter HDR buffer tweak and that should get the perfromance back to where 3.9 was by uncommenting this line:

https://github.com/GarageGames/Torque3D/blob/57dfeb829a40fb88c974d9370d70e8dcadeb650b/Engine/source/gfx/gfxDevice.cpp#L1324

That'll make the HDR format default to the RGB10A2, which as said above is lighter and thus costs less to utilize HDR, but at the expense of less accurate lighting and possible color banding.

@Duion for #1746, I have a PR pending I just need to make a tweak to tonight and will get rolled in. Plan is to get fixes for a few more issues that people ran into and have an RC2 pushed out this weekend.

Hey guys, try this and test 'er out. Seemed like it worked for me.

https://github.com/GarageGames/Torque3D/pull/1876.

Credit goes to @Lopuska from his PhysicsGMKRefactor work, and Az and Timmy for remembering about it ;)

For those asking,

But really, should the physics version really matter? I'd imagine the terrain system would be programmed to recognize when a part of its surface has been set to "empty", regardless.

The setup passes through the physics abstraction layer on to the physics library in question. The issue was that the abstraction part didn't properly translate the holes in such a way for bullet to know about all that. the stock and physx stuff happened to. The above code change should make bullet properly aware of holes in the terrain, so give it a shot and let me know :)

...to go ahead and bump that up - or heck, could look at making it a pref...Let us know if bumping it up worked for you then :)

 

Yes bumping it from 70 to a Max of 90 Skinned Bones fixed the issue.

Making it a pref sounds nice but honestly just bumping it up will solve upcoming issues with ppl comin and asking why, cuz i dont think that ppl will cross the line of 90 Bones.

70 Bones is enough for a Player Character and for some of us it should be enough for the view models as well.

Anyways thx JeffR for pointing me to the right direction.

I figure we can do both. Bump up the default a bit, and also possibly make it a pref so it's easier to tweak as needed.

And yeah, thanks for helping test stuff! :)

Heh, yeah, fair enough.

It's obviously possible to push it higher, i think it was pretty much a memory/bandwidth consideration. 70 was figured as a relatively low, but acceptable number, I believe that's what Mango's team used as their max, which is why it's that number.

That said, fair point that it could be limiting from an artist perspective. Entirely a valid possibility to go ahead and bump that up - or heck, could look at making it a pref, so for games with less complex art, they can rein the number in and save on some memory and all that jazz.

Let us know if bumping it up worked for you then :)

Yeah, i getcha.

I think part of it is, that as knowledgable as all these really awesome people that do tutorials are, they're not actually teachers. So it can sometimes be easy to forget - especially when it's one-sided teaching happening - that skipping parts of the lesson, or assuming existing knowledge, can be a bit of a gamble.

Sometimes one you have to take to get on with the lesson, to be sure, but still a gamble. Ideally in those cases, there'd at least be a 'This part of the lesson assumes you have knowledge of X, Y and Z. If you aren't familiar with these, please go to A, B or C to brush up on them before continuing'.

I know a number of tutorials adopt that method, and I feel it's a decent compromise.

You sexy beast! ;)

Very awesome. I need to give this a proper run-down.

So outside of obvious, improvements like cutting back on how much string interpretation we use and whatnot, what do you think is still missing at least an initial implementation?

It's sounding like it's pretty close to at least the 'everything runs' level.

prime emphasis on this release was fixing bugs

 

Sry but 3.10 broke 2 things for me and maybe even more....

I have used 3.9 for my current Project and wanted to check out the 3.10 RC and i made sure that i add all and evryrthing in order but for some odd reasons i get the following Issues.

#1 Damage gets applied to the player when spawning - if weapon is a Melee weapon.

#2 DAE and DTS(cached)models - Model Parts are not being rendered - this happens with FPS_View Models.

Now am sure i have encountered Issue #1 some releases ago but i know that that Issue isnt happening in 3.9

and about #2 am just :shock:

Would like to hear if other ppl experienced stuff like that

Hey, thanks for the spot on these!

T3D doesn't have any stock weapons that are melee, so I don't have anything on hand to test that side with it. How are you doing the melee checks? Raycast? Collision mesh?

For the second bit, hardware skinning was implemented to improve on the performance of animated meshes, it could be running aground on that. Could you try going into tsShape.cpp and, near the top find

bool TSShape::smUseHardwareSkinning = true;

And set that to false? That forces the animated meshes to run in 'software mode' like how it used to. Try doing that, and seeing if the mesh peices render again as usual. We though we'd hammered out any oddball spots with it, but obviously this is why we do testing ;)

Definitely shouldn't be seeing a drop in performance. It should at least be the same.

I'll run some in-depth benchmarking between the two versions tomorrow and we'll try to isolate what's going on with that.

Thanks for the detailed info!

Yeah, I see where you're coming from on that.

Heh, maybe some kind of tutorial setup that has the example code, and much like a footnote reference on a wiki page, have little footnote references next to stuff like arrays, local/global vars, etc that link to their relevent part of the tutorial, to help mitigate the 'wait, what's "%thing[0]" supposed to be?' effect.

Yeah, the sketch tool uses the normal of the surface clicked to orient the brush when creating it.

If you don't want that, currently, you can click the little cube icon in the top bar, and it'll make a 1m cube, 0 rotation. That would likely be useful.

For improvements, I could see a option/setting for conforming to the surface normal or not when creating new brushes.

Then why such low performance in an almost empty level? I mean, the desert level has nothing except a terrain, scattersky and advanced lighting. This just does not give me much confidence in how it might behave in a bigger level with more art, and probably also other stuff like AI going on. Don't get me wrong , I am not bashing T3D.

The idea is, effectively, that with Deferred Lighting(the older method), it had less up-front cost in rendering a scene, but didn't scale as well as more and more and more stuff was added into it.

For deferred shading, there's a higher up-front render cost to render a scene, but as more things are rendered in the scene, it scales better. Which is why a nearly empty level doesn't perfom as well compared to the older builds. However, as Timmy said, if compared, you should see better performance in a fully loaded level.

Try taking the pacific demo package and tossing it in there and seeing how it scales comparitively. http://ghc-games.com/SC/Pacific_Package.rar

Are there plans to make T3D support multicore processors better?

Yep, this is definitely the plan. I've already done some testing at threading the renderer itself, and we've also been looking at running a thread for the client and one for the server(as T3D always has both, even in singleplayer). This would effectively get us a thread for rendering, and then the server-side stuff, like physics and AI would be in a different one. This would help a ton with performance.

You can feel free to add me in skype, my email being Areloch at gmail dotcom.

I dunno if I've got time to do a full-on sitdown lesson, but I'm more than happy to answer questions and help get you sorted :)

In the interest of plotting out better documentation and tutorialstuffs in the future, what parts of video or written tutorials throw you off?

That'd be because getObjectMount() returns a sceneObject, which isn't necessarily a ShapeBase object.

You'll either want your initial ShapeBase* obj = this; to instead read SceneObject* obj = this;, so you can handle ANY scene object that may be mounted, or if you just assume the only things you'll be mounting are other ShapeBase objects, you can turn that last line into:

obj = dynamic_cast<ShapeBase*>(obj->getObjectMount());

Which will try casting obj to a ShapeBase. If one of the mounted objects isn't a shapebase or derived from it, that approach could cause problems/crashes though, so be wary.

Wow, that's a STARK improvement. Is your far plane the default value in both cases?

This may give some ideas on where the math is currently going oddball when we go in to fix 'er up.

If you notice any other details or settings that have an impact as you fiddle, by all means, lay it out here, it'll help a lot in narrowing things down.