andrewmac

metalness is universal. The divide is typically specular color or roughness/smoothness (same thing, just which ends of the spectrum 0.0 and 1.0 represent). we went smoothness to save 2 buffer slots.

Incorrect. You can't substitute specular color for roughness as roughness modifies the clarity of the reflection. Specular color can make an appearance in this workflow, but its used to modify the radiance (reflection). To save space many engines (Torque 6, UE4) substitute albedo modified by metalness as the specular color. Its a hack but its works for a large majority of materials and saves GBuffer space.

Now that we have dx11 is this going to happen ?

The only reason I made this is because the DX9 limitation prevented light propagation volumes from being efficiently implemented in realtime. If DX9 support is dropped and DX11 is the norm someone should rewrite the injection and propagation steps to use compute shaders and you'll have realtime light propagation volumes instead of baked.

Hm you are right, all those extensions are already in use, so either use .t3d or just leave it as it is.

As I said before TSC is an initialism, not an extension used by microsoft. If you check the page for the extension: http://filext.com/file-extension/TSC you will see its used by TINA pro, circuit simulator software. Low risk for collision among torque users. If you check the page for .t3d however: http://filext.com/file-extension/T3D its used by Swift 3D, Topaz 3D, and Unreal Engine. High risk for collision.

• MacOS support.
  
  This was originally slated for 3.9, if you look at the 3.8 release blog, but a lack of machines to test on, and the age-addled old platform code made it impractical to really tackle initially. The good news is, near the end of 3.9's development, with SDL and epoxy to take a LOT of the workload off, huge strides were made and it's actually almost completed. There's still some issues with rendering on some machines and catching errors and warnings that crop up, but it's looking very practical to have MacOS as an official platform for 4.0! You can see Timmy's screenshot in the 3.9 RC thread showing off T3D running on MacOS with his and JeffH's work now.
  
• SDL as the main platform layer.
  
  Torque3D's supported SDL for quite a while now, and it's naturally the main platform layer for Linux(and MacOS). However, it's been a little bit of a red-headed stepchild to the Win32 platform code. For 4.0, that's changing and SDL will be adopted as the core platform layer with whatever glue needed sitting atop it. This will drastically simplify the platform code and make it easier to maintain. It also offers a good bit of future proofing should any other platforms come into the equation down the line. SDL's stuff is very nearly at parity with the Windows side, it's pretty much just a matter of jumping over the last bits and doing cleanup/bugfixes to make it rock-solid.
  
• Graphics API refinements
  
  DirectX 9 has proven to be a monstrous workhorse of the graphical APIs, reliably serving well beyond what anyone though it would. However, while it has proven to be a rock-solid API, the time has come to retire the poor girl and send her off to the glue facto-eeeer, the farm. Yes. As such, DirectX 11 will be taking over as the main Dx rendering API, and will continue to see refinements to bring it up to speed now that Dx9 isn't hampering it or OpenGL. Timmy's been poking at this and has noted improved performance in Dx11 by quite a lot, and some gains in OpenGL as well.
  
• Hardware Skinning
  
  Another thing that's been pretty much complete outside a few oddball behaviors we'll be getting in there is Hardware Skinning. When it's behaving, the current implementation already notes a huge improvement in performance for animated meshes, so getting it polished up and in should be a huge, immediate performance boon.
  
• A new base template
  
  This is also basically complete. This will be a much more streamlined starting template intended to easily drop in modules, assets and the like into to build up your game project, as opposed to having to spend time stripping out the stuff you don't need. Numerous ancillary improvements also help load times, easier to read and comprehend code and the like. This will replace the empty and full templates, cutting down on the effort needed to maintain(no need to duplicate changes).
  
• Vive support
  
  This comes from our own Mango's efforts. It's pretty much done, but didn't quite squeak in for 3.9. It will be going into 4.0 for sure.

It seems to me like these features will take drastically less time to develop than the other listed features. They also don't break backwards compatibility. In my opinion these are useful features that I think justify a 3.10 release rather than holding them back until the rest of the features are finished.

and "tsc" is the typescript compiler :D

That usage is an initialism not a file extension. As a file extension .tsc is said to only be used by TINA: http://filext.com/file-extension/TSC which is a circuit simulator. Obscure enough that I think we're safe to use it.

I also agree with @Bloodknight that some people around here have a rather unrealistic negative view about T3D capabilities. That is not good for the future of the T3D MIT engine. People are allowed to have such negative views, but if such negative views are not met with common sense it will grow to become a disease that spread among our users. In the end it will destroy our forums, webchat(I believe that has already happened to some extent) and dry out our small user base.

There is also a group of users, yourself included, who have unrealistically positive view about T3D capabilities. It blinds you to what the rest of the gamedev community is doing and causes the engine to further fall behind. If it were up to you T3D would never drop D3D9 support and thus always limit itself in capabilities. If such fanboyism isn't met with common sense it will grow to become a disease that spread among our users.

Rather than discussing integrating Area Lights into T3D we're arguing about the video. So while T6, Unity, and UE4 (and likely all the other engines) are getting real time area light support, we're sitting here arguing about it because no one here can appreciate or evaluate anything that isn't Torque.

Anyway, I thought I could be the voice of reason but it looks like I'm the source of the problem at this point. I'm clearly in the minority and you would all rather be left to shit on anything that the other guys are doing. Lesson learned, if you don't have something pro-torque to say, don't say anything at all.

@Dwarf King: You and the others who originally responded to this literally ruined the discussion on the video. You can say whatever you want to justify that to yourself but you helped to derail what could have been an interesting and constructive discussion. You're contributing nothing positive and this is the third post where you've patronized my responses in an attempt to insult me. Great community we've got left here, really inviting.

Oh and the game play joke/needle stick came up as I am tired of all the nice graphic demos from all the commercial engines. Eye candy alone will never ensure a fun game or that using a tool is productive. You see some times it is not about how fancy or smart a tech you use. It is really more about the game play and the design of the game as such. Hence that is why a game such as TorchLight(made with Ogre3D) became a hit even though it is "only" a DX9 game. I hope that your CS classes informed you about that. Because they sure informed me abut GUI design and interactive design ;)

Sure, but this is a graphics demo. They described it as a graphics demo. Its described purpose is to showcase the state of graphics in Unity in 2016. If the video was about UI or gameplay elements and I criticized it on not showcasing graphics wouldn't that be dumb? So, could we try judging the video for what it is and not what you wish it would be? If you don't like videos about graphics, don't watch them, and don't comment on them.

The reason why all these commercial engines release videos about graphics and not about the other engine features is because engines have pretty much mastered those elements. GUI? Interactive Design? These things have been on lock for all the engines, T3D included, for like 10+ years. Why would anyone make a video about it? It won't get shared or get press coverage. The major recent advancements the engines are making are in performance, graphics, realistic rendering for the purpose of creating movies/short films/etc, and VR support which is tightly coupled to performance and graphics.

You don't have to be a graphics enthusiast, you don't have to like the video, but could you maybe not ruin it for the rest of us?

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.

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:

Adam is a short film created with the Unity game engine and rendered in real time. It’s built to showcase and test out the graphical quality achievable with Unity in 2016.

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

@andrewmac

They're releasing it soon so everyone can run it on their own machine.

 

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.

The thing about a movie is that it is rendered on somebody elses machine. A game runs on your own machine. Do they say what the spec was of the computer used? It could be something that most people could not justify for game play - but can be justified for advertising your game engine :?:

It was done at 1440p on a GeForce GTX980. They're releasing it soon so everyone can run it on their own machine. The video showcased a number of features combined to achieve a level of quality you would expect from something rendered offline. I don't think this is meant to be a game engine advertisement per-say. UE4 is sort of dominating the graphics category right now and has a booming arch viz and short film community (who are all switching over from offline renderers) so I think this is just Unitys response to that.

So.... where is the game play? :mrgreen: :mrgreen: :mrgreen: :mrgreen:

It's a self described short film. Why would a short film have gameplay? That would make it a short game.

The burgers on the display panel in the fastfood store also always look so much better than the actual product you buy.

This criticism would be valid if this was prerendered but its real time.

i'm not even sure what it is supposed to be highlighting.

High visual fidelity rendered in real time. Also its showcasing a new real time area lighting technique they developed and volumetric lighting implementation. You can read more about it here: https://eheitzresearch.wordpress.com/415-2/

Also, a lot of unity tech while very nice isnt actually real time, the environment for example will use baked in shadows and ambient occlusion, these two things alone make any environment look hugely better than any real time alternatives.

If you take a close look at the video you'll realize that the majority of the impressive parts couldn't have been baked. Was the static environment in the beginning baked from the one directional light? Probably, though it didn't have to be. All those moving pieces can't be baked, so all the wires and cords coming out of him, all his motions, etc were all rendered in real time and it came out looking great. Him + the environment is also being lit by real time area lighting that was developed specifically for this project. As he walks down the hall those are real time reflections. When he gets outside theres now like 50 of him moving around, blowing grass, the guys with the guns etc. The only parts that could be baked there are the static environment.

The point is that they achieved prerendered visual fidelity without having to prerender it. Having ~10% of the lighting baked for insignificant static objects doesn't take anything away from this video.

The rest is doable in any other game engine you can get the models into.

I mean.. sort of? You could add the area lighting and other effects used to pretty much any engine you have source access to, but I think its inaccurate to state you could literally drop the models into any engine right now and recreate it. Not unless you allowed it to be prerended.

Not trying to imply this could only ever be done in Unity or that Unity is the greatest engine ever or anything. Just saying the engine and the team that made the video both deserve some credit. It came out very well.

The form allows you to cast your vote more than once so I wrote a bash script to vote for the choice I like best and I effectively ruined the poll :D

edit: he fixed it :x :lol:

In Torque 6 I switched the extensions to .tsc for Torque Script and .tsh for Torque Shader. So, that's where my votes at. One way or another I strongly believe .cs needs to change as it conflicts with C#.

Actually it seems like what @flysouth is discussing, is exactly what @andrewmac implemented in Torque6! Since the code-bases are sort-of-similar, it might be possible to use some of the same code for plugins in Torque3D.

Yeah, was thinking that myself - but wasn't entirely sure. Maybe he'll chime in on it.

The theory could be reused but the actual code can't. The plugin system is obviously very specific to Torque 6, but yes, it functions pretty much exactly as its being described here.

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.

I'll be merging it into Torque 6 as soon as it's available. It should be an easy transition since Torque 6 isn't script heavy at the moment and hopefully it'll provide good test results for you. Looking forward to it!

In the image @Steve_Yorkshire posted top and bottom are 4 and 5. In the layout I posted and the image you showed, 2 and 3 are top and bottom.

This is the layout I'm used to which is what I used in Torque 6:

///                  +----------+
///                  |-z       2|
///                  | ^  +y    |
///                  | |        |
///                  | +---->+x |
///       +----------+----------+----------+----------+
///       |+y       1|+y       4|+y       0|+y       5|
///       | ^  -x    | ^  +z    | ^  +x    | ^  -z    |
///       | |        | |        | |        | |        |
///       | +---->+z | +---->+x | +---->-z | +---->-x |
///       +----------+----------+----------+----------+
///                  |+z       3|
///                  | ^  -y    |
///                  | |        |
///                  | +---->+x |
///                  +----------+

Other than switching Y for Z so that Z is up, it looks like they match. 2 and 3 should be top and bottom. Good good. The current setup in T3D is the one @Steve_Yorkshire posted? That's an odd layout.

Could you post at least one of the skyboxes you're trying to use? Are you piecing them together manually or do you have them already in DDS?

Yeah, ignore me, I only glanced at it and saw "height based blending".

Ignore me I misunderstood.

Ignore me I misunderstood.

Torque3D does its asset loading based on what's visible. You can fill the entire scene with lots of items but until they pass a scene scope query they won't actually be loaded to display. Once it is loaded to display though it doesn't need to be loaded again.

What you're likely seeing is a) the initial position of the camera is causing a number of items to be out of scope on initial load and b) the reflection off the water is causing more items to be scoped when you witness the reflection.

As you mentioned the problem gets worse with heavier scenes. The ideal solution would be threaded asset loading so there is no noticeable stall even if that would result in visible popping as assets finished loading its better than stalling the game in my opinion. A hack solution is to make the first few frames of the scene scope everything so all objects will be loaded, then go back to normal scene query afterwards.

I chased this problem for a little while back when I was using T3D and it's a pain. My problem was that players would spawn, turn the camera and get hit with a 2-3 second stall then the game plays fine after that.

Is there any AA technique that's close-ish to SMAA that definitely works on OpenGL?

I'm quite happy with DLAA. It's simple enough to implement, produces good quality and it's quite fast. That said, I never actually got SMAA working so my opinion is a little biased. Also never had the ability to do a side by side comparison for quality differences either so take the suggestion with a grain of salt :P