[MusicallyInspired]

 Hendricks266, on 28 May 2016 - 12:59 AM, said:

A complete merge is desirable once PolymerNG meets the responsibilities of a source port, and can cleanly land on our codebase like the Enterprise-D saucer section.

Best analogy.

[Kyanos]

[Paul B]

 icecoldduke, on 28 May 2016 - 05:53 AM, said:

My goal is to eventually get the code merged with main. You never merge code into main, much less changes of this magnitude, over to main until its passed rigorous quality control testing. You never merge unfinished code over to main. My intent is merging my code into eduke32 main, but that's not happening until:

• The product is finished.
  
• Meets the standards TX and Hendricks set.
  
• Has had rigorous testing done it.

I'm not trying to fracture the community. Even though it might seem like that's what's happening, this is how software development is done. You keep mainline working, while you work on fancy new tech and you don't merge fancy new tech with mainline, and break everyone, until at minimum those three conditions are met. It is the correct way to make software.

Damn how I wish Microsoft as a company would operate this way. Life would be a lot better.

[icecoldduke]

Paul B, on 28 May 2016 - 08:45 AM, said:

Damn how I wish Microsoft as a company would operate this way. Life would be a lot better.

I can't speak for Microsoft, as I have never worked there, but not everyone follows by those rules. When I'm lead of a project, those are rules I rigorously make everyone follow. That and check-in buddies . Take a little time now, to save a whole bunch of time down the road.

[Kyanos]

Thoughts on TROR;

Earlier you mentioned optional switching between the vis passes, any chance you could get your fast vis pass running if TROR is detected or a flag is set or something. Maybe the new method is too far off from that to make switching viable... I dunno.

[icecoldduke]

Drek, on 28 May 2016 - 12:04 PM, said:

Thoughts on TROR;

Earlier you mentioned optional switching between the vis passes, any chance you could get your fast vis pass running if TROR is detected or a flag is set or something. Maybe the new method is too far off from that to make switching viable... I dunno.

Lets not go down that road yet. I believe its just an error with my implementation on the rendering side and has nothing to do with Polymost. If hypothetically I'm wrong, what your purposing is doable, but that would mean, you couldn't have any SOS visible, while you have TROR visible.

I'm not saying that I would do what your purposing, or that if its even needed; merely stating TROR would work with what you purposed.

[Kyanos]

Cool, glad to see it's a good possibility that TROR will remain unscathed.

icecoldduke, on 28 May 2016 - 12:11 PM, said:

you couldn't have any SOS visible, while you have TROR visible.

ha, I had to read that a couple times. I meant more of a per map instance, you're saying you can do it per frame which would be much better.

I highly doubt anyone has SOS within TROR, but Micky C is a real jerk like that

[Hendricks266]

HiPolyBash, on 28 May 2016 - 01:23 AM, said:

Wouldn't it make more sense for PolymerNG to be available as an option in EDuke32 alongside Polymer/Polymost?

That's what would end up happening.

HiPolyBash, on 28 May 2016 - 01:23 AM, said:

as opposed to having a separate distribution for a version of EDuke32 that relied exclusively on the PolymerNG renderer with the exception of the UWP version for Xbox One.

That's one of the big issues, actually: ice has his own build system set up that targets only UWP, meaning only Windows 10 and Xbox One. In theory PolymerNG should be able to run on anything that supports the graphics API ice is using: Direct3D 11 is supported back Windows 7. Ideally we would have GL and/or Vulkan (and GL ES, and Metal ) layers in place too, but the absence of those wouldn't prevent a merge.

Trooper Dan, on 28 May 2016 - 01:37 AM, said:

Of course, he also implied that PolymerNG meeting those standards was not foreseeable, which I guess is technically true since we can't actually see the future...but that seems overly pessimistic.

By "forseeable" I mean on the order of months.

[icecoldduke]

Hendricks266, on 28 May 2016 - 12:56 PM, said:

That's one of the big issues, actually: ice has his own build system set up that targets only UWP, meaning only Windows 10 and Xbox One. In theory PolymerNG should be able to run on anything that supports the graphics API ice is using: Direct3D 11 is supported back Windows 7. Ideally we would have GL and/or Vulkan (and GL ES, and Metal ) layers in place too, but the absence of those wouldn't prevent a merge.

I plan on making Win32 projects to allow for widerspread testing. Having Xbox One support IMO serves two purposes: a) potentially allows more people to run PolymerNG and B ) allows me to test things on min spec hardware. Also don't forget UWP on the Xbox one only has access to 45% of the CPU, with 2-4 cores and only 45% of the GPU. UWP on the PC can use full hardware. So technically speaking, min spec is 45% of the Xbox One Hardware.

Don't panic, I will have Win32 projects(Windows 7 x64 or higher) when I want more broader testing. While it's true DirectX 11 is required, this will run on DX10 hardware. I knows this because UWP on the XB1, restricts the feature set down to D3D 10 .

Bottom line, I will support Windows 7 and 8 when I need more broader testing. For now its Windows 10 and Xbox one only.

[Hendricks266]

I would like to merge our VS projects. Ideally they should be able to build both for UWP and Win32 if that is possible, though that may take the elimination of Makefile.msvc, which is probably overdue. The Xcode project I created can build for both OS X and iOS.

PolymerNG should also be able to build using our GNU makefiles. I am cleaning them and the codebase, but that is a discussion for another thread. Don't bother for now.

[icecoldduke]

Hendricks266, on 28 May 2016 - 01:17 PM, said:

I would like to merge our VS projects. Ideally they should be able to build both for UWP and Win32 if that is possible, though that may take the elimination of Makefile.msvc, which is probably overdue. The Xcode project I created can build for both OS X and iOS.

PolymerNG should also be able to build using our GNU makefiles. I am cleaning them and the codebase, but that is a discussion for another thread. Don't bother for now.

Agreed on all counts.

[Micky C]

By merged when "finished", do you mean the base polymerNG renderer or the full thing with all the fancy effects you wanted?

And Drek that's not where the saucer section connects to

[HiPolyBash]

Is the plan still for PolymerNG to eventually be moved over to Vulkan as it's a low level, platform agnostic API?

[icecoldduke]

Micky C, on 28 May 2016 - 05:35 PM, said:

By merged when "finished", do you mean the base polymerNG renderer or the full thing with all the fancy effects you wanted?

And Drek that's not where the saucer section connects to

Finished as in its feature complete, and stable. When its get to the point were most of the bugs are ironed out, and we are 100% feature complete, I will start releasing "release candidates". When the majority of users on here sign off on any one release canidate, that will be the build we will try to integrate over to main.

HiPolyBash, on 28 May 2016 - 05:39 PM, said:

Is the plan still for PolymerNG to eventually be moved over to Vulkan as it's a low level, platform agnostic API?

I assume your asking, because you are a non windows user . Linux support and such Vulkan support, are down the line issues. I don't know if Hendricks and TX will want Linux support for PolymerNG before it goes over to main. This will be a big task. In the meantime, there are little to no gains for using Vulkan in PolymerNG at this present time; therefore I will only look into Vulkan support when the Windows version is feature complete, and have to move on to Linux.

[HiPolyBash]

I was asking as a Windows user given there are gains to be had in terms of draw call overhead when using Vulkan reducing frame time which would be beneficial to your performance goals in the long run as well as Vulkan being cross-platform. I was just curious if it were still on the cards as the old thread specified that moving over to Vulkan was the end goal. I was unsure if that had changed given the focus shifted more toward a DirectX 11 renderer.

[icecoldduke]

HiPolyBash, on 28 May 2016 - 05:51 PM, said:

I was asking as a Windows user given there are gains to be had in terms of draw call overhead when using Vulkan reducing frame time which would be beneficial to your performance goals in the long run as well as Vulkan being cross-platform. I was just curious if it were still on the cards as the old thread specified that moving over to Vulkan was the end goal. I was unsure if that had changed given the focus shifted more toward a DirectX 11 renderer.

Direct3D 11 has a lot of advantages for developers; the visual studio graphics debugger is fantastic and has saved me a lot of time on PolymerNG. That is one big reason I went back to Direct3D 11(along with supporting more users). Direct3D 12 and Vulkan don't have great graphics debugging tools yet; which means it would take longer to figure out bugs. On a project I'm doing in my spare time, time is a currency I have to spend wisely.

That aside I know you guys just saw the new Doom video showing the performance gains in Vulkan. Right now I would like to focus on getting NG features in and working. The performance gains we could get form Vulkan on high end crazy user maps, might be worth it. I have a RHI layer for a reason; So when and if I decide to add Vulkan support, I won't have to redue the renderer.

Stop believing the marketing hype. Direct3D 11 still has plenty of life in it. The other reason I don't initially want to move to Vulkan is I know I will end up getting more support requests, due to different levels of fuckage happening with different hardware configurations. So right now I plan on proceeding with Direct3D 11 for the time being.

[HiPolyBash]

I appreciate the clarification on that. I simply asked due to the cross-platform nature of the renderer for Linux/OS X users and the theoretical performance gains to be made in regards to draw calls and reducing frame time as well as the previous thread stating that eventually you'd move over to Vulkan and I was unsure if anything had changed in that regard.

Once again I have to applaud you for your efforts. It's really fantastic to see progress being made toward a renderer with support for everything that content creators in the community have been requesting for years. It's certainly going to be interesting to see what comes out of this!

[Hendricks266]

icecoldduke, on 28 May 2016 - 05:46 PM, said:

I don't know if Hendricks and TX will want Linux support for PolymerNG before it goes over to main. This will be a big task.

Hendricks266, on 28 May 2016 - 12:56 PM, said:

Ideally we would have GL and/or Vulkan (and GL ES, and Metal ) layers in place too, but the absence of those wouldn't prevent a merge.

[icecoldduke]

That answers that then. We'll see how things go, and how much bandwidth I have. It might be better to get the Windows version(Win32 and UWP projects) over to main before adding another RHI layer. Anyway this is a down the road issue. We have a lot to do between now and then.

[Mblackwell]

https://www.youtube....YmY&t=02h09m20s

Edit: Also, Vulkan is a thin shim in the end. If you skip backward to the talk by Dan Baker he talks about how Vulkan expects you to do the right thing in your app because the driver won't save you like it does in other APIs. So if you app is well written you should not see differences on Vulkan supported hardware of any type on any OS.

Also:
https://lunarg.com/vulkan-sdk/

Edit2: Realistically Vulkan is kind of a big undertaking on the initial setup (time to triangle). GL using AZDO type techniques would probably be easier to get up and running (not including time spend debugging difference in driver implementations), although you'll probably have to do silly things like technically run GL in a lower version context than desired and call extensions if you want Mac OS to like it because they are terrible about updating their drivers.

[icecoldduke]

Mblackwell, on 28 May 2016 - 09:02 PM, said:

https://www.youtube....YmY&t=02h09m20s

Edit: Also, Vulkan is a thin shim in the end. If you skip backward to the talk by Dan Baker he talks about how Vulkan expects you to do the right thing in your app because the driver won't save you like it does in other APIs. So if you app is well written you should not see differences on Vulkan supported hardware of any type on any OS.

Also:
https://lunarg.com/vulkan-sdk/

Edit2: Realistically Vulkan is kind of a big undertaking on the initial setup (time to triangle). GL using AZDO type techniques would probably be easier to get up and running (not including time spend debugging difference in driver implementations), although you'll probably have to do silly things like technically run GL in a lower version context than desired and call extensions if you want Mac OS to like it because they are terrible about updating their drivers.

Vulkan is a huge undertaking, and is out of the scope of what I want to do over the next few months. I understand its the big thing right now(hey you can have all acess to the hardware!), but in reality this isn't the case. It's true you get more granular control over things like the command buffers(which can be a big win), but you don't really get control over how the shader pipeline works for example. With Direct3D 12 and Vulkan you can prepare the data how you want to send to the GPU, but after you send the data down to the card, its hands off at that point.

The issue with build is all the different little sectors you guys use to make detail. All of these little sectors create a bunch of small pieces of geometry. For each piece of geometry that has a different material, shader attribute, etc, etc requires state changes. This is required whether or not your on Vulkan or Direct3D 12 or Direct3D 11. My answer to this problem is going to be a plane property table. Instead of updating a constant buffer, which requires a state change, we upload all the plane properties to a texture at the start of the frame. Then, remember each vertex has a sectorId, we use that to look up into the plane property table. All of this means all I have to do is bind the plane property texture and I'm done. No constant buffers updates between draw calls. That means the only state changes I'll have is what textures to bind, which would be solved with Virtual Texturing.

That's my working idea anyway. I haven't tried this idea out yet, but if it works then the performance gains with Vulkan vs Direct3D 11 RHI layers in PolymerNG should be negligible. I'm sure Plagman has more insight into Vulkan then I do , since I haven't worked with it, but I don't think its worth me dropping everything right now and implement it.

[MusicallyInspired]

Mor my part, I only heard about it (let alone was excited about it) because you mentioned it in your initial PolymerNG pitch thread. Whatever will be will be. First thing's first obviously.

[Kathy]

But without doing cross-platform/vulkan/gl now, it'll be a pain in the ass later. It's a typical mistake made by many game developers.

Quote

I don't think its worth me dropping everything right now and implement it.

It actually might be. It's your choice obviously and I don't understand that stuff to have a constructive advice, but I won't hold my breath for a gnu/linux support.

[icecoldduke]

Kathy, on 29 May 2016 - 02:35 AM, said:

But without doing cross-platform/vulkan/gl now, it'll be a pain in the ass later. It's a typical mistake made by many game developers.
It actually might be. It's your choice obviously and I don't understand that stuff to have a constructive advice, but I won't hold my breath for a gnu/linux support.

The code hightlighted in green, is non graphics api specific. It has no idea if I'm using Vulkan or Direct3D 11 or magic api #12. That is the core renderer. The core renderer calls into the RHI layer(whats in red), that code is API specific. If I choose to use Vulkan at any point I just have to rewrite the code in red. The code in green stays the same regardless of whether it I'm using Direct3D 11 or Vulkan. . I'm not saying it will be any easy task by any means, but I designed the renderer in such a way that I can replace the graphics API at any time.

There are lot of engines out there that inline the graphics api with the renderer. I choose not to do that .

[Kathy]

Yeah, I read that in earlier posts. If it's gonna continue to be in independent modules and have no unforeseeable consequences, then it's good. But it's just... I've heard similar arguments before. Obviously not to the point of actually showing and assuring that everything is separate, but still. I hope you're right and it won't be a problem solely because you haven't started crossp-latform route from the start. Because actual porting most of the time is not that easy compared to cross-platform development.

[icecoldduke]

Kathy, on 29 May 2016 - 07:15 AM, said:

Yeah, I read that in earlier posts. If it's gonna continue to be in independent modules and have no unforeseeable consequences, then it's good. But it's just... I've heard similar arguments before. Obviously not to the point of actually showing and assuring that everything is separate, but still. I hope you're right and it won't be a problem solely because you haven't started crossp-latform route from the start. Because actual porting most of the time is not that easy compared to cross-platform development.

I would like to point out it is cross platform, it works on Windows and the Xbox One . I understand what your saying though.

[Mblackwell]

Thing is it doesn't always matter if your code is non-API specific as certain ways of batching calls (for example) work better in one API over another. And if you aren't holding to certain POSIX standards your application may not compile on GNU/Linux or Mac OS.

So if you plan to be non-Windows family then you have to keep it in mind as part of the design.

[icecoldduke]

Mblackwell, on 29 May 2016 - 07:37 AM, said:

Thing is it doesn't always matter if your code is non-API specific as certain ways of batching calls (for example) work better in one API over another. And if you aren't holding to certain POSIX standards your application may not compile on GNU/Linux or Mac OS.

I can extend the RHI for batching of draw calls, this is not a issue.

Mblackwell, on 29 May 2016 - 07:37 AM, said:

So if you plan to be non-Windows family then you have to keep it in mind as part of the design.

All code in the PolymerNG folder(core PolymerNG renderer) will compile with any compiler out there. All OS functions have wrappers. There is no graphic api, os specific call, or compiler specific non sense inside of the core PolymerNG renderer.

This isn't my first bbq .

[icecoldduke]

PolymerNG Xbox 1 first pass model support and Hires UI. Model Vertex Animations don't work, and first person models aren't implemented yet. Sorry for being overbright - this is my projectors fault.



I'm talking with content guys right now about getting the vertex animation exported as skeletal animation. With all vertex animations included, uncompressed, the model cache is about 2gb of data. That's just too much. Were as vertex data for all assets is about 100mb. My next step is to get skeletal animation support in, FBX support is already in, just need to export the skeletal data to the model cache and implement skeletal animation on the engine side.

[HiPolyBash]

Awesome progress. I can't wait...there's only one solution..