Microsoft Trademarks Direct Physics - Is This A New Physics API for DirectX 12?

Microsoft trademarked Direct Physics. After their acquisition of Havok in 2015, this sounds like a dedicated physics API for DirectX 12.

[LavaLampGoo]

Like the article says, this sounds like prep for some announcement at E3 and my guess is involving the Scorpio

[TheCommentator]

And XB1.

DX12 HW is designed to be really efficient with advanced physics and lighting renderers, so it looks like the aquisition of Havok was merited after all. Nvidia corrobotates this, saying that their new physics and lighting rendering solution works best on DX12 HW. Scorpio development is supposed to make XB1 games look better too, according to Turn 10, but you're right about it likely being announced at E3.

[Mystogan]

nah, this is something for developers. It will likely be revealed at //BUILD/ next week.
That's their developer conference.

[TheCommentator]

Good point, I forgot about Build. 👍

[rainslacker]

MS isn't going to leverage Havok to be DX exclusive. That would be completely idiotic considering what they paid to acquire Havok. Havok is worth a lot more as a licensed API or game engine than it is as a marketing tool for DX. If MS leverages havok to be DX exclusive, then it just opens the doors for other capable physics API's to make their way into the market....which on the back end they already are, because some people were concerned MS would strip Havok tools away from them before they could finish development. That isn't something that MS wants, because it just gives more leverage for Vulkan to have a supplimental API which can outdo whatever MS has to offer. That isn't something NVidia wants, because the more people move towards open source compatible solutions, the less relevance their DX ball licking has....and Vulkan and OpenGL have already given AMD an edge almost out of nowhere among developers.

Anyhow, to be more informative, and not seem like I'm merely trying to attack you(because I'm not), this is Havok tools being integrated into DX with a rebranding. It's not something that is hardware dependent, nor does Havok physics tools work on the hardware level like that. Physics tools in general are simple math(relatively speaking) type tools which run extremely fast, and don't require special processes to make effective. Havoks lighting tools work on a similar principal, but are hardware dependent to some degree, however, their lighting processes aren't anything out of the ordinary that wouldn't be built into hardware either way if it's going to support certain functions. Quite honestly, MS current API is actually stronger in the lighting rendering pipeline than Havok ever was.

Personally I wouldn't really trust anything NVidia says about what works best where. If their tools work best on DX hardware, it's because that's all they care to support. Considering NVidia is all about DX because they can't be fussed to make something like Vulkan that their competitor did, what is their opinion on the matter worth at all? NVidia isn't in the business of making physics model processes. They're graphics makers. Their lighting rendering solutions work better on DX hardware, because they were built in conjuction with DX and with DX in mind. Anything they make in terms of physics processing relies strictly on the GPU compute aspects of it's chips, and the math itself doesn't require anything substantial on the processors themselves. Game physics is about as simple physics as it gets. Seriously....game physics algorithms are rudimentary middle school math that can all be done in a few steps, using mostly add, subtract, and multiply with some floating point thrown in to keep it accurate.

[TheCommentator]

Right, Rain, but I didn't say it would be exclusive. I said it would work really well on DX12 HW, which is designed to run physics and lighting. DX12 doesn't make Havok effective, it makes it more effective... or did you forget what a HW accelerator is?

Also, you're really going to call what Nvidia showed at GDC rudimentary math? It is the beginnings of CG quality physics being rendered in real time, and it's far more advanced than any other physics renderers available because of it's use of DX12. They even went as far as to explain that their solution wouldn't run as well on other HW. Besides, the real point is that it doesn't matter how fast physics currently are because there still isn't enough processing power to run complex physics and lighting in real time. Simple ≠ complex.

Furthermore, who says Direct Physics is simply Havok with a new name? MS could have used Havok as a base to build a physics renderer similar to Nvidia's, but MS had mentioned Direct Physics as far back as 2006, so it's likely that MS incorporated elements of Havok into DP and not just changed Havok's name.

As far as the "DX12 ball licking" goes, grow up with that rhetoric. DX12 will make a difference because it's HW >in addition to< being an API. Does PS4 have DX12? Without it, it will have to use emulation of the HW functions in order to render scenes of the same quality, while DX12 will add to the processing of what the XB1 already has. You don't have to believe me, but when XB1 sees parity with PS4 multiplats remember this conversation.

[rainslacker]

First, let me say I wasn't really trying to dissuage against your comment completely. That wasn't my intent.

But, moving on to address your reply, Havok isn't a hardware based physics engine. That would be something more like PhysX. Havok at it's core is built to be hardware independent. Generally, DX side stuff like this is also hardware independent.

What MS is doing here, is integrating the physis engine into the SDK. That's where it becomes beneficial. Unless MS has greatly revamped the already great Havok tools, I can't see that the way it runs will be changed at all between DX hardware and non DX hardware. It's not to say that certain hardware sets couldn't include processes which run Havok tools functions more effectively, but I feel at this juncture, that is a lot to presume, and outside a couple aspects of the tools, I'm not sure it's necessary due to how efficient the tools already are.

I think it's important to understand just how good Havok tool's are. And I for one am quite excited that it's being implemented into a SDK level solution for many reasons. The socketed approach that has been had to be taken up to now is sufficient, but this just makes everything more streamlined.

Anyhow, onto the math of Nvidia. Yes, I'm going to call it rudimentary math. When I say rudimentary, it's entirely relative to actual complex physics calculations which are used for say actual CG rendering techniques, or real world prediction/application of physics models, which are not practical for in game implementation. The math used in games is simple. It's about as basic as it gets, because that is what works best, and overall, super complex algorithms just aren't needed for any kind of physics that you see in games. Physics, by and large, is made up of "tricks" which uses algorithms which achieve a similar or acceptable result without worrying about exacting precision.

This isn't the same as rendering physics, which is where things like lighting and what not reside. But overly complex algorithms which provide real photo-realistic images are still a long ways off from gaming application. DX hardware or not, you're talking about hundreds of millions of compounding algorithms processed per pixel to abstract how light is reflected, and it takes an exhorbitant amount of time...so even in lighting physics, it uses "simple" math to achieve desireable results.

"who says DXP is merely Havok with a new name"

It's havok tools integrated into the SDK. This is actually known already in the dev community. Many people are excited about it.

If it's more....what would it be? Based on all I've said, what more is needed?

I'm not saying it's all Havok tools, or what MS has changed compared to the Havok tools package, or how exactly it's integrated for development implementation, but it is Havok tools.
As far as growing up....maybe I could have chosen better wording, but NVidia has a history of talking up DX and not taking responsibility for poor performance from anything else because they simply decide not to write drivers. Sorry if my callous description offended you, but that's what NVidia has done for a while now, and it's annoying for devs, and for some people who actually understand that NVidia is often full of sh*t when it comes to this stuff.

[rainslacker]

"Does PS4 have DX12"

No. But it won't have to emulate it. That's not how API's or tools like this are set up. Havok has run great on PS consoles since it's inception, just as it has on Xbox since it's inception. Havok isn't hardware specific, and despite this new itteration having an SDK level implementation, which is good for Windows hardware support, MS is still going to offer Havok tools in a way that allows for portability. If they don't, they've pretty much just rendered their new toolset useless to any development outside of those which are only meant for windows platform release. Even if they don't offer up Havok, then 3rd party tools will make it more than possible....such as the ones I build which specifically work to port code between platforms where no direct portability is avaiable.

Normally I don't like to list my resume, but consider that I got my first major job in the game industry due to having written my own physics engine, which led to me becoming a tools developer, and I am intimately well versed on how these things work, because it's made up a bulk of my professional career.

That being said, don't take what I say in either comment in this thread as some sort of derision against what MS is doing. This is actually one of the most exciting things I've ever looked forward to on a professional level. It's not something that's going to make a huge difference to the end user, as I assume end results will be on par with what we have now, but from a development perspective, this is pretty exciting stuff.

Sorry if I seem argumentative with you about it, but I actually do understand what's going on here, and I feel that my knowledge on the subject is much more relevant than you're correlations to things which aren't applicable to what is happening here. Going forward, I have no intention of being critical of this, and really look forward to sharing my expertise to those who may wonder what some of all this means for them or development.

So take that for what it's worth.

[Mystogan]

Its gonna be revealed at build next week, not E3.

[shiva1]

May 10 to 12 in 2017. I have my eyes glued at this event every year.

[XanderZane]

It just keeps getting better and better. Rich L. was right. There was a lot more news about Scorpio then what he couldn't share.

[IamTylerDurden1]

This was known..

[Festano]

Would be great, I love games with highly accurate physics

[XiNatsuDragnel]

Interesting

[christocolus]

Simplygon, Havok, Direct Physics... These will definitely help improve game development. Hopefully, we will learn more at E3.

[gangsta_red]

Sounds like MS is suiting up for some interesting games.

[christocolus]

Yeah. Can't wait to see what they have planned for E3.

[Alexious]

Hopefully. They need to announce more first party games

[SpaceRanger]

They wouldn't put focus into this at E3. This is dev conference material. So don't hold your breath

[freshslicepizza]

@SpaceRanger
"They wouldn't put focus into this at E3. This is dev conference material. So don't hold your breath"

I imagine they will highlight some of the new abilities on the hardware, so please do keep holding your breath.

[timotim]

MS seems to be doing what I hoped...focusing on building game engine elements that not only 3rd party studios could use, but for first party as well.

[Goldby]

yes, instead of designa nd build the games themselves, charge others to use your product to makea game for their system.

Ms at the end of the day is looking for the easiest buck

[rainslacker]

I think it's a new package for what already exists. I know MS has some new physics model API's coming out which are supposed to address some needs which currently have been up to the developer or tool makers to develop. basically they're moving it out of the tools realm, and making them more of an integrated to the SDK solution.

I'm supposed to be getting some information next week on what this is all about. I have a feeling it's just going to be what I already know exists, but put into a MS bundled package, with some workload algorithms likely redesigned from current offerings to match up with the overall DX game loop algorithms....which is something that used to be have to be done on a per game basis.

That in itself is a good thing for developers though, because it means less work on their end to figure out what works best in their own implementations. Kind of requires understanding how 3rd party tools and built in SDK solutions differ from each other in the development cycle, which I'm not going to get into excessive detail about....because I don't know how to talk about it in laymans terms.

Anyhow, I don't see it dramatically changing game development, because there is nothing new on the physics front that is required for current game designs to run.

There is no need right now to reinvent the wheel with complex physics models, because the physics models which have existed for a long time are sufficient, elegant, and efficient. Making them more complicated just makes things worse, and MS knows this, because they're software engineers. When it comes to physics in games, simpler is better, because it means more can be done with the same effect. Game physics is quite literally some of the most basic junior high level math you can imagine nine times out of ten. That's all it needs to be.

I don't see a lot of this being talked about at E3. Dev stuff like this is extremely dry stuff, and people would zone out. When it comes to stuff like this, I'd see them showing, not telling, and when telling, they're likely to simply show and not get into the details. If you want to see how exciting this is on a development level, just watch a build or GDC conference about engineering stuff in general. It's very technical. For those that work in those fields, it can be very interesting, and even cool at times, but to the average person with only a cursory knowledge of game design, and even less knowledge on what's on the game code side of stuff, it's all just a bunch of jargon and high level details about how to make things work. Just think of it the difference between MS showing CD3's destruction physics, versus the actual discussion during the same showing which explained how it worked. How many people actually understood or listened to the technical stuff and how many people actually talked about the results themselves? E3 is about results....Dev conference panels are about boring technical stuff.:)

[Aurenar]

Technical test for physX retirement?

[KaiPow]

PhysX was a neat concept but I didn't like having a separate card dedicated to it.

[Alexious]

PhysX was bought out by NVIDIA a long time ago. This is about Havok.

The PhysX middleware nowadays isn't used in that many games, if you were referring to that.

[KTF26]

Actually PhysX is used in much more games than what you think
PhysX is full physics engine and it's the main physics engine used in Unreal Engine 3, 4 and Unity 4, 5
most if not all games use these engines use PhysX
but it has some features require nvidia's hardware and we rarely see these features implemented these days

[rainslacker]

PhysX has always paled in comparison to Havok tools. In any case, I'm not aware that DX ever directly integrated PhysX into it's SDK. It offered socket level implementation, but beyond that, DX had it's own physics API's which were just as capable as physX most of the time, and if they weren't, third party tools were usually more capable. The necessity for things like PhysX aren't even really required anymore. OTOH, SDK level physics integration is really long overdue. Having to tie in a physics engine on top of whatever the API's pipeline was was just an extra step, and could sometimes not work the way it should have without extra work.

@KTF

PhsyX is the main offering for UE and Unity, because it doesn't require anything to include. But most big games use third party physics engines because they're more efficient and typically run more physics algorithms without the need for special hardware(or high level implementation routines). If you look at the credits of any big game, you are much more likely to see the Havok logo somewhere in there, because it's just that good. NVidia had PhysX at a time when it made more sense to have a hardware level solution. Nowadays though, GPU Compute is generally much better and infinitely more versatile. I always felt PhysX was long overdue for retirement.

[ccgr]

Looking forward to finding out more!

[XXanderXX]

Wild , sounds interesting

[Ulf]

If Microsoft makes Havok licenses free, via making it part of DX, but charges on other platforms, you can believe some devs are going to favor MS over Sony. A LOT of devs, particularly indies.

Havok costs a buncha money, and everybody uses it, because it's just plain the best. Of course, it's really the support fees that get you, and they will still charge for that..

[rainslacker]

Some devs maybe. But cheap or free third party physics tools are readily available. I see them still offering Havok for other platforms, which will likely directly "port" between different API's, because it's almost necessary. It also makes sure that MS makes money off the licensing of those tools.

I felt this was likely MS end game after thinking on it after they brought Havok. I couldn't see them removing Havok engine or tools from the market for exclusive use on MS platforms, because they just spent way too much money for the acquisition. It makes no sense acquiring such a valuable product, then removing it from the market, when they could have simply made their own solution at a fraction of the price.

Making Havok tools into a SDK level implementation does indeed make it very attractive to choose DX when making one's game though. However, unlike what I see some people posit, it doesn't mean that it's going to run better on MS platforms. It just means that less work will have to be done on the MS platform versions, and that getting things up and running on MS platforms will be quicker, while it will require licensing of some sort of porting tool to move over to Vulkan...which itself is just a rendering API. But when it comes to game engines, or other companies SDK's, it now means that MS gains revenue from the licensing of the tools required to get it to run on other platforms.