JeffR

Ooh, tried it again, and got it to happen this time. I had put it to fullscreen, 1900x1080 on the resolution with steam running in the background(apparently it wasn't before). Right, so I'll keep iterating on this, see if I can narrow it down.

K, grabbed the latest drivers, went through the same steps, and was able to walk around the town, no hangups no problems, I did skip the tutorial, if we think that'd matter. So I don't think its the driver, at least. From here, we'd wanna try and narrow things down, such as a particular set of replication steps, so lemme know if you think I missed anything in my little routine above, or if you know of any particular things your users tried and I'll iterate through them.

'Aight, fired up the final version, bumped up every setting except vertical sync to max, started a new game, created a character, talked to the inn kepper, slept for the night and then was able to go outside and walk around the town, didn't note any issues. The machine's a R9 200-series, drivers currently at 14.501.1003.0, so it's behind. But so far everything looks alright. I'll try updating the drivers and have another go of it and see if it crops up.

'Aight, cool

Thanks, I'll get 'er set up tonight and check if I can replicate it at all. Another quick question, do you just use Dx? Or do you support OGL as well? And if you do, any idea if it's behaving the same way for your users?

Either should let me confirm the issue, but if you have a development build that'd let me use a debugger.

Hmm, do note that the 16.3.x drivers are mentioned several times, but that is a wide spread of cards. I have access to an AMD machine, is there any chance you have a test build you could email me so I can try it on my end and see if I spot anything when I run it?

Sounds like a tricky issue, but I'd be glad to help out! Since you mention lighting-related, just to clarify, are the users able to get to the main menu and stuff even with advanced lighting on and set to high? Also, any chance you can list some of the cards you're seeing this on? Or is it a total random smorgasboard of radeon/AMD cards?

What @LukasPJ said. There's no need for this to be an Us vs Them debate. We can easily point at a thing and go 'Hey that's neato' without it becoming some big deal. @andrewmac You mentioned 'rather than discussing area lights', but I don't think anyone's linked that paper TO discuss it. I believe that's part of the problem, here. There's not much discussion to be had as-is. The video looks nice, but there's not much to critique, and no one had posted stuff relating to the techniques used in it's production such as that area light paper, so currently there's almost no discussion to be had. Edit: Right, thread was locked, so no one'll be able to post the whitepaper link, haha. Will say that, in the future, I think threads like these would be better served if someone offers discussion points or tech speculation. There's only so much that can be said about how generally neat a video is. So to thread starters and posters in general, a good attitude to approach from is "How did they do X", or "Are there any papers/videos/code for doing Y", and "What would be needed to replicate this look". These are good for discussion, and get to the heart of what we all ACTUALLY want to discuss, rather than sitting around cooing over a video. Leave that to the youtube comments section :P

As Az said, the structure with PBR isn't COMPLETELY different, you won't have to remake your UVs or anything crazy like that. With PBR, you need the following data in textures: Surface color(Albedo) Surface normals Metal-ness Roughness/Smoothness Ambient Occlusion(i believe this is technically optional, but helps a lot in ensuring the nooks and crannies on a surface are shaded right). While you can pass in the Metal, Rough and AO in as separate grayscale images, because Az rigged up a compositor function, it's going to be easier to work with if you combine all 3 into a single image and just tell the PBR mat to use that. Again, as Az said, Red channel is smoothness, Green is AO and Blue is metal. Once you have that set up, you just need a cubemap. Level-wide will work, though we're trying to wrap up an IBL(Image-based lighting)-style system that uses area probes to provide regional ambient lighting info. You'd place a probe in the map, scale it's area of influence(if the pixels all inside it, it's cubemap is supplied for the PBR calculations) and then you'd either manually set a cubemap, or let it bake one from the probe's point of view. Idea then being that you sprinkle them around your level so that the lighting on objects is properly consistent to their surroundings. For making the various maps, and assembling the composite texture, we highly recommend you nab Allegorithmic's Substance tools which you can nab from here. Their Substance Live bundle has 3 tools that are super useful for cranking out PBR materials and they use a rent-to-own system where you pay $20 a month until you pay off the license, and then it's yours forever. So it's a pretty good deal for such good tools. If not, just putting them into the right channels via any image editing software will work fine as well. We'll also be fleshing out the process of making and converting images and materials over to PBR on the wiki to make all this easier to keep on top of :)

I had started a wiki page for stuff to test soas to be consistent and cover most all bases here: http://wiki.torque3d.org/testing:pre-release-checklist This would be a good starting point. Obviously it's not complete yet, but it gives a good list of stuff to check-over, and is applicable to all platforms.

But as I mentioned before this was not the intention of the video. It's not an advertisement for Unity's gaming capabilities. It's their answer to Unreal's Kite video and the other graphical demonstrations. This is a quote from the Unity website for Adam: People are faulting it for goals it never had. The real discussion here should be what new tech did they bring to the table that T3D doesn't have, and how could T3D be improved to reach that level of quality. Instead we've just got a bunch of people trying to explain why the video is bad. It's just.. sad :( Yeah, more of just a broad statement on my end that I'd prefer they put out gameplay demos instead of movies. For what it is, the Adam demo is very well done, just as the Kite demo is.

I wonder why they have not released it already. It would certainly give them a lot more advertising if they did. Could it be perhaps that not all is as it seems? :? I guess we will have to wait for that release and see lol I think it has more to do with upcoming SIGGRAPH 2016 than some kind of nefarious reasoning. Theres a huge computers graphics conference called SIGGRAPH at the end of the month and I bet they're holding off to release it as part of the presentation there. Eric Heitz and friends will be presenting the area light stuff, I imagine unity will have some kind of presentation that showcases Adam and follows it with the release. Of course this is all speculation. It's disappointing this community isn't more supportive of things going on outside of it. It seems anything that isn't pro-torque is immediately met with defensive responses, like its somehow an insult to Torque. It's a shame :( we're supposed to be computer scientists not fanboys. Hopefully they have more papers and stuff than the area light one they already pushed out. Would be kinda lame if they just re-hashed their presentation. On the demo, it, much like other movie demos unity and unreal have put out in the past are definitely pretty neat. Good demonstration of what some obscenely talented artists can do with the platforms. Not as great for showing 'this is what games could be like', because not needing to do physics, AI and other gameplay stuff frees up a lot of processing power to further funnel into graphics. Would be nice to see them funnel their art team to a small gameplay demo or something instead for a better game benchmark. Heh, reminds me with Square Enix's Luminous engine demonstration a few years back that looked incredible, and then people found out it was running on 3 or 4 titan x's to achieve realtime.

I'd be keen on mac support happening, and lots of stuff has had the tangental benefit of making that easier going forward, stuff like epoxy helps a lot for making sure systems with flakey or out of date drivers work(such as osx or some units distros), and SDL shaves off a lot of the work in dealing with the platform layer work. The big thing holding back mac being a minor drop-in effort is Apple putting very minimal effort into keeping osx working with modern OGL, which isn't something us full-in'ing on can change. We can work around odd osx behaviors, but we can't really fix them. That said, the last attempt that was made a few months back showed it's pretty close, I recall some odd graphical behavior and some platform oddities with SDL, but it did compile and run. As we continue to refine the OGL gfx layer, and switch over to SDL for the platform core, it should be much easier to double-back around and have a bit of slap-around on mac ;) Stuff like PBR - which is almost completed already and the entity/component work don't negatively impact osx other than it potentially coming about a bit slower, and stuff like e/c and PBR help a lot with standardizing art and gameplay paths, which do benefit the mac dudes too when we get that end working. Another limiter that is slowly being resolved is anyone with the code know-how having access to macs which almost no-one did in prior attempts. I've got access to one from my work, and a few other people are getting them for testing and all that jazz. That means that when we look at it again, there's a much higher number of eyes on it so testing and fixing can occur much faster. So yeah, I can promise you it'll be looked at and we'll make an effort to get mac support added proper - chances are better now than ever before - but I disagree that we need to stall on other fronts to get there, and quite a bit of work, if indirect, has already been pushed to making it workable going forward. :)

Yeah, development branch is the 'work in progress and could have issues', but we try to keep it pretty stable and not break stuff if at all possible, so having a fairly up to date development binary should be MOSTLY safe :P A minor bit of clarity of it being from the WIP development branch would be a good idea in general though, yeah just so no one confuses themselves.

Glad to hear! :D

I merged in some improvements to the mounting a week or two back, so if Johzx's binaries are up to date, it should include those improvements. You'll still see some jittery behavior if you have a chain of mounted objects, like a scope mounted onto a gun mounted onto a vehicle, and when the vehicle moves, the scope'll lag behind some, but the improvements helped with at least the first-step mounted objects to keep up better(and allow most classes to do it, even the TSStatics). So I'd say check with Johzx on if his precompiled binary is up-to-date and give it a whirl with the mounting improvements in there and lemme know if that helps.

Johxz is correct, shooting for this weekend, and if any snags pop up, it'd be next week. Really wanting to have it out for the weekend though. As for osx, we'd done some work into that a little while back, and while it worked, it was kinda in a weird place stability-wise. JeffH was looking at beating it all up and getting cocoa in there for a stable layer. He had been doing the work here: https://github.com/JeffProgrammer/Torque3D/tree/macosx_cocoa If you're able to help or help test, that'd definitely speed up that side of things. Part of the problem is not everyone has a mac to easily develop/test on, so if you can help on that front it'd be quite the boon. I'd suggest trying to hit him up if you can help.

It supports DX9 and 11. 11 support is solid, but not fully optimized(not taking advantage of command buffers and all that fun stuff). Once 3.9 is released(should be this weekend-ish), we'll be working at dropping DX9 and going full-in on optimizing DX11. Work is already being done on that front and DX11 has seen a good bit of performance gain over 9 already, so for 4.0 it should be solid.

Not sure about intercepting, but an example would be like, suppose you had a weapon with a bunch of mounted attachments that you want to do something when you reload(have little dodads move, etc) So each of those would have a "reload" animation. Then you'd use the smartPlayThread(%myGun,"reload",true); to tell the gun to play the reload animation, but it would also iterate over all the mounted objects and tell them to play their reload animations as well. This would let you have all your attachments do their little dodad animations upon the gun being reloaded, as per the example. Hopefully that explains the idea. If not, is there a particular scenario you're thinking of?

Just pushed RC2, which has various improvements and fixes. It can be nabbed here.

I've actually considered that very thing. Sounds like quite a few of you people want it as well. Guess that'll have to get put on the list for reals then :P It's a good middleground between the cheapness of billboards and the not-weird looking-ness of 3d meshes, so I'd say it's a good compromise.

Yeah, the entities are being intended to be very flexible, especially with the mounting. I'll have a look at the static shape mounting bit, it's not as flexible as it should be, but it definitely should at least keep up with the mount object. It sounds like the interpolation isn't handling it correctly as is, which means it's likely a bug. With 4.0, the general ethos is going to be more of a "You shouldn't have to use the source unless you're optimizing for performance, or crazy specialized stuff, but general gameplay shouldn't require source changes. Source is there to make things shiney and fancy, not to get the game running".

I'll have to chuck some buxx at it when I get home!

Andrew had started implementing assimp but had issues with getting the animation portion working a while back. I took a look at it myself because assimp support is on the docket for 4.0, and had integrated it into the ShapeAsset for loading. Got mesh loading fine and had been looking into the animation side(got it mostly figured out, but not 100% done). I'll get the code I had for that and toss it into a branch for you if you wanted to poke at it. If we get animation loading sorted, it's mostly done. The odd part comes from how the different formats store their bone transform tweens.