Cap zone ring - #2119
Conversation
AdamTadeusz
added
the
Changes in neoAssets
AdamTadeusz
left a comment
AdamTadeusz
left a comment
There was a problem hiding this comment.
Minor nits, but the issue with transparency and smoke grenades needs to be resolved or, since it can't be resolved without some major changes to how rendering works or without major changes to how the boundary looks (and im unsure whether an opaque boundary is possible with CMeshBuilder since it seems to not want to draw depth), we need to come to an agreement wrt whether this issue is large enough to have a negative impact on gameplay
| m_pRingMaterial = materials->FindMaterial("effects/cap_zone_ring", TEXTURE_GROUP_CLIENT_EFFECTS); | ||
| m_pRingNsfMaterial = materials->FindMaterial("effects/cap_zone_ring_nsf", TEXTURE_GROUP_CLIENT_EFFECTS); | ||
| m_pRingJinraiMaterial = materials->FindMaterial("effects/cap_zone_ring_jinrai", TEXTURE_GROUP_CLIENT_EFFECTS); | ||
| AddToLeafSystem(RENDER_GROUP_TRANSLUCENT_ENTITY); |
| } | ||
|
|
||
| const Vector& playerOrigin = player->GetAbsOrigin(); | ||
| const float distanceToCap = playerOrigin.DistTo(capOrigin); |
There was a problem hiding this comment.
const float distanceToCap = max(0.f, playerOrigin.DistTo(capOrigin) - m_flCapzoneRadius);
So distanceToCap remains constant while inside the cap, and we don't get surprised by the cap suddenly appearing next to us when the cap radius is very large (or the boundary of the cap not appearing until we are already inside if the radius of the cap is greater than 768hu)
|
|
||
| RenderGroup_t CNEOGhostCapturePoint::GetRenderGroup() | ||
| { | ||
| return RENDER_GROUP_TRANSLUCENT_ENTITY; |
There was a problem hiding this comment.
The cap boundary being translucent is an issue given its size. Returning RENDER_GROUP_TRANSLUCENT_ENTITY means the cap boundary will be sorted against other translucents using the cap center as the origin leading to some funky behavior. The funkiest of behaviors lies in its interaction with smoke grenades. If a smoke grenade smoke particle emitter's origin is further from the camera than the center of the cap zone, it will render before the cap boundary, meaning parts of the boundary that are behind the smoke will still render on top. Because the boundary is translucent however, it will still render later than opaque models like non-cloaked players. This means you will be able to, in specific circumstances, spot players through smoke grenades using gaps in the cap boundary.
The only solutions as far as I can tell are:
- Make the boundary opaque. I was having trouble getting CMeshBuilder to write to the depth buffer so not sure if this is possible. Theoretically theres $alphatest with $alphatestreference and $allowalphatocoverage but that will still look not great unless players are using MSAA, and even then the fade out over distance will look bad, and again couldn't get this to work probably for the same reasons as a fully opaque CMeshBuilder.
- Draw the boundary in several steps. CClientLeafSystem::SortEntities determines the order in which translucent entities are drawn. If DrawModel took an argument and only drew the portion of the model specified by that argument, SortEntities could instead sort entity, argument pairs where the origin also depends on the argument. Anyway I'm bikeshedding here, this definitely shouldn't be done in this PR. What you could do maybe is create a clientside only entity that corresponds to a small section of the border. These would be connected to the cap entity in that deleting the cap would also delete all the smaller border entities, but they would exist separately in the clientleafsystem and would be sorted more thoroughly.
- Implement order independent transparency. Again bikeshedding here.
All in all its probably unrealistic for this pr to solve this issue, so we should instead consider how much impact it will have on the game, and whether its worth it.
There was a problem hiding this comment.
Upon further investigation I realized I forgot to remove the Sine material proxy that wrote to the material's alpha. With that commented out, it is indeed possible to use alphatest for a cap border that sorts correctly against translucent entities. The problem with this is the fading out of the cap over distance. Since we cannot change the alpha of the border smoothly with this (even with MSAA), the next be st solution might be to simply always render the cap border, and carefully edit the mipmaps so that at the lowest levels the texture is very unobtrusive
There was a problem hiding this comment.
Alternatively just always render the border, I don't think it's that obtrusive to begin with, and it will not render when outside the pvs anyway. Alphatest is much more performant that transparent, so this might even be better performance wise
There was a problem hiding this comment.
Thanks for testing and analysis, appreciated it
2 participants
Description
Visible border ring for cap zones to help players see the actual cap zone size. I tried to make it with a minimalistic design in mind to prevent problems with players' visibility in the cap zones.
Toolchain
Linked Issues
N/A
Linked PRs
assets - NeotokyoRebuild/neoAssets#133