[icecoldduke]

 Mblackwell, on 25 May 2016 - 04:37 PM, said:

BTW your aspect is wrong in the PolymerNG screen you posted. Not sure why, but it's pretty off.

I'll look into that; but clcoast is running at 100fps . I remember a lot of you on here thought that could never happen.

[Mblackwell]

But now we don't even know if you're rendering it correctly.

[Micky C]

In addition to those secret levels in Duke 3D, I remember William Gee made a Dukematch level that made heavy, wide-spread use of SOS to dis-orient the player and create interesting pathways.

There's also a level in the AMC TC Episode 3 that takes place in a virtual reality and uses SOS to make intentional visual glitches.

Although by the sounds of things the issue has been resolved anyway.

[icecoldduke]

 Mblackwell, on 25 May 2016 - 04:42 PM, said:

But now we don't even know if you're rendering it correctly.

Aside from a few things, its pretty damn close . Another option I thought of is doing a pre-vis pass, during level loading. If I can scan over all the sprites that can move sectors then I could do previs. I know con scripts can move sectors, can I scan over the con scripts to figure out what might sectors it might touch?

[Mblackwell]

In Polymer if you disable lights you should be getting multiple hundreds of FPS in clcoast, and if you disable the shader that converts all of the tile colors to the correct shade table lookup then you shouldn't drop below 60.

(not so stealthy edit: Granted I'm on an i7 4770k and a GTX 970, but that's at 1920x1200)

[icecoldduke]

 Mblackwell, on 25 May 2016 - 05:00 PM, said:

In Polymer if you disable lights you should be getting multiple hundreds of FPS in clcoast, and if you disable the shader that converts all of the tile colors to the correct shade table lookup then you shouldn't drop below 60.

(not so stealthy edit: Granted I'm on an i7 4770k and a GTX 970, but that's at 1920x1200)

Were basically on the same hardware. My i7 is a 6700. What is your frame rate with and without turning off everything you mentioned while you are in that exact spot as I took my screenshots at? What cvars did you turn off? Can also you take a screenshot?

The area I took the screenshot in is the worst case for that map. I can get above 50 and even above 100 in Polymer in clcoast depending on were the camera is looking. The camera looking down the canyon at that spot causes a huge perf drop in Polymer.

[Mblackwell]

Loading it up and playing to about that spot (as far as I can tell) I get 50+fps with r_pr_lighting 0, r_pr_shadows 0, and r_pr_artmapping 0. That jumps to 70+ if I disable VBOs (r_pr_vbos 0).

In both cases looking or moving around causes the framerate to jump drastically, to well over 100+fps (in some cases 300-400, and into the 500+ range), even with VBOs and the artmapping shader turned back on.





Note this is without any HRP stuff loaded.

[TerminX]

How are you handling textures that change tile number, shade, etc? Presumably you have a way to handle that without re-uploading the whole geometry since it's something that happens all the time. What if you just hacked something in to draw anything the portals say isn't visible with a null (transparent) texture?

Just throwing shit ideas at the wall and seeing what sticks.

[icecoldduke]

 Mblackwell, on 25 May 2016 - 05:13 PM, said:

Loading it up and playing to about that spot (as far as I can tell) I get 50+fps with r_pr_lighting 0, r_pr_shadows 0, and r_pr_artmapping 0. That jumps to 70+ if I disable VBOs (r_pr_vbos 0).

In both cases looking or moving around causes the framerate to jump drastically, to well over 100+fps (in some cases 300-400, and into the 500+ range), even with VBOs and the artmapping shader turned back on.

Note this is without any HRP stuff loaded.

I can confirm that r_pr_vbos does cause the frame to jump to 50fps. The problem is its still taking 20ms to do just the albedo pass. That doesn't leave any room for any other effects. I want PolymerNG to never exceed 16ms. Can you confirm at that spot were I'm at in the screenshot you are getting 20ms( 52 fps).

I want the geo pass to only take 1-2ms tops.

 TerminX, on 25 May 2016 - 05:14 PM, said:

How are you handling textures that change tile number, shade, etc? Presumably you have a way to handle that without re-uploading the whole geometry since it's something that happens all the time. What if you just hacked something in to draw anything the portals say isn't visible with a null (transparent) texture?

Just throwing shit ideas at the wall and seeing what sticks.

Right now shade info etc is being uploaded via a double buffered constant buffer. I plan on moving that data to a lookup texture of some kind. The only geo thats uploaded dynamically is geo that changes position during a frame. That null transparent texture idea is interesting, could you elaborate a bit more on it?

[Mblackwell]

With the settings I mentioned (disabling r_pr_artmapping and r_pr_vbos, etc)

[icecoldduke]

 Mblackwell, on 25 May 2016 - 05:36 PM, said:

With the settings I mentioned (disabling r_pr_artmapping and r_pr_vbos, etc)

13ms is too high. 7ms isn't great either. Ideally I want to cut 7ms down to about 3ms, since I'm CPU bound at the moment, that should be doable. Remember guys in PolymerNG I want to have lighting, skeletal animation, shadows, HDR, tone mapping, volumetric lighting scattering, screen space reflection, and FXAA. 16ms = 60fps. Currently in Polymer you would only have 16ms-13ms = 3ms to play with, thats nothing. When I get the CPU down to match the GPU, I'll have 16ms-4ms = 12ms to play with.

Some of you might be thinking my performance enhancements are over kill, but the fact is the longer the albedo pass takes to do shit, the less fancy stuff we can render, and still achieve 60fps. At the end of the day, you have to trade off what you want. Do you want things like global illumination or sector over sector? I plan on still finding a solution to the SOS issue, but I can't think of anything, at least right now, that will offer the same performance as the current setup, without having visibility pre-generated. I know you guys would hate having to run a build tool everytime you make changes to your map. So there are going to be trade offs, you guys need to tell me what you guys want.

As many of you know I wrote a Volumetric Light Scattering plugin for UE4. I want to add this to PolymerNG. I can't get this effect to match framerate if I can't find a good solution for SOS.

[TerminX]

 icecoldduke, on 25 May 2016 - 05:23 PM, said:

Right now shade info etc is being uploaded via a double buffered constant buffer. I plan on moving that data to a lookup texture of some kind. The only geo thats uploaded dynamically is geo that changes position during a frame. That null transparent texture idea is interesting, could you elaborate a bit more on it?

Basically you'd run through the existing software sector/wall collection routines, store the results, and when rendering you would draw these surfaces with a completely transparent dummy texture so that they wouldn't actually appear in the rendering output. I don't know if such a hack is viable since I'm not really familiar with your code or how it works.

[Hendricks266]

 icecoldduke, on 25 May 2016 - 05:48 PM, said:

When I get the CPU down to match the GPU, I'll have 16ms-4ms = 14ms to play with.

Hmm.

[Mblackwell]

GI or SOS?


I'd take SOS.





You should dump the geometry from Clear the Coast and see how UE renders it, for the sake of curiosity.

[icecoldduke]

 Mblackwell, on 25 May 2016 - 06:12 PM, said:

GI or SOS?


I'd take SOS.





You should dump the geometry from Clear the Coast and see how UE renders it, for the sake of curiosity.

Are you sure you want SOS over VXGI?

[Mark]

I guess I need to do a little research on the difference between SOS and ROR. The first line in the Eduke wiki says "Room Over Room (ROR), also referred to as Sector Over Sector (SOS) "

[icecoldduke]

 Mark., on 25 May 2016 - 06:25 PM, said:

I guess I need to do a little research on the difference between SOS and ROR. The first line in the Eduke wiki says "Room Over Room (ROR), also referred to as Sector Over Sector (SOS) "

No.

Sector over sector is when two sectors can overlap, but not see each other. Room over Room is when you can see and travel from sector A to sector B through the floor or ceiling. Room Over Room support works just fine with the current system.

[Mark]

Then I guess I'm in the minority that would choose GI.

[TerminX]

You absolutely cannot have a Build renderer that doesn't handle multiple sectors occupying the same "physical" space properly. It's nonsense. It's like saying "hey, let's make a renderer that doesn't even work with the original maps". Just stop. Accept that this is absolutely a required aspect of the engine and work it into your plan.

[Paul B]

 icecoldduke, on 25 May 2016 - 06:28 PM, said:

No.

Sector over sector is when two sectors can overlap, but not see each other. Room over Room is when you can see and travel from sector A to sector B through the floor or ceiling. Room Over Room support works just fine with the current system.

Does that mean TROR would work? SOS sort of go hand in hand in most of the original levels. Come to think of it though there is no real logical sense to have two rooms sharing the exact same physical space. At least not when attempting to map with realism. SOS almost seems like a bad practice and as long as the SOS were at different heights but still over lapping there wouldn't be a problem right? They would have to share the exact same physical space right? You can still have a room over a room but have them offset on the vertical Z axis and it wouldn't pose a problem? Or does it mean any SOS in general that is over lapping regardless of the vertical null space between the two sectors would be an issue?

[Mblackwell]

 Mark., on 25 May 2016 - 06:35 PM, said:

Then I guess I'm in the minority that would choose GI.

Then Decay and Graveyard wouldn't run.

[Hank]

 Mark., on 25 May 2016 - 06:35 PM, said:

Then I guess I'm in the minority that would choose GI.

Same here.

 Mblackwell, on 25 May 2016 - 06:39 PM, said:

Then Decay and Graveyard wouldn't run.

Why not? My understanding is that Room over Room would still work?

[Kyanos]

 icecoldduke, on 25 May 2016 - 06:21 PM, said:

Are you sure you want SOS over VXGI?

plz stop

[Mblackwell]

 Hank, on 25 May 2016 - 06:40 PM, said:

Same here.



Why not? My understanding is that Room over Room would still work?

Weird overlapping sectors and scissor/inversion tricks.

 icecoldduke, on 25 May 2016 - 06:21 PM, said:

Are you sure you want SOS over VXGI?

If I wanted to lose all of the features of BUILD I could just use UE4.

[icecoldduke]

 TerminX, on 25 May 2016 - 06:36 PM, said:

You absolutely cannot have a Build renderer that doesn't handle multiple sectors occupying the same "physical" space properly. It's nonsense. It's like saying "hey, let's make a renderer that doesn't even work with the original maps". Just stop. Accept that this is absolutely a required aspect of the engine and work it into your plan.

Out of the box I can definitely say it will load the old maps just fine. There will be a vis pass to handle SOS, this vis pass will more then likely be slower then whats in there now. How much slower, is TBD. Maybe this weekend we can flush out some ideas, and who knows maybe we will come up with something that is faster then the current vis pass. That would fantastic.

 Paul B, on 25 May 2016 - 06:37 PM, said:

Does that mean TROR would work? Also, as far as I'm concerned you can't have ROR without SOS they sort of go hand in hand.

TROR I guess is what I meant to say, I forgot there was TROR and ROR and different variations. Whatever technique Blood and Shadow Warrior use is supported, by the faster vis pass. The YAX_BUNCH code.

If you don't use SOS, you can get 60fps(with all or most effects enabled).
If you use SOS you will get around 30fps(with all or most effects enabled).

But as I said lets try to flush out some ideas I could have missed.

[Hank]

 Mblackwell, on 25 May 2016 - 06:44 PM, said:

Weird overlapping sectors and scissor/inversion tricks.

Would this also include my mirror spaces? Most occupy other used player space.
So I officially withdraw my previous post.

[added]
icecoldduke answered that below, and let's hope they'll find a solution.

[icecoldduke]

There would only be errors if another sector is physical occupying the space of another sector. The only other method i know of to make both cases run at 60 is to do a offline build pass. But again i want to try and flush out some ideas with tx and hendricks this weekend if there avalaible.

[oasiz]

Remember that there are a couple of worst case scenarios that might easily have more than 4-5 sectors overlapping the same "dimension".
SOS is a bit scary and there are a couple of maps that utilize oddities of the engine specifically to create stuff like transparent water that you can dive in to.
There definitely needs to be some reliable and fast way of detecting what is visible (and should be drawn) and what not.

IMO, it's better to assume that a map has SOS than not have, in most of the stock maps it's taken in to account by actually making putting the overlapping areas in to their own heights.
However, even in my maps I use a bunch of overlapping sectors to do helper things like audio emitting.
Theoretically a mod could make a map geometry transform in to something completely different or have 80 overlapping areas.
Check out Tier drops or Lunatic fringe for stress tests, stock maps as secret levels and push the concept of SOS.

While maps/mods like that don't fully exist yet out in the wild, I think stuff like that just beauty of the engine and one of the reasons why Duke is still being mapped on (and modded on, even unique games being made).
I'm all for creating a very optimized base game but d3d feature set in stock maps is pretty limited compared to what is actually possible.

Just noting that some of the "dirty decisions" really do enable crazy things not thought about before.
Compared to stock Doom/Quake and obvious graphical differences aside, I'd say that vanilla build had way more mileage technically due to not enforcing creative limitations over performance and designing around base game limits.
Limitations that ports removed later.

Anyway, Good job on getting things this far and I wish you good luck !
Watching this thread takes me back 10+ years when polymost/earlier duke ports were still being worked on

[Tea Monster]

 Mblackwell, on 25 May 2016 - 06:44 PM, said:

If I wanted to lose all of the features of BUILD I could just use UE4.

No you can't. Some dickhead at Gearbox's legal dept. will send you a C&D order, as the Cataclysm mod found out.

I'd love to use UE4. I would really love to. I wouldn't even mind too much using Source. It would solve so many problems.

Sadly, that is not an option because of how Gearbox view modding.

[Danukem]

 icecoldduke, on 25 May 2016 - 07:22 PM, said:

There would only be errors if another sector is physical occupying the space of another sector. The only other method i know of to make both cases run at 60 is to do a offline build pass. But again i want to try and flush out some ideas with tx and hendricks this weekend if there avalaible.

This sounds good, and I'm really looking forward to the new renderer and putting it to work with new content.

However, please, for the love of Duke, stop declaring that you are going to break existing features for the new renderer, especially features that have been an integral part of the game since it was released. Just don't do that. Please. If maps with SOS have a lower frame rate, then so be it.