JeffR

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

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.

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.

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

Are the settings maxed out? Also, what graphics API are you using? D3D9?

Hey Guys! Was hoping to get this out the first week of December, but when ya find bugs, you wanna fix bugs. So here it is, the RC for 3.10 (Updated to point to RC2)! The prime emphasis on this release was fixing bugs and shoring up some stuff like some of the lighting maths, but we also squeaked in a few new additions as well. This like updating the Recast lib to latest, as well as the initial implementation of Ipv6 support and swapping the main audio device to OpenAL-soft, which is much better than the old OpenAL, OpenVR support for the Vive and freaking MacOS support! Tons of fixes went in, including getting collada exporting fixed up as well as some utlitiy functions to bake a bunch of static geometry like convex shapes or meshes, into a single mesh, which can help a lot on performance with complex scenes, lots of fixes and tweaks to lighting stuff, as some of it didn't play well with the new linearized math under certain conditions - especially dark maps. As the last time, RC testing will probably run until the end of the month-ish unless some crazy stuff pops up, and then we'll push onto 4.0. I'll have the Linux build uploaded tomorrow. I've been working on a 'master thesis' post about what's the target for 4.0 and what'll be going into it, what's already done and what's yet to do. Hopefully you guys'll like where things are headed, but untill then, test the crap out of 3.10 so we can make sure we've got a good, solid foundation for fording the rivers on the way to 4.0!

Hey ben, Can I get some screens of what it looks like when you lower the near plane? I hadn't tested that. The acne/artifacting for the cube shadows is definitely annoying and will get some TLC. The gaps you see in the parabloid shadows are 'working as intended' though. Not even being snarky. The way it calculates those is by mapping a sphere to two, or even 1 render target(which is the idea behind the 'single pass dual parabloid'. It's really fast, but due to the distortion of the render to make the hemispheres work, you get gapping at the seams. Those are great for fast lights, like gunfire, but definitely not as idea for permanent lights like lanterns or the like.

Haha, yeah. I'm doing up a GUI interface to select the benchmark path, that'll go in today, but otherwise yeah, feel free to hammer the crap out of it and suggest things the benchmarker should record. It's perfectly extensible.

If you're only trying to set the position of the gui control, you should be able to just call setPosition(mPtScreen); if you poke through gui/core/guiControl.h, that's the header of the root gui object class, and that sucker has a ton of useful utility functions for doing basic stuff like this. Lemme know if that doesn't work, but that should do what you need.

Oh wow, sure enough, there's at least the rain one floating around. Yeah, that was the old format to get you stuff like animated rain splashes or droplets. It's deprecated, so we don't really want those floating around. Nice catch!