Work Blog - JeffR

301 posts Page 23 of 31
damik
Posts: 54
Joined: Thu Jun 23, 2016 12:02 pm
by damik » Fri Jun 22, 2018 11:19 am
very cool :D
Monkeychops
Posts: 25
Joined: Wed Feb 18, 2015 11:53 am
by Monkeychops » Sat Jun 23, 2018 10:13 am
Looking awesome!

Has there been any work on high DPI support? Would be nice if we had UI scaling and preferably ability for the engine to to render in say 1080p but scale it cleanly to a 4k monitor (relying on Windows to do the scaling leaves it blurry).
Duion
Posts: 1114
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Sat Jun 23, 2018 1:04 pm
Looking awesome!

Has there been any work on high DPI support? Would be nice if we had UI scaling and preferably ability for the engine to to render in say 1080p but scale it cleanly to a 4k monitor (relying on Windows to do the scaling leaves it blurry).
How is this supposed to work? If you scale a small image up, it will always become blurry, the only exceptions are losless vector graphics, which are not supported by the Torque UI system. The only way I see is to make your UI for a 4k resolution and then scale down, so it does not become blurry. Or do not use images at all and let the UI be generated in the engine, then it will never be blurry.
Monkeychops
Posts: 25
Joined: Wed Feb 18, 2015 11:53 am
by Monkeychops » Sat Jun 23, 2018 11:34 pm
@
User avatar
Duion
some more recent games allow you to specify a display scale so it keeps the monitor resolution at 4k native, so it doesn't switch the whole desktop and can go in windowed mode etc. but only renders say 1080p and then scales it up accurately using whole pixels. Sometimes you can also scale the UI such that the UI is rendered at 1080p and scaled up but the game itself runs at 4k res (or even vice-versa if you want a nice crisp UI rendered at 4k but you want the game to run at 1080p for performance).
JeffR
Steering Committee
Steering Committee
Posts: 863
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Jun 24, 2018 1:12 am
@ Monkeychops Yeah, hDPI has come up before, and the tricky part is UI scaling. Most specifically, text as we use bitmap-cached text for rendering. Adjusting the DPI displayed obviously influences the absolute values, so the math has to be reworked to accomodate for it.

We've been mulling on it, but haven't reached a satisfactory resolution(heh) yet. One thing that's come up that is really tempting is dropping bitmap-cached text and shifting over to signed distance field text, which would allow vector-like scaling of text without needing to actually treat everything as vectors. The engine actually has snippets of SDF code already(likely intended to ultimately use in the case I'm speaking) and there's other examples online, so that's probably best route for it even if we weren't figuring on an hDPI approach anyways. Smoother, cleaner text at scalable resolutions is always desireable.

For the last bit you'd mentioned, in prior posts I'd actually talked about dynamic resolution scaling for the rendered game world, but it only works with the game scene currently, not GUI elements of the like.
That said, another possible angle is dynamic scaling the backbuffer itself. Would need to experiment with that approach to see if that harms the clarity of text and stuff. It'd probably be fine for regular GUI controls, but when talking about DPI scaling, the most important thing is text clarity. If your text becomes blurry and hard to see, it's wasted, after all. :)
JeffR
Steering Committee
Steering Committee
Posts: 863
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Jun 24, 2018 1:51 am
Sorry guys, was expecting to get this up last night, but some shenanigans with extended family put that on hold. So without further ado, now for part two!

The Physics, Torque and the API
So, anyone that's dabbled in the physics handling of Torque knows that there's the 'Stock Physics' and then there's the Physics API. Most people understand it as stock physics are the default, integrated into lots of parts of the engine, used for basic stuff while the Physics API opens up being able to use Bullet or PhysX to do "real" physics.

The reality is slightly more complex than that in how integration and their behaviors work. While it's true that stock physics(henceforth known as Torque Physics) doesn't really well support thousands of rigidbodies all colliding with little performance impact, it makes up for it in the implementation of the physics being clear, accessable and modifiable, as well as playing a lot nicer with networking. The physical state of Torque Physics is simpler, which is bad for performance, but good for trying to make simulations line up client-to-client.

Bullet and PhysX, however obvious hold a large advantage when it comes to the simulation itself, especially in scale. Handling thousands of rigidbodies is totally a feasible option, but as covered prior, the particulars of the physics behavior isn't as readily modifiable, and also the way they implement their physics states makes some things more difficult(typemasking raycasts or collisions so only certain types interface is not particularly simple, for example) nor is networking as easy.

So there's been good reasons for keeping Torque Physics around. However, the E/C work has shown that maintaining the two ways of interfacing with physics - Torque's stock way and the PhysicsAPI - leads to a lot of extra, sorta-duplicated code, and it just makes everything bulkier. So as a solution, we've been looking at implementing Torque's physics into the API as well, so all access is much simpler, streamlined and consistent.

Image

This will come with a number of advantages beyond just simpler interfacing. It'll let us shift a lot of various, separated tidbits that fall under the umbrella of 'physics' into a single place(Anything dealing with collisions in Torque Physics for example is in completely different directories from the actual things that implement said physics/collisions). We can treat the Torque physics as a 'simulation' rather than a bunch of separated objects running their own things, which will let look at threading the Torque Physics, which will drastically improve it's performance. And it'll let us grab the few objects that only exist as Torque Physics handled, even when the other engines are in use, and establish code consistency with objects that implement the PhysicsAPI normally. Things like triggers and the like that interface with, but are implemented apart from the PhysicsAPI can be brought into the fold for consistency.

Then, when stuff implements physics, such as components in the E/C, you can have one common piece of code that touches the PhysicsAPI and it'll Just Work.

Motion Matching Animations and You
One thing I've never been super happy with, even if it generally works really reliably, is character animation. It functions, but the system implementing it is stuff, and if you want more flexible or dynamic behavior you run into a number of roadblocks with how animations blend with the current implementation. So i've been spending quite a bit of time researching new animation paradigms. From primarily procedural and physics driven, to other techniques that lead closer to traditional 'play animation clips', but expand the flexibility involved.

I ended up stumbling upon a GDC talk by Ubisoft developers where they discuss the creation of a new animation system called Motion Matching. I'll link to the videos about it below as they're very well worth a watch, but I've been looking into an initial pass implementing it as a way to allow highly responsive player controls but also with very detailed, characterized animations.

Quick introduction:


The full talk:


And a breakdown of the "Dance Cards" they talked about:


The basic idea is a simple one, and amusingly Torque has a system in place that's startlingly close to how it works already - the Player class's ActionAnimations.

If you've ever gone rooting through the player's animation system, you'll find the big list of Action Animations. This is basically a 'database' of sorts with an animation clip, and a movement vector associated to it.
During runtime, as the player moves around, each frame the update tick for the player object updates to 'pick' an action animation. In the Player class' case, this is as simple as getting the current movement vector, then looping through all the entries in our 'database' to find the closest fit to that vector, further filtered by the current stance.
It works well, it's fast, and it's responsive to player control. You never really 'wait' on an animation to happen. When we change animations being played, we do a simple blend transition so you never really have any jitter happen.

So, to expand upon that to achieve Motion Matching would involve a number of improvements, but for the initial implementation I'm shooting for first, it's actually quite straightforward. We need to:
  • Account for change in movement vector
  • Account for look direction
  • Account for expanded filter tags
  • Support layered partial blending of 2 clips, not just a fast transition
  • Eventually, add IK to allow foot anchoring to avoid foot sliding
To expand upon those points. We have the current movement vector figured for already. If you're moving forward, your vector is 0 1 0, for Y+. If you have your ForwardRun animation associated to a vector of 0 1 0, then it's the closest fit and it'll utilize that.
But what if you're turning, or you do a 180 degree pivot? You go from 0 1 0 to 0 -1 0 in a frame, and it'll just do a basic transition of ForwardRun to BackwardRun.
Not inheriently bad or ugly, but we lose out a lot of animation potential.

What we want to do is have an entry for an animation clip that informs we have a directional change of 0 1 0 to 0 -1 0, aka 'turn around 180 degrees'. So when we do our Pick update, we'd not only compare the current movement vector, but also that change in direction from the last update. Then we can see 'oh we're turning 180 degrees' we can then instead pick a TurnAround animation instead of jumping straight to BackwardRun.

We can likewise accomodate look direction, so you can have things like 'running forward but your character is looking over his shoulder', as well as adding a flexible tags system.
So if we have ForwardRun and ForwardRunWithRifle, both have the 0 1 0 movement vector, but the second one can have a 'RifleWeapon' tag. When we go to Pick, we can track what our active tags are and preemptively filter our results.
If the RifleWeapon tag is active we can filter to only have those results, and looking outside that tag only if we find 0 satisfactory matches. Likewise, if RifleWeapon is not active, we don't want our player to play ForwardRunWithRifle so we'd exclude those setting(unless we somehow don't find a better pick).

The cool thing about this is how simple, yet flexible it is. It'd support the exact same behavior the player class does now, but with the added functionality above, you can get towards what you see in the GDC demonstration or recent AAA games' level of animation quality without needing to build up animation state machines with thousands of branching states that are impossible to easily sift through or debug. It also works REALLY well with mocap(which I've been slowly expanding into in my personal trails) but also works just as fine with hand-made animation clips because the system itself only wants clips of animation. The structure of the clip is utterly irrelevent to how the system plays them back, which is awesome.

That flexibility and scalability is really cool, in my opinion and while it's obviously not a panacea system, it'd be flexible enough to work for most people, I'd wager. So I've been working on that for the personal project, but when I'm happy with it, the MotionMatchingAnimation component'll go in as standard for T3D as well.

This is getting pretty long again and I've a good deal more to talk about, so later tonight, I'll get part 3 up!
JeffR
Steering Committee
Steering Committee
Posts: 863
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Jun 24, 2018 2:52 pm
Part Threeeee

Building Editor
I'll post up some video of this in action in the next few days, as it's currently got some really janky rendering behavior happening, but it's an expansion on the tileset editor I posted about prior. As, if you've ever played the Sims, then you've got a pretty solid idea of where this is at. Placing individual tiles down got annoying, and this seemed like a good general purpose tool that'll get a lot of mileage ;)

The Clean Core
In the face of 4.0, we've been piloting a good deal of work in refactors of rendering, adjusting the platform layers, etc. Obviously it's needed work to modernize and sexify the engine, and implementations and R&D have been going pretty well(as can be seen via my workblog).

But one thing that's come up related to all this a good deal as the refactor work goes deeper down is just how messy and spaghetti-y the core of the application is. The main loop, various layers of cruft in main and utility classes, etc.

So one bit of discussion that cropped up is establishing a new, cleaner core to the engine application, and bringing over all the good stuff we like with the engine as well as all the excellent new developments, while leaving behind the spaghetti, the cruft, the fat. This would carry a number of advantages - smaller exe size, smaller, cleaner codebase to navigate, and an opportunity to touch up some deep level stuff that isn't as easy to get at currently.

When talking about HOW to do the Clean Core, 2 main approaches came up: a new from-scratch application layer, or utilizing T2D as a baseline. We know Andrew took a stab at something similar with his Torque6 attempt, with a few improvements, such as the DLL system, and implementation of BGFX.

This is the angle on it I've been looking into the past few weeks. What we'd be doing is less 'Torque2D but with some 3D stuff' and more 'Take Torque2D and make it Torque'. By bringing over the good stuff from T3D(and there is a lot, as we know) we can achieve the same feeling as T3D while a much cleaner, faster underpinning. I mean, I know it's 2D so it's faster anyways, but I fired up the ToyCar demo of T2D recently as part of this and I got 1400fps. Any application core that can reach 'renders so fast that the numbers are effectively worthless' is a fast application core. Obviously this isn't a proposal of 'throw everything out and start over' because that'd be really, really dumb and utterly unneeded.

What the proposal is, ultimately, is 'Lets make Torque3D, but with the clean application core that Torque2D's codebase provides'.

At the same time, what this would allow is a quicker implementation of quite a number of things:
  • The Inevitable GFX2(or 3?) allowing for modern render APIs, threaded rendering etc.
  • A total refactor of the material system and render pipeline based off the stuff in my workblog
  • A clean, consolidated platform layer without the half-n-half implementation there is now
  • Utilizing the threadpool in a ton of places in the engine, boosting performance by maximizing how many threads/cores we can utilize, making the core application more efficient
  • Full implementation of E/C being to core standard for objects


We'd naturally retain some aspects of T2D that are already there, such as:
  • The previously mentioned ultralight application core. Compared to T3D's usual exe size that's between 20mb and 200 depending on if you have debugging info in it, T2D's exe usually runs 2mb.
  • The Scene object. Not to be confused with SceneObject, Scene is an object that IS a reprensentation of the scene. Rather than relying on a nebulous, global SceneGraph, we can rely on the Scene for lookups and management of the scene. This is important, because it opens the door for doing stuff like having a StreamingScene which implements level streaming right into the scene management behavior without impacting the default behavior, etc. Or even a special 2D scene.
And of course, we'd be bringing over a LOT of excellent stuff from T3D because, well, it's going to be the next version of T3D(with prospects for 2D behavior in the future as well)
  • The networking, with all the improvements that have been made
  • All the updates that have gone into updating the console system and scripting layer
  • the EngineAPI system and the companion c-interface, which allows easy wrappering of console stuffs, most importantly retaining the ability for Lukas to keep hammering on with his most excellent C# work(as well as pave the way for any other script languages to be plugged in later)
  • PhysicsAPI system, and therefore PhysX and Bullet(and as mentioned in part 1, T3D's current physics)
  • SFX, allowing for flexibile audio options
  • SDL as the platform layer, only implemented more thoroughly. With T2D's lightweight core, this could even potentially open up mobile platforms in the future as well.
  • The Entity/Component systems I've been working on
  • The vast spread of utility classes and functions for things like math. Though I think we'd take time to consolidate them and maybe make them a build option to keep exe sizes down if they're not needed all the time
  • The various plugins and addons that have been added over time, like Walkabout, the awesome features added by AFX, etc.
  • Terrain system, though we'd probably take the time to update the old girl to make her faster and sexier
  • And a whooooooole lot of small doodads and useful functionality bits, various GUI controls, etc
  • Oh, and the entire editor suite, because it's a good bloody set of editors and tossing them out is a terrible, terrible idea. They'd see updates and cleanup, but they wouldn't be tossed out.
Now, you're probably wondering why we don't just go with Andrew's already established work, and there's a number of reasons for that. One is some concerns of licensing and copyright notations. But another big one is Andrew opted to utilize the BGFX rendering library, which we will not be using. Since he already implemented it pretty thoroughly, it'd take just as much time ripping it out and replacing it as if we just started with T2D clean, so not much reason there.

A few things he added would absolutely be useful to implement - his support for DLL plugins was masterful and we'll definitely take the opportunity to do something similar, which is great for plugins like AFX or various AI addons, as they can be more separated out from the engine core, keeping it clean.

But ultimately, given that it's only one or two bits we'd really be keen to keep directly, it makes more sense to kick off from the latest T2D and bring over the T3D sexy to make it a consolidated platform.
As I hinted at, another advantage of this is it would let us implement some 2D-specific bits like a Scene2D and various 2D components and BoxPhysics into the PhysicsAPI in order to make the Clean Core version of Torque jive both with 3d and 2d scenes in a clean, logical way.

So the prospects of it are, honestly, pretty sweet. We keep all the good familiar stuff we love from T3D, but for the deep-level stuff we get a much cleaner, newer(as a lot of you may not know, but T2D was an almost total rewrite of Torque Game Engine back in the day). This makes it easier to maintain, faster to run, and simpler to explore and expand.

So, dear readers, this is where I want to hear feedback on this great, crazy idea. I think it's a really smart plan that has far, far too many benefits, with the only con being it's going to take time, but ultimately you guy's opinions matter a whole lot in this decision too. Tying in on this would be even figuring we opted to go forward on this, would it mean you guys would be keen to seeing it be 4.0, and we just have another version or two of updates and fixes to the current model of the engine in a form of 3.11 and maybe 3.12? I had been figuring a 3.11 version was going to happen regardless for people that can't hop the bridge to all the big changes that come with stuff like PBR, but it's hard to predict the timeline of the Clean Core.
It'd obviously be relatively fast as it's so much more clean, leaner code to work with, but there's a lot we'd want to move over, and a good deal we'd want to add new, like the GFX2.

So, by all means, get in here and put in your 2 cents. Or 5 cents. or 10. Whatever number of cents you've got jingling around, this is important and your opinion on how we should approach this is too. I can safely say it'll be great, but considerations for what it'd mean for you guys must be made too.

I think that's just about everything for now. I'll definitely be back in the next couple days for more bits of the building editor and the like, but for now: discuss away!

-JeffR out.
Monkeychops
Posts: 25
Joined: Wed Feb 18, 2015 11:53 am
by Monkeychops » Mon Jun 25, 2018 9:51 am
@
User avatar
JeffR
Probably the biggest thing holding T3D back in recent years has been the fact that TorqueScript isn't very widely known, understood or supported.
I know that discussion has been had a lot of times and people say "if you know torquescript it does the job well" (which may be true, but still that in itself is part of the problem - most of the world's dev population don't know torquescript) and "everything is too hard-coded and built in/around torquescript it would be too much work to support other scripting languages" (which is a very important argument with only a small team to support it).

Perhaps with a new engine core we could finally have a new clean scripting API as well for which bindings could be made for other languages like C# and JavaScript?

Some benefits I could see to this would be:

- Appeal to a much wider audience (people that are used to working with Unity in C# for example)
- Be able to take advantage of a huge amount of open source code (Github is full of C#/Javascript implementations of anything from voxel engines to noise libraries, image processing libraries etc. etc.)
- Data Access. With languages like C# it's a piece of cake to do things like connect to SQL or NoSQL databases, map objects to data structures, work with JSON, XML or whatever other data needs the game has. Doing stuff like this in Torquescript can be a huge pain and is probably going to involve having to jump through a lot of hoops involving native code modules and exposing things to script.
- Portability. Being able to bring in code written for say Unity and move over to using T3D with the minimum possible effort.
- Tooling support (Being able to code in the most popular IDEs with full code completion, automatic refactoring etc.)
- Cleaner, more maintainable code (Languages like C# are better suited for bigger, more complex projects through being able to modularize and extend code more easily and built in support for things like collapsing bits of code you don't need to see in the editor)
- Performance (Torquescript isn't incredibly fast... a compiled C# assembly could in theory perform more complex calcs than you can feasibly do in torquescript without having to get into writing native code and recompiling).
- Code security. Instead of having a load of scripts easily hackable by the end user, a C# assembly could be compiled, obfuscated and/or protected by the various other encryption solutions available on the market.
Duion
Posts: 1114
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jun 25, 2018 11:09 am
@ JeffR Probably the biggest thing holding T3D back in recent years has been the fact that TorqueScript isn't very widely known, understood or supported.
You just made up a claim without providing any evidence that it is true.

I saw experienced programmers having no problems coding in Torquescript right from the start even though they did not know it before at all. Torquescript is pretty much like C and therefore not hard to figure out at all.

Regarding C# we have an implementation for this, but open source software should never depend on Mono or C# see here:
https://www.fsf.org/news/dont-depend-on-mono
Also most likely nobody will copy over their C# from Unity to Torque, you cannot just copy a game from one engine to another.

And Javascript should be pretty much self explanatory why not to use it.

Script code is usually not performance relevant code and if you want performance, put the code into C++ which will outperform any scripting language in performance.
Timmy
Posts: 364
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Mon Jun 25, 2018 1:01 pm
@ JeffR Probably the biggest thing holding T3D back in recent years has been the fact that TorqueScript isn't very widely known, understood or supported.
You just made up a claim without providing any evidence that it is true.

I saw experienced programmers having no problems coding in Torquescript right from the start even though they did not know it before at all. Torquescript is pretty much like C and therefore not hard to figure out at all.

Regarding C# we have an implementation for this, but open source software should never depend on Mono or C# see here:
https://www.fsf.org/news/dont-depend-on-mono
Also most likely nobody will copy over their C# from Unity to Torque, you cannot just copy a game from one engine to another.

And Javascript should be pretty much self explanatory why not to use it.

Script code is usually not performance relevant code and if you want performance, put the code into C++ which will outperform any scripting language in performance.
That article from the FSF is nearly 10 years old, on top of that MS purchased Xamarin, so they own mono lol and have kept it MIT.
301 posts Page 23 of 31

Who is online

Users browsing this forum: No registered users and 3 guests