Do you like new DOTF?

[MaceMadunusus]

Your exact wording, "ID Tech 3, which JKA is based off of, uses something called VIS" makes it sound as though it used a special system, when in fact, as you say now, every engine does this, which bore correcting.

VIS ie VISIBILITY encompasses the entire system from radiant structural brushes, portals, to leafs and nodes, to PVS, to how ingame determines to render the information based off of the PVS table and your location, and how that information is transmitted to rendering network side between servers and clients. Again, GENERALIZED term used by the compiler (IE what I use) that describes the entire system rather than a single part of it for the sake of simplicity when explaining to someone quickly on a forum, who wanted possibly clarification later on in discord. Especially when I linked an article that goes over the whole BSP, PVS, etc parts of the system if he wanted to look more in depth himself. But noooo you HAD to come and correct people, as usual.

You do realize that JKA does do view frustrum culling, right? So it still does do occlusion culling according to your odd definition of the term..

Last I checked your FOV, Height of camera, Tilt, etc wasn't taken into account when calculating things. So if it does do that, its the most basic form possible of it. Since shit renders off your screen (including dynamic non-baked, objects). Arguably difficult to call it view frustrum since the engine doesn't use half the information necessary. Since it only seemed to take into account the root position, and rotation. PVS itself shows this in that oh you're within this location, okay here is what is rendered. Sooooo, what is it about this view frustrum culling you're talking about? Pretty much everything is view frustrum culling by your definition. Sadly, that is not what it is regarded as by the industry.

Furthermore, the second sentence of the Wikipedia definition of PVS, which I linked before reads:

I literally said "PVS is a form of occlusion culling yes". You're not contradicting my statement at all. I merely said when people refer to occlusion culling nowadays, they don't refer to ancient methods like PVS. Again, simplification for the sake of talking to someone on the forum without going in depth, and you just coming in here to spout your "knowledge" for the sake of making yourself look better or knowledgeable.

It also does distance culling, which is a form of occlusion culling

No, Distance Culling is a form of Culling. Occlusion culling which is a type of culling needs an occluder of some sort. Whether that be an object, volume, whatever. Being based off of distance instead of a type of occluder makes it NOT occlusion culling.

I suggest you actually look up who you're talking about. Xycaleth, who is working on rend2, was working on driver code for video cards...

So you actually proved my point by saying this yet you don't realize it. Just because someone has knowledge of how graphics cards work and works on the drivers does not mean they have created a proper modern occlusion culling system from scratch for a game that has made it live and is tried and tested. Sure he could take time, use some things from another open source or one of his driver related projects, do some research, etc. to make something functioning. But that doesn't mean hes built the system from the bottom up and understands it in and out. You failed to list something he created a modern occlusion culling system for by himself or with a team (ie no copying/adapting of code from another project like the majority of rend 2).

Point is. Your response was unneeded for the point I was trying to get across. So yes you should shut up.

 

[eezstreet]

VIS ie VISIBILITY encompasses the entire system from radiant structural brushes, portals, to leafs and nodes, to PVS, to how ingame determines to render the information based off of the PVS table and your location, and how that information is transmitted to rendering network side between severs and clients. Again, GENERALIZED term used by the compiler (IE what I use) that describes the entire system rather than a single part of it for the sake of simplicity when explaining to someone quickly on a forum, who wanted possibly clarification later on in discord. Especially when I linked an article that goes over the whole BSP, PVS, etc parts of the system if he wanted to look more in depth himself. But noooo you HAD to come and correct people, as usual.

I literally said "PVS is a form of occlusion culling yes". You're not contradicting my statement at all. I merely said when people refer to occlusion culling nowadays, they don't refer to ancient methods like PVS. Again, simplification for the sake of talking to someone on the forum without going in depth, and you just coming in here to spout your "knowledge" for the sake of making yourself look better or knowledgeable.

Well of course! You said that the OpenJK team lacked knowledge. How could I not try to defend ourselves?

Last I checked your FOV, Height of camera, Tilt, etc wasn't taken into account when calculating things. So if it does do that, its the most basic form possible of it. Since shit renders off your screen (including dynamic non-baked, objects). Arguably difficult to call it view frustrum since the engine doesn't use half the information necessary. Since it only seemed to take into account the root position, and rotation. PVS itself shows this in that oh you're within this location, okay here is what is rendered. Sooooo, what is it about this view frustrum culling you're talking about? Pretty much everything is view frustrum culling by your definition. Sadly, that is not what it is regarded as by the industry.

Just judging based on the code, it does seem to take fov into account but I'm not sure what you mean by height/tilt? You mean Z coordinate and the camera pitch? It should also take that into account, based on the fact that it's using the viewaxis matrix which has both of those.

No, Distance Culling is a form of Culling. Occlusion culling which is a type of culling needs an occluder of some sort. Whether that be an object, volume, whatever. Being based off of distance instead of a type of occluder makes it NOT occlusion culling.

See, I baited you with this dumb statement because view frustrum culling isn't occlusion culling either. Because there's no occlusion there. And for a delicious twist of irony, some engines control distance culling with the frustrum culling, which makes your claim that "modern engines handle occlusion culling with view frustrum culling" especially silly. Unity, which is a modern engine that does this, explicitly states that view frustrum culling is not the same thing as occlusion culling. It was a bold risk on my part to make myself look stupid but it paid dividends!

So you actually proved my point by saying this yet you don't realize it. Just because someone has knowledge of how graphics cards work and works on the drivers does not mean they have created a proper modern occlusion culling system from scratch for a game that has made it live and is tried and tested. Sure he could take time, use some things from another open source or one of his driver related projects, do some research, etc. to make something functioning. But that doesn't mean hes built the system from the bottom up and understands it in and out. You failed to list something he created a modern occlusion culling system for by himself or with a team (ie no copying/adapting of code from another project like the majority of rend 2).

Point is. Your response was unneeded for the point I was trying to get across.

Your comment was that nobody knew what they were doing, and that major advancements were made by copy-pasting stuff from other sources. While it is true that a great deal of OpenJK's fixes were backported from ioquake3, it was better to investigate old fixes that we weren't aware of, instead of reinventing the wheel. The stuff that SomaZ and Xycaleth are doing with rend2 are very significantly different enough for me to warrant it calling it his own version. I would know, as I was the one who originally copied that code over to begin with.

No, we didn't include a modern occlusion culling system because in my professional opinion and the opinions of others, it isn't warranted. It's not due to lack of experience at all. Mappers have frequently struggled with the system, either due to the poorly explained guides, or because of issues upstream with the map compiler. By your own admission, most of your problems are with the map compiler, either with it not compiling the shaders into the geometry correctly, areaportals being wrong, etc, etc. As I've stated before, the main focus of OpenJK is on fixing JKA specific issues with the game, and focusing only on the game and any JKA specific tools, like ModView. Your issue is better taken up with the developers of GTKRadiant and/or q3map2. Or even better, you could take it up with the MB2 team, who still refuse to migrate to an OpenJK based engine and cling to JAMP. It's not going to be possible until you do that.

And barring that, I don't think the issue is necessarily to do with occlusion culling either, because polygon-per-polygon, JKA still renders at a dismal FPS. MB2 still has bad loading times and uses an absurd amount of RAM for what graphics you're getting. Those types of issues are what's killing the performance. Not because you can see a fair bit of polygons behind walls. I mean, that hurts, but no, the fact that there's sometimes multiple projectile EFX being rendered at once for some weapons, memory is being reallocated over and over for EFX, most of the polygon math is done on the CPU, nothing is done using batch OpenGL calls, saber blade effects use zillions of triangles, some models don't have LODs, the dynamic glow shader is horribly inefficient, over 100mb of .data segment memory is used just for animations, nothing (except BSP data) is deallocated when not in use, and some sabers are pushing 1k triangles...that's probably where the pipeline issues are going to be. I haven't even gotten into the utter chaos that is the configstrings and netcode, but that's a story for another time.

The point is, the majority of the issues with the engine are pretty unique issues for MB2, either because of the sheer vastness of content that wasn't ever anticipated, messy spaghetticode, or issues which go above and beyond the scope of OpenJK. Either you can adapt to the situation, or cling to JAMP and suffer issues. Either way, claiming that the issue is how bad the system of PVS is, when PVS is almost a perfect fit for the type of hallways and corridors that make up DOTF, is wrong.

 

[MaceMadunusus]

Well of course! You said that the OpenJK team lacked knowledge.

I also didn't say you couldn't look it up or figure it out. You yourself said it is out of your scope, therefore no reason to bother learning about it, therefore lacking knowledge.

Just judging based on the code, it does seem to take fov into account but I'm not sure what you mean by height/tilt? You mean Z coordinate and the camera pitch? It should also take that into account, based on the fact that it's using the viewaxis matrix which has both of those.

Just because the function exists doesn't mean it is used. Also, what is even the point of it being used with a PVS system in the first place? Since it renders or derenders chunks of the map entirely based off of which leaf you are in. In fact, looking at the code you linked I don't see anything actually using the function. I see it being loaded but not used. Especially by anything PVS related. It isn't referenced by sv_game or tr_world... etc. So just because something exists doesn't mean it is used or used in the way you say it is used. Again not a code wizard but it seriously doesn't look like its being used by the PVS components of the renderer to me. All I see the PVS components referencing is leafs, clusters, etc that you are in or are connected. The only thing I see it using from the view point currently is its origin. The only thing I can see the frustrum being used for in my quick search is culling dynamic lights.

See, I baited you with this dumb statement because view frustrum culling isn't occlusion culling either. !

Nah this is just a mistake I made when editing my post. I added the view frustrum stuff in after the fact a bit too quickly and didn't edit what was around it. Typed too fast so I guess you got me.

Your comment was that nobody knew what they were doing

When I have you, ensi, etc tell me that PVS works properly, the I literally have to show you it doesn't on like 4 separate occasions and still have you guys constantly saying I'm wrong then I literally prove it with screenshots forgive me for thinking you guys don't know what you're doing.

No, we didn't include a modern occlusion culling system because in my professional opinion and the opinions of others, it isn't warranted. It's not due to lack of experience at all.

So, you're not doing it, and no one has ever done it? Sounds like no experience to me, still haven't shown me something where someone from openjk made a good, reliable, occlusion culling system.

Your issue is better taken up with the developers of GTKRadiant and/or q3map2.

I never told the OpenJK guys to fix it? I merely said you guys didn't understand what was actually happening because you had no experience with it. And not knowing of those issues before I pointed it out proves that.

And barring that, I don't think the issue is necessarily to do with occlusion culling either, because polygon-per-polygon, JKA still renders at a dismal FPS.

You're not wrong there but I am again speaking within current limitations. Even if JKA/MB2 was properly optimized in all of its EFX, Models, Weapons, Loading, etc. It would still be much less performant to use a layout like the one suggested even if everything else was proper.

Either way, claiming that the issue is how bad the system of PVS is, when PVS is almost a perfect fit for the type of hallways and corridors that make up DOTF, is wrong.

Yes PVS being perfect is totally why shit appears through walls in leafs/nodes on the other side of the map. I'm sure you don't remember this image.

Where you could see the area circled in red through areaportaled doors if you were standing where purple was, but only if the yellow door with the purple dash was open. Even though the location was behind multiple doors, several leaf separation, behind multiple area portals, etc. Now I managed to fix that by modifying some of the surrounding structural brushes. So it is possible that it is the fault of the compiler but that is far from a certainty and far easier to lump it into the entire visibility system.

This is PVS being perfect:

Notice how the area portaled door in the upper area isn't open and the area behind that door isnt rendered. Part of that corner of throne isn't rendered until you get to that spot. And this all only works if the door is open. Door is open, and you stand in that one spot, you can see that back corner of throne. Working properly? I think not.

This is what I have to deal with. And I am tired of people telling me JKA's PVS system works for DOTF like maps. They don't because they're far too complicated for it to support.

 

[eezstreet]

Just because the function exists doesn't mean it is used. Also, what is even the point of it being used with a PVS system in the first place? Since it renders or derenders chunks of the map entirely based off of which leaf you are in. In fact, looking at the code you linked I don't see anything actually using the function. I see it being loaded but not used. Especially by anything PVS related. It isn't referenced by sv_game or tr_world... etc. So just because something exists doesn't mean it is used or used in the way you say it is used. Again not a code wizard but it seriously doesn't look like its being used by the PVS components of the renderer to me. All I see the PVS components referencing is leafs, clusters, etc that you are in or are connected. The only thing I see it using from the view point currently is its origin. The only thing I can see the frustrum being used for in my quick search is culling dynamic lights.

It's probably because it's spelled frustum and not frustrum. I've made that mistake as well.
The frustum is set up R_RenderView, which is called every frame.
The frustum is then referenced in R_CullLocalBox to determine what should be culled.
Finally, any trisurf which is CULL_OUT (as in, all verts were outside of the frustum) is not drawn. There's lots of code that reference R_CullLocalBox, but here it is for bmodels and patches.
I apparently modified code related to this in the SP code, because a comment that I made is there. It uses 5 planes in JKA for the view frustum and 4 in JK2.
The point of it is to not render things which are behind the player or that the camera otherwise can't see. It's done before the occlusion culling, like Wikipedia outlines.

When I have you, ensi, etc tell me that PVS works properly, the I literally have to show you it doesn't on like 4 separate occasions and still have you guys constantly saying I'm wrong then I literally prove it with screenshots forgive me for thinking you guys don't know what you're doing.

On a theoretical basis, PVS is a perfectly good system for this type of thing. It's why John Carmack chose to use it with Doom and continued using it with Quake. Whatever issues exist are purely an implementation issue, since even Unity and Unreal 4 use it on a low level from what I've been told.

So, you're not doing it, and no one has ever done it? Sounds like no experience to me, still haven't shown me something where someone from openjk made a good, reliable, occlusion culling system.

Nobody has ever recoded the system because it's kind of a waste of time compared to the other obviously broken stuff which I've listed above. I can't actually think of a single Quake3 based game that's changed the PVS/visibility system in a meaningful way. Maybe some of the later/newer Call of Duty games? MoHAA still uses BSP despite being a lot of open terrain. I also can't speak for whether or not any of the other devs have actually done any PVS related stuff, as their work often has some tight NDAs involved with them.

I never told the OpenJK guys to fix it? I merely said you guys didn't understand what was actually happening because you had no experience with it. And not knowing of those issues before I pointed it out proves that.

Sorry, misunderstanding I guess.

You're not wrong there but I am again speaking within current limitations. Even if JKA/MB2 was properly optimized in all of its EFX, Models, Weapons, Loading, etc. It would still be much less performant to use a layout like the one suggested even if everything else was proper.

Maybe. It kinda depends on the benchmark. If you're spending 1ms to cull out polygons that would've otherwise taken 0.5ms to render, it might actually be faster. On paper you are right though.

Yes PVS being perfect is totally why shit appears through walls in leafs/nodes on the other side of the map. I'm sure you don't remember this image.

Where you could see the area circled in red through areaportaled doors if you were standing where purple was, but only if the yellow door with the purple dash was open. Even though the location was behind multiple doors, several leaf separation, behind multiple area portals, etc. Now I managed to fix that by modifying some of the surrounding structural brushes. So it is possible that it is the fault of the compiler but that is far from a certainty and far easier to lump it into the entire visibility system.

This is PVS being perfect:

Notice how the area portaled door in the upper area isn't open and the area behind that door isnt rendered. Part of that corner of throne isn't rendered until you get to that spot. And this all only works if the door is open. Door is open, and you stand in that one spot, you can see that back corner of throne. Working properly? I think not.

This is what I have to deal with. And I am tired of people telling me JKA's PVS system works for DOTF like maps. They don't because they're far too complicated for it to support.

I can't really diagnose exactly why that happens. Could be that you've made a mistake, could be a bug with q3map2, could be anything really. But I'm telling you that in theory, BSP is perfectly suited for hallways and interior spaces. Could you spruce up the system with modern methods? Absolutely. I actually think Theed is a better example case, or anything with lots of trees in a valley. How do you prevent wallhacks in that scenario? You can't, really.

 

[MaceMadunusus]

It's probably because it's spelled frustum and not frustrum. I've made that mistake as well.
The frustum is set up R_RenderView, which is called every frame.
The frustum is then referenced in R_CullLocalBox to determine what should be culled.
Finally, any trisurf which is CULL_OUT (as in, all verts were outside of the frustum) is not drawn. There's lots of code that reference R_CullLocalBox, but here it is for bmodels and patches.

I typed it correctly in the search because I copy pasted it from the function itself. I saw that function as well. The rest of the PVS ones I searched though just used the origin but I guess the order of operations is a bit off here since I am not sure the order and looks like I misunderstood that function a bit.

On a theoretical basis, PVS is a perfectly good system for this type of thing. It's why John Carmack chose to use it with Doom and continued using it with Quake. Whatever issues exist are purely an implementation issue, since even Unity and Unreal 4 use it on a low level from what I've been told.

Yeah, PVS is a good system that works for anything of the complexity of doom or quake. It is actually really great for that. Just starts sucking when you get to higher complexities with multiple things overlapping. Many MB2 levels have passed that complexity though. The levels for JKG weren't anywhere near as intertwined as MB2 ones and in general worked fine. I am definitely not saying PVS is a bad system. Just JKA/ID Tech 3s implementation is flawed for when level complexity gets higher. Might be a compiler thing, but area portals start bugging out at around 16 for example. Which makes large maps fairly difficult. It is weird because you can be working on a level, having a particular door be perfect for months and months. Then you add one area portal elsewhere in the map and it breaks. There are many times for example where I also try to control the portal set up for these higher complexities and it just ignores me (You can see this in the portal view for dotf near the throne room... Literally trying to fight it to create the leafs I want to).

I can't actually think of a single Quake3 based game that's changed the PVS/visibility system in a meaningful way. Maybe some of the later/newer Call of Duty games?

I used call of duty versions of radiant for a few months at one point. Never released what I worked on but it definitely felt modified. Could have just been compiler side but it definitely didn't do a few of the weird things JKAs does. It wasn't perfect but it felt better. I was able to build a lot of diagonal buildings and whatnot without it completely freaking out on me.

Maybe. It kinda depends on the benchmark. If you're spending 1ms to cull out polygons that would've otherwise taken 0.5ms to render, it might actually be faster. On paper you are right though.

Yes that is absolutely true but we know in JKAs case that the culling of things is much faster than the rendering of things.

I can't really diagnose exactly why that happens. Could be that you've made a mistake, could be a bug with q3map2, could be anything really. But I'm telling you that in theory, BSP is perfectly suited for hallways and interior spaces. Could you spruce up the system with modern methods? Absolutely. I actually think Theed is a better example case, or anything with lots of trees in a valley. How do you prevent wallhacks in that scenario? You can't, really.

Again, I do agree that BSP and PVS is a good system. I'm not saying it isn't. It is very less performance intensive than more modern occlusion culling techniques and as a result is highly beneficial for lower end hardware, or lower detail games where the cost of Just saying there is something wrong with the implementation. Whether the issues arise from Q3map2, ID Tech3, or something raven potentially did with JKA, or whatever. I don't have the time or resources to figure out where exactly the problem lies and I just lump it all together. It is just very error prone for how simple of a system it is.

This is how I fixed the issue with the purple dot and red circle: https://i.gyazo.com/64025e5eadd9f2000668193b1cd6bfb8.mp4. While in a way it does make sense it did that because of the brush touching 4 leafs it still really shouldn't have done that when the next one over touches two and there are no issues with it viewing areas that aren't touching the cluster you are currently I really don't see how a structural brush touching the 4 leafs would cause the fourth to be visible (when only 3 should be visible with that door open). You could argue I built the structural brushes incorrectly here but it really shouldn't be that sensitive and causes a lot of frustration for simple oversights wasting hours of time across a level for little issues like this. Usually oversights like this happen on maps where I am constantly changing the layout or modifying things. Where something changes and I miss changing some thing old, the it fucks up visibility, and I have to spend a while trying to figure out what I missed.

Whatever issues exist are purely an implementation issue, since even Unity and Unreal 4 use it on a low level from what I've been told.

Not sure about Unity but UE4 doesn't use PVS. It uses Precomputed Visibility Volumes (PVV) which are created by the level designer that are then processed by the compiler to create Precomputed Visibility Cells (PVC) that are generated based off of level geometry in the determined playable area. Looks something like this:

Quite a bit different from PVS in terms of implementation/functionality but on a basic level they're pretty much the same idea. PVV/PVC is much less error prone as far as I can tell.

 

[President Bossk]

You guys are having a nerd war. My brain hurts.....

 

[Blazer]

I think obj really needs a change. Maybe just keep the king of the hill, but change it somehow.

I've played dotf enough and half the time not even half of the imperial team is dead and some speed jedi or sneaky jedi just runs up into obj and takes it before anyone even knows what happened. The old dotf had a console you had to destroy to get inside throne.

 

[MaceMadunusus]

I've played dotf enough and half the time not even half of the imperial team is dead and some speed jedi or sneaky jedi just runs up into obj and takes it before anyone even knows what happened. The old dotf had a console you had to destroy to get inside throne.

They're out of position, have bad communication, or bad game sense. Notice how basically no other map has this time gate feature including in other games like overwatch or cs:go. It is a bad mechanic and you are relying on a crutch in order to win rather than properly strategizing or communicating with your team.

 

[Subaru]

That was still doable in old dotf, by going through the window (or sending a sneaky clone squad).

 

[Chaos the Chaotic]

You should have kept the catwalk in Dotf but with destructible supports. Similar to what you did in Republic_Cruiser but at a greater height with all that entails. Falling to your death, dmg, crushing those underneath, etc. 3 destructive support beams that must be destroyed by blaster, saber, rocket or nade.

The best of both lulz.

 

[jango40]

You should have kept the catwalk in Dotf but with destructible supports. Similar to what you did in Republic_Cruiser but at a greater height with all that entails. Falling to your death, dmg, crushing those underneath, etc. 3 destructive support beams that must be destroyed by blaster, saber, rocket or nade.

The best of both lulz.

That... seems like a simple but excellent idea. It'd probably create performance problems though?

 

[MaceMadunusus]

That was option #1 I was talking about earlier that I decided to not use in favor of option number 2.

 

[President Bossk]

You should have kept the catwalk in Dotf but with destructible supports. Similar to what you did in Republic_Cruiser but at a greater height with all that entails. Falling to your death, dmg, crushing those underneath, etc. 3 destructive support beams that must be destroyed by blaster, saber, rocket or nade.

The best of both lulz.

I think that is the first non-troll comment I have ever heard you make.

That was option #1 I was talking about earlier that I decided to not use in favor of option number 2.

I like it, I think map would be significantly better with and more enjoyable with this. Feels a little bland for whatever reason right now.

 

[anomer]

Sith or Jedi jumping on the catwalk had to use majority of their FP. Here the ships are easily accessible by mandos and force users, while being impossible to climb by other classes (based on the screenshot). It seems like it could be easily abused by Imps that breached the Hangar. (I know that scenario is usually lost cause in competitive games, but majority of matches is open pub which is more... random). I guess having few sets of boxes and maybe some 'repair ramp' could provide needed access on top of Nubian for infantry. Don't know about fighters.

Overall the ships look good but I like the idea of destructible catwalk too.

Btw. in gen, current elevators are slow and clunky which makes it even harder for non-mobile classes to fight there. What do you think about Planetside 2 style elevators (2 way, levitating)? They would be perfect for gen. Is there something in JKA / MB2 content that already provides similar functionality? If not, how would you estimate difficulty of implementing that system?

 

[MaceMadunusus]

Sith or Jedi jumping on the catwalk had to use majority of their FP. Here the ships are easily accessible by mandos and force users, while being impossible to climb by other classes (based on the screenshot).

Yes there will be other ways up. I literally just added the ship right before I took the screenshot. Hence why it is an editor screenshot

Is there something in JKA / MB2 content that already provides similar functionality?

Not currently. There is a trigger you can push people with but it is not exactly how planetside handles and would need tweaks to work properly. Not sure how difficult it would be to implement. But we have also not seen that type of elevator used in SW either.

 

[Chaos the Chaotic]

If you're adding ships....you know, there was this scene in the movie where some little kid gets into a fighter and spawn kills a bunch of droids.
Just food for thought.

I think that is the first non-troll comment I have ever heard you make.

I'm before your time, boy. I used to submit quite a large number of ideas back in my heyday of irreverence.
And they were even more glorious than you could possibly ever imagine!

I'm the reason Jabba is fat!

 

[anomer]

But we have also not seen that type of elevator used in SW either.

Good point. Though with artificial gravity in spaceships that tech should be theoretically possible in the setting. I also vaguely recalled containment fields working like that, but after investigation, they are just magnets. Containment field

 

[Penekowski]

Having a ship there would look awesome, sure. I can already see cancerous jedi/sith wasting time there like on the ds falcon coming from a mile away. But hey, a long as rocket arc troopers can make their come back on dotf then I'm all for it (they are rare nowadays)

 

[MaceMadunusus]

Not much different from catwalk, but gunners will be able to get up there more reliably than catwalk and DS.