grayman 2968 Posted October 25, 2018 Report Share Posted October 25, 2018 No. It'll fall through the cracks if it isn't posted in bugtracker. Edit: You can always get someone else to file the issue. Just have them attach your test map and include a link back to the beginning of this thread. You're in luck. The problem already appears in bugtracker. Perhaps someone can attach your test map to that issue and add the link back to this thread. Quote Link to post Share on other sites
Skaruts 65 Posted October 25, 2018 Report Share Posted October 25, 2018 I just recreated the staircase, and found it actually somewhat easy to get the same problem, and I think it's related to excessive geometry cuts, although probably still caused by a bug. As I made the walls longer/shorter I got different results (or no bad results in some cases), one time it affected the wall where some tris had different lighting, another time the wall had a black triangle, and then I got the exact same problem as the OP, in the staircase itself.All the problems with walls could be solved by making the staircase into a func_static, but the last one couldn't. The way I solved that one this case, that you might want to try, was by using rich_is_bored's 3rd setup (with a slight difference, but may be irrelevant -- see in spoiler below), and by making three func_statics out of it:- one for all the boards- one for both the big ramp and the big block- one for all the leftover triangle-steps below the boards. 1 Quote Link to post Share on other sites
Zen3001 8 Posted October 25, 2018 Author Report Share Posted October 25, 2018 here's the map file, don't know how to attach it to the report myselffstmp.map.txt Quote Link to post Share on other sites
Abusimplea 168 Posted October 26, 2018 Report Share Posted October 26, 2018 here's the map file, don't know how to attach it to the report myselfAttached the map to the bug. Quote Link to post Share on other sites
Zen3001 8 Posted October 26, 2018 Author Report Share Posted October 26, 2018 I just recreated the staircase, and found it actually somewhat easy to get the same problem, and I think it's related to excessive geometry cuts, although probably still caused by a bug. As I made the walls longer/shorter I got different results (or no bad results in some cases), one time it affected the wall where some tris had different lighting, another time the wall had a black triangle, and then I got the exact same problem as the OP, in the staircase itself. All the problems with walls could be solved by making the staircase into a func_static, but the last one couldn't. The way I solved that one this case, that you might want to try, was by using rich_is_bored's 3rd setup (with a slight difference, but may be irrelevant -- see in spoiler below), and by making three func_statics out of it:- one for all the boards- one for both the big ramp and the big block- one for all the leftover triangle-steps below the boards. Yup, that helped 1 Quote Link to post Share on other sites
Skaruts 65 Posted October 26, 2018 Report Share Posted October 26, 2018 (edited) Just for the record, maybe the other setups work too, I only tried that one. The reasoning was just that separating each part of the staircase in its own func_static that makes the engine calculate their geometry separately, making it cleaner and without each part interfering with each other (or the walls/floors). Since excessive geometry seemed to be the problem, I though that would be the way to go. Though, as far as I know, and someone correct me if I'm wrong, anything that isn't sealing geometry should always be func_static anyway. Edited October 26, 2018 by Skaruts Quote Link to post Share on other sites
HMart 319 Posted October 27, 2018 Report Share Posted October 27, 2018 (edited) Just for the record, maybe the other setups work too, I only tried that one. The reasoning was just that separating each part of the staircase in its own func_static that makes the engine calculate their geometry separately, making it cleaner and without each part interfering with each other (or the walls/floors). Since excessive geometry seemed to be the problem, I though that would be the way to go. Though, as far as I know, and someone correct me if I'm wrong, anything that isn't sealing geometry should always be func_static anyway. Not necessarily, func_statics should be used only for static models (to save performance), any model that moves should be a func_mover (controlled through scripts) or a idMoveable (defined in def files, is a rigid body physics enabled object), you also need to know that AI path calculation (AAS) only works on world brushes, AI walks fine on func_static floor but you need to put a brush under it, btw no need for the AI to touch the brush, so you can have a func_static floor and a brush under it some units down and it still works fine. Edited October 27, 2018 by HMart 1 Quote Link to post Share on other sites
duzenko 654 Posted October 27, 2018 Report Share Posted October 27, 2018 What is the smallest simplest repro case? Can you get it break with just an empty room and a staircase? Quote Link to post Share on other sites
Skaruts 65 Posted October 27, 2018 Report Share Posted October 27, 2018 (edited) What is the smallest simplest repro case? Can you get it break with just an empty room and a staircase?That's how I managed to. In a 256x256 room (128 high). There's two sets of stairs in the map, to the left of player start is the one I managed to fix before, and to the right is the original one with the problem. stairs.map.txt EDIT: I just made it solid 0 and looked at it from the inside, and doesn't seem like there's any faces facing inward. Someone mentioned this before, and I was wondering. Edited October 27, 2018 by Skaruts Quote Link to post Share on other sites
Destined 615 Posted October 27, 2018 Report Share Posted October 27, 2018 Though, as far as I know, and someone correct me if I'm wrong, anything that isn't sealing geometry should always be func_static anyway. Not necessarily, func_statics should be used only for static models (to save performance), any model that moves should be a func_mover (controlled through scripts) or a idMoveable (defined in def files, is a rigid body physics enabled object), you also need to know that AI path calculation (AAS) only works on world brushes, AI walks fine on func_static floor but you need to put a brush under it, btw no need for the AI to touch the brush, so you can have a func_static floor and a brush under it some units down and it still works fine. This is especially important for stairs, as these also need a working AAS area. So, this case is one, where leaving the stairs as a brush would actually be helpful as you don't need to add an additional monster clip for AI to use it (if it works without the rendering error, of course). Quote Link to post Share on other sites
Skaruts 65 Posted October 27, 2018 Report Share Posted October 27, 2018 Can't the unnecessary geometry become a bit of an issue, though, in dmap times or at runtime? Especially if stairs are detailed? Quote Link to post Share on other sites
duzenko 654 Posted October 27, 2018 Report Share Posted October 27, 2018 This looks like a bug in dmap logic Does the dmap noopt yourmap fix the gap? Quote Link to post Share on other sites
Skaruts 65 Posted October 27, 2018 Report Share Posted October 27, 2018 This looks like a bug in dmap logic Does the dmap noopt yourmap fix the gap?Yup. It does. Quote Link to post Share on other sites
duzenko 654 Posted October 27, 2018 Report Share Posted October 27, 2018 The 'edge removal optimization' code should be the suspect Does anyone know if the BFG has a dmap function? And if not why was it removed? Quote Link to post Share on other sites
VanishedOne 543 Posted October 27, 2018 Report Share Posted October 27, 2018 "unknown command 'dmap'" RBDoom3BFG restored it though. 1 Quote Some things I'm repeatedly thinking about... - louder scream when you're dying Link to post Share on other sites
HMart 319 Posted October 27, 2018 Report Share Posted October 27, 2018 I assume idsoftware removed it because, one they used a extra tool to compile the maps for BFG so no need to include the older engine dmap, two they thought no one would want to mod BFG has it was very hard to mod, this before RBDoom3BFG came into the scene. Quote Link to post Share on other sites
duzenko 654 Posted October 27, 2018 Report Share Posted October 27, 2018 Anyone knows why the dmap optimization issues a bunch of OpenGL calls in the process? It's not like the draw result is used anywhere EDITIt must be the internal FPU precision issue Quote Link to post Share on other sites
duzenko 654 Posted October 27, 2018 Report Share Posted October 27, 2018 @stgatilovCan you confirm that the ifdef in idMath::InvSqrt is affecting this? @SkarutsDo you have the @nbohr1more's 2.07 alpha build? I can give you a fixed .exe to install on top of thatOr you can just ignore this issue and wait for 2.07 release Quote Link to post Share on other sites
Skaruts 65 Posted October 27, 2018 Report Share Posted October 27, 2018 @Skaruts Do you have the @nbohr1more's 2.07 alpha build? I can give you a fixed .exe to install on top of that Or you can just ignore this issue and wait for 2.07 releaseI don't, but it's ok. I wasn't the one with the issue, I just managed to replicate it. I'm not really making any FMs at the moment either, so... Quote Link to post Share on other sites
stgatilov 1130 Posted December 6, 2018 Report Share Posted December 6, 2018 It seems that the SSE version of InvSqrt was not precise enough.I have supposedly fixed the problem, watch for this kind of issues in the future 2.07 beta. Quote Link to post Share on other sites
grayman 2968 Posted December 6, 2018 Report Share Posted December 6, 2018 I verified that rev 7788 fixes the missing tris in my WIP. Nice work! Quote Link to post Share on other sites
stgatilov 1130 Posted December 6, 2018 Report Share Posted December 6, 2018 I verified that rev 7788 fixes the missing tris in my WIP.Nice work!All the credit goes to Duzenko, he did the hardest part I only fixed the bad code which I wrote for 2.06 Quote Link to post Share on other sites
grayman 2968 Posted December 6, 2018 Report Share Posted December 6, 2018 Ok, then super kudos to both you and Duzenko. 2 Quote Link to post Share on other sites
duzenko 654 Posted December 6, 2018 Report Share Posted December 6, 2018 All the credit goes to Duzenko, he did the hardest part I only fixed the bad code which I wrote for 2.06 Aren't you even a little bit interested why it worked for you on AMD?Do AMD CPU's calculate _mm_rsqrt_ss more precisely? Quote Link to post Share on other sites
stgatilov 1130 Posted December 6, 2018 Report Share Posted December 6, 2018 Aren't you even a little bit interested why it worked for you on AMD?Do AMD CPU's calculate _mm_rsqrt_ss more precisely?The AMD CPUs calculate it differently --- that's for sure.Specification does not define the result precisely, it only says "relative error must not exceed 2^-11" or something like that. It may turn out that AMD implementation is more precise.Or it may be that the particular triangle causes problem only when the error has very specific value. So when you reproduce it on Intel CPU, then you see the problem because they all use the same circuits for it. And when you use AMD CPU, it is not reproduced in this particular case. But you can create some more stairs with such CPU and find another example of the same problem, which will be present on Ryzens but absent on Intels. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.