Timmy wrote:Just to keep this thread updated, should be an official PR for dx11 by next week. Instancing is all done, heaps of problems fixed and the port is now about 98% complete.
Yeeeeeee.
Pre-Pull Request: D3D11 Initial testing
PR is here https://github.com/GarageGames/Torque3D/pull/1559
I will get started on phase 2 very soon which is all about cranking up the performance, phase 1 was nothing more than just a baseline port to get things running.
I will get started on phase 2 very soon which is all about cranking up the performance, phase 1 was nothing more than just a baseline port to get things running.
Timmy wrote:PR is here https://github.com/GarageGames/Torque3D/pull/1559
I will get started on phase 2 very soon which is all about cranking up the performance, phase 1 was nothing more than just a baseline port to get things running.
@
Thanks so much for this effort. This is the expansion to T3D's API I have been waiting for. It feels really good to see this sort of initiative from the community.
Recently I've pulled my head out the sand and decided to dust off my GitHub repository. I'm finding lately that many of the source changes I've been doing could be useful to others sitting in a repository. I've even got a couple super simple pull requests I really should run by the committee. When I see this sort of initiative from my peers, it really gets me motivated to use a little free time to contribute a bit back myself. Thanks for that, Timmy =)
Anyways, I guess I just wanted to express some sort of gratitude for this work and let you know I'll be testing it fairly thoroughly soon(potentially with a few different game builds).
For anyone interested the phase 2 of all this work will be here https://github.com/rextimmy/Torque3D/tree/dx11_phase2. Just be warned though, i can't guarantee it will always be stable, so treat it as experimental.
No problem @
TorqueFan , it was a lot of hard work but quite a few people not just myself.
No problem @
JeffR wrote:@TorqueFan
By all means, if you've got code you think would be worth getting into the engine, toss a PR up for it
Contributions are ALWAYS appreciated.
Honestly my repos are a mess. I had a couple tiny PR's ready to go, but lost them when I was updating my dev branch
Luckily they were tiny little fixes, but I'm not entirely keen on updating a dev branch in GitHub without damaging branches I've made from it. Perhaps I could just put those changes in the forum as a resource? The first change is literally a one line change, and it's subtractive at that( comments out an existing line of code ).D3D11
I was able to get it to compile using VS2013 on Windows10 without issue. Select DX11 and use it from options menu no problems with GTX 980.
I found 2 problems right away with my main project that prevented further testing with that project:
° CRASH - When opening GuiObjectView the application would crash. I assume it's when loading the shape or animation from the shape.
° BUG - Objects don't appear to support multiple materials. All my models would render with one material and the other materials on the model rendered white.
When I get a bit more free time I have some side projects with project-specific rendering code I will test with this.
. Just report anything you find, log is handy too.I just took a look into it, and very quickly realized that the source of the issues was from my own merged code! My custom GuiObjectView code extends the class to support cam nodes, blend animations, and hiding/showing sub-meshes. It all works fine pre this D3D11 merge.
But there's a catch, of course : All of this stuff is hooked to new GUI's and supporting scripts for said GUI's. So it's a tad bit of work but I'd be willing to wager I'll find the culprit hiding someplace in the initialization functions for the class - either in script or source(i.e. onAdd() or initMaterials() etc.). Bottom line, though, is I am able to use the provided D3D11 branch without issue prior to merging my updates. Therein lies the quandary - now I just have to buckle down and fix it lol.
I don't believe a log will be necessary but at some point I did want to release the extended GuiObjectView code as a resource to the community. I'd definitely want my changes to be compatible with the D3D11 update =) I'll have all the changes available on a GH branch soon enough(cleaned up a bit), so if the problem persists maybe someone could identify it. Moving forward I plan on blogging and sharing about my experiences with T3D, while providing code resources and so on. It's a geeky need that simply must be fulfilled - but more on that later (soon™).
Anyhow just wanted to be sure I let you know asap about my findings. The last thing I'd want is to have you chasing ghosts
But there's a catch, of course : All of this stuff is hooked to new GUI's and supporting scripts for said GUI's. So it's a tad bit of work but I'd be willing to wager I'll find the culprit hiding someplace in the initialization functions for the class - either in script or source(i.e. onAdd() or initMaterials() etc.). Bottom line, though, is I am able to use the provided D3D11 branch without issue prior to merging my updates. Therein lies the quandary - now I just have to buckle down and fix it lol.
I don't believe a log will be necessary but at some point I did want to release the extended GuiObjectView code as a resource to the community. I'd definitely want my changes to be compatible with the D3D11 update =) I'll have all the changes available on a GH branch soon enough(cleaned up a bit), so if the problem persists maybe someone could identify it. Moving forward I plan on blogging and sharing about my experiences with T3D, while providing code resources and so on. It's a geeky need that simply must be fulfilled - but more on that later (soon™).
Anyhow just wanted to be sure I let you know asap about my findings. The last thing I'd want is to have you chasing ghosts
Who is online
Users browsing this forum: No registered users and 1 guest
