[TerminX]

The only reason the def parsing is as fast as it is is because I set it up to use a hash table so that most of that string comparing doesn't have to happen... we're not fucking retarded here.

Currently xscale and yscale values for textures can not change at runtime.

[Hendricks266]

icecoldduke, on 23 May 2016 - 07:36 PM, said:

Can these mod values change at runtime?

Currently no. In the future I would like to look at making all content modifiable from Lua, but that is so far off, it is not something we need to be concerned about now.

[icecoldduke]

TerminX, on 23 May 2016 - 07:39 PM, said:

The only reason the def parsing is as fast as it is is because I set it up to use a hash table so that most of that string comparing doesn't have to happen... we're not fucking retarded here.

Currently xscale and yscale values for textures can not change at runtime.

Never said you were . The def parsing in eduke32 isn't bad in terms of performance, but I don't know how well it would scale when more content gets added in. In general I have a strong disdain for text formats. There is no reason why one would have to process a format during runtime, everything should be saved out in something that can be read directly into memory.

Anyway I'm off my soap box, I'll handle that stuff during the geo generation pass.

[Hendricks266]

What if you want to add a new token?

[icecoldduke]

Hendricks266, on 23 May 2016 - 08:23 PM, said:

What if you want to add a new token?

In the cases were you need to add data that breaks the current format, you have code that can read in the old data and convert it to the new format. If you still don't like that, you can always have text files that only get used within the editor, then when you switch over to the game it only reads binary, memory ready data.

[TON]

Why in the video the textures of occluded surfaces load late when the camera looks to those surfaces?

[icecoldduke]

TON, on 24 May 2016 - 08:25 AM, said:

Why in the video the textures of occluded surfaces load late when the camera looks to those surfaces?

Not sure yet, I have to debug through it to figure it out . Initial guess it might have to do with the frustum of the vis pass not being wide enough, mixed with fact the vis data for the current frame is from the last frame.

[icecoldduke]

So I found some other sync points on the GPU that I fixed, and I decided to do a side by side with PolymerNG on the PC vs latest EDuke32 Polymer both running CLCoast side by side. I am currently running a i7 3.4ghz 32gb DDR 4 with a NVIDIA 970 GTX 4gb.

PolymerNG runs CLCoast at 5-7ms(over 100fps), Polymer runs at between 28-32 ms(around 30-38fps). PolymerNG is currently CPU bound in this map, the GPU is only taking 4ms to render this frame.



So with this in mind, I'm trying to figure out how to deal with the SOS issue, and the best answer right now is...to not do it. Is it possible to go in and fix the old maps to not have SOS? Is it possible to avoid doing SOS(ROR is ok). I haven't decided on anything yet, but I really like being able to send down all the data for the map at once during the vis pass. This is a huge performance boost. I'm not sure yet how I can do the same thing if I have to deal with portals and such.

Any ideas anyone?

[Hendricks266]

icecoldduke, on 25 May 2016 - 02:59 PM, said:

So with this in mind, I'm trying to figure out how to deal with the SOS issue, and the best answer right now is...to not do it. Is this possible to go in and do fix the old maps to not do SOS?

[TerminX]

icecoldduke, on 25 May 2016 - 02:59 PM, said:

So with this in mind, I'm trying to figure out how to deal with the SOS issue, and the best answer right now is...to not do it. Is this possible to go in and do fix the old maps to not do SOS? Is it possible to avoid doing SOS(ROR is ok). I haven't decided on anything yet, but I really like being able to send down all the data for the map at once during the vis pass. This is a huge performance boost. I'm not sure yet how I can do the same thing if I have to deal with portals and such.

Any ideas anyone?

Are you fucking kidding me? This is Build; you have to deal with portals. It's kind of amazing to me that you have all of this technical skill, but you have no idea how to correctly hook it up/apply it to this engine.

Seriously, that's the dumbest thing I've ever heard you say. You should get with me on Skype so we can talk frequently and I can help you do this right.

Don't get upset about this post, accept the criticism and get in touch with me ASAP before you waste time on shit that isn't going to work.

[icecoldduke]

Hendricks266, on 25 May 2016 - 03:10 PM, said:

...

Oh I know your not going to like it , but imo its worth having this discussion. The fact is the vis pass as it stands now runs REALLY fast, clcoast at 100fps. I would like to keep that performance. That being said I'm open to ideas. I could doing fancy portal magic that would involve doing a branch during the vis shaders pass that could, in theory, cull out encroaching sectors. The problem with this is, its the best idea I have right now. Branches kill GPU parrelization. which hurts performance.

So my question still stands, can you guys make maps and not do SOS. Don't confuse SOS with ROR, ROR will work just fine.

TerminX, on 25 May 2016 - 03:13 PM, said:

Are you fucking kidding me? This is Build; you have to deal with portals. It's kind of amazing to me that you have all of this technical skill, but you have no idea how to correctly hook it up/apply it to this engine.

Seriously, that's the dumbest thing I've ever heard you say. You should get with me on Skype so we can talk frequently and I can help you do this right.

Don't get upset about this post, accept the criticism and get in touch with me ASAP before you waste time on shit that isn't going to work.

I would love to get on skype with you, i'll send you my info.

[TerminX]

No, nobody is going to alter every map that has different sectors that exist in the same space. Are you high or something dude?

[Mblackwell]

The fact that geometry doesn't have to conform to anything is why people like BUILD and most maps take advantage of it to create otherwise impossible situations. That's why you should always use the portal data first and cull based on that, and even within that you'll sometimes have to throw out your results and just render everything or you'll waste system time.

[TerminX]

IMO the answer is to follow the portals in the very beginning of the rendering pipeline... use it to your advantage straight off and only feed the GPU sectors and walls that you've determined are visible via the portals.

[icecoldduke]

TerminX, on 25 May 2016 - 03:19 PM, said:

IMO the answer is to follow the portals in the very beginning of the rendering pipeline... use it to your advantage straight off and only feed the GPU sectors and walls that you've determined are visible via the portals.

The issue with that approach is you become draw call bound, and thats kill GPU parralization. It's actually cheaper to give the GPU more work all at once then it is to piece meal it over a bunch of smaller draw calls. I have thought about building a sector list, based on portals, and uploading all of those indexes to a index buffer every frame. I haven't tried this yet, but that would require a GPU sync that I want to avoid, double buffering might solve that issue, but I don't know yet.

Right now the 2-3ms of the total GPU time I currently have is because I am rendering each plane individually during the albedo pass. I can do a couple things to fix this, but probably the best idea I have so far is the dynamic index buffer, so I can submit them all the planes at once. I don't want to use this technique twice, which is why I'm asking about SOS.

[Hendricks266]

If you want to be able to claim your renderer works with Build or that Duke 3D is playable with it (Tier Drops, Lunatic Fringe), that's the kind of approach that you'll have to take. By all means try and batch geometry as much as possible, but you can't send all of it to the GPU at once.

[icecoldduke]

Hendricks266, on 25 May 2016 - 03:25 PM, said:

If you want to be able to claim your renderer works with Build or that Duke 3D is playable with it (Tier Drops, Lunatic Fringe), that's the kind of approach that you'll have to take. By all means try and batch geometry as much as possible, but you can't send all of it to the GPU at once.

I want this to be known, I'm not setting my mind to anything. I'm asking here so maybe we can flush out something I haven't thought of.

That being said, the fact I can't send all the data down during the vis pass to the GPU is a huge problem.

So I would like to know, what are the use cases for SOS? I would like to know in what situations SOS is being used.

[Mblackwell]

In Vulkan there's no serialization and you can send millions of draw calls and still maintain fps since there's no lock and no driver overhead.



Just throwing that out there.

Anyway, you shouldn't suddenly get a huge spike unless you're spending too much time working out what shouldn't be drawn. Drawing everything always would probably get you 33ms total render time.

[Mblackwell]

icecoldduke, on 25 May 2016 - 03:32 PM, said:

I want this to be known, I'm not setting my mind to anything. I'm asking here so maybe we can flush out something I haven't thought of.

That being said, the fact I can't send all the data down during the vis pass to the GPU is a huge problem.

So I would like to know, what are the use cases for SOS? I would like to know in what situations SOS is being used.

Mirrors, rooms that didn't quite fit where they wanted, saving grid space, creating disorienting transitions between rooms, creating two overlapping variations of the same room, sliding doors and other misc sector effects, inverting sector boundaries in order to simulate TROR before it existed, and lots more!

[icecoldduke]

Mblackwell, on 25 May 2016 - 03:38 PM, said:

In Vulkan there's no serialization and you can send millions of draw calls and still maintain fps since there's no lock and no driver overhead.

Just throwing that out there.

Anyway, you shouldn't suddenly get a huge spike unless you're spending too much time working out what shouldn't be drawn. Drawing everything always would probably get you 33ms total render time.

The trick is I'm rendering everything to a buffer that's 274x154. The render target is a single channel 16 bit integer, and the depth buffer is a 24bit with 8 bit stencil(I can cut this down). The vis pass in clcoast I think is 1.5ms, that includes the readback. The rest is the albedo pass, and that's because I'm not batching that up at all.

I'm not convinced that the overhead from the draw calls is the problem. I think it has to do with lack of wavefront parrelization, because you have a whole bunch of different draw calls. When I tried implementing portals during the vis pass, I wasn't CPU bound, I was clearly GPU bound(+15 ms), so I'm not sure Vulkan can help this situation.

Mblackwell, on 25 May 2016 - 03:43 PM, said:

Mirrors, rooms that didn't quite fit where they wanted, saving grid space, creating disorienting transitions between rooms, creating two overlapping variations of the same room, sliding doors and other misc sector effects, inverting sector boundaries in order to simulate TROR before it existed, and lots more!

The trick for mirrors in build, were you have to put that stupid sector behind the mirror, that seems like that could be something that doesn't have to be done in a next gen renderer. Just have a material that marks that texutre as a mirror and be done with it.

If you run out of grid space, if you had no load times, you could put the owerflow into another map...

I would like to see a example of "creating disorienting transitions between rooms".

"creating two overlapping variations of the same room" Why would this need SOS?

"sliding doors" if you could use models instead of sectors for sliding doors, would that solve that issue?

Again I'm just getting a feel for what you guys need SOS for. If I come up with a solution, that doesn't involve removing support for it, I need to know exactly what you guys are doing.

Worst case if I switch to a "slower" vis pass when I detect SOS, would that solve the issue? You would get a decent performance hit, but you would get SOS.

[MusicallyInspired]

Sometimes I think you actually challenge yourself to see how far you can tick Hendricks266 off lol. Or TX at all (you succeeded!). You don't remove a staple feature of the engine for performance gain. It's not all about performance. I'll take the performance hit every time over castrating the engine and orphaning countless maps. Have you even played through the game? SOS is crucial to not only fanmade maps but the vanilla episodes! And not only in a couple isolated instances.

[icecoldduke]

MusicallyInspired, on 25 May 2016 - 03:59 PM, said:

Sometimes I think you actually challenge yourself to see how far you can tick Hendricks266 off lol. Or TX at all (you succeeded!). You don't remove a staple feature of the engine for performance gain. It's not all about performance. I'll take the performance hit every time over castrating the engine and orphaning countless maps. Have you even played through the game? SOS is crucial to not only fanmade maps but the vanilla episodes! And not only in a couple isolated instances.

As I said, I think the best option is not to remove the feature, but instead fall back to the slower vis pass when I detect SOS. This way I don't break old maps. If you as content developers want to maximize performance, then don't do SOS.

[MusicallyInspired]

What about people who make maps primarily in 8-bit but there are people who want to play them in PolymerNG? You're segregating your renderer. People aren't going to design for it if you go down this road. If your response to that is "dem's the breaks, move on", well....you just have no respect for the community.

[Mblackwell]

What we are doing are everything done in vanilla Duke and then some.

Sliding doors and the like all have specific hard coded reactions/interactions including with themselves, child sectors, and they can even bump into other sliding door sectors and cause them to trigger. They can be arbitrary shapes and sizes, and they are used frequently along with oddly configured split doors in usermaps.

For the things people want to do in build, there is no better way. And if you avoid the things that make the engine unique you should use a different engine.

[icecoldduke]

MusicallyInspired, on 25 May 2016 - 04:03 PM, said:

What about people who make maps primarily in 8-bit but there are people who want to play them in PolymerNG? You're segregating your renderer. People aren't going to design for it if you go down this road. If your response to that is "dem's the breaks, move on", well....you just have no respect for the community.

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

What we are doing are everything done in vanilla Duke and then some.

Sliding doors and the like all have specific hard coded reactions/interactions including with themselves, child sectors, and they can even bump into other sliding door sectors and cause them to trigger. They can be arbitrary shapes and sizes, and they are used frequently along with oddly configured split doors in usermaps.

Alright then we need to come up something, I'm open to ideas. Here's a idea: I can maybe use a compute shader to do the portal culling, and use that to build the vis list. I'm not sure off hand if compute shaders are supported on dx 10 hardware, and I'm not sure how many compute units lower end has off hand. Let me check.

[MusicallyInspired]

Quote

I would like to see a example of "creating disorienting transitions between rooms".

I recall a map where there was this circular hallway that goes around in a circle (actually, cube-shaped, not rounded, but you get the idea) with the illusion of a very small post in the center, but as you walked around it the walls and lighting would change and you'd be walking around in circles in the same spot but the environment keeps changing until you reach the exit. I....can't describe it any better than that.

[icecoldduke]

Alright so it looks like a viable path might be to do the portal work on the GPU with a compute shader(yay! found a use for compute shaders). So put down your pitch forks, let me go back to the lab, and see if I can come up with something .

You guys are angry group of people .

[TerminX]

icecoldduke, on 25 May 2016 - 04:02 PM, said:

As I said, I think the best option is not to remove the feature, but instead fall back to the slower vis pass when I detect SOS. This way I don't break old maps. If you as content developers want to maximize performance, then don't do SOS.

That's lame. That kind of impossible architecture is a hallmark feature of Build--the very fact that it's portal based and that the map is completely dynamic is pretty much the whole point behind even using Build for anything at this point.

Would it be possible to use the portals to create a table of what is and isn't visible during a particular frame and refer to it when drawing? Then you can just update the table every frame instead of having to change the actual geometry.

[icecoldduke]

TerminX, on 25 May 2016 - 04:17 PM, said:

That's lame. That kind of impossible architecture is a hallmark feature of Build--the very fact that it's portal based and that the map is completely dynamic is pretty much the whole point behind even using Build for anything at this point.

Would it be possible to use the portals to create a table of what is and isn't visible during a particular frame and refer to it when drawing? Then you can just update the table every frame instead of having to change the actual geometry.

I think one of hallmark features in build is, you can legally make Duke content in it without getting sued . It's possible, let me think about this and get back to you.

[Mblackwell]

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