render issue

[grayman 2974]

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.

[Skaruts 65]

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.

 

[Zen3001 8]

here's the map file, don't know how to attach it to the report myself

fstmp.map.txt

[Abusimplea 168]

here's the map file, don't know how to attach it to the report myself

Attached the map to the bug.

[Zen3001 8]

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

[Skaruts 65]

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

[HMart 334]

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

[duzenko 659]

What is the smallest simplest repro case? Can you get it break with just an empty room and a staircase?

[Skaruts 65]

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

[Destined 618]

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).

[Skaruts 65]

Can't the unnecessary geometry become a bit of an issue, though, in dmap times or at runtime? Especially if stairs are detailed?

[duzenko 659]

This looks like a bug in dmap logic

 

Does the dmap noopt yourmap fix the gap?

[Skaruts 65]

This looks like a bug in dmap logic

 

Does the dmap noopt yourmap fix the gap?

Yup. It does.

[duzenko 659]

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?

[VanishedOne 546]

"unknown command 'dmap'"

 

RBDoom3BFG restored it though.

[HMart 334]

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.

[duzenko 659]

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

 

EDIT

It must be the internal FPU precision issue

[duzenko 659]

@stgatilov

Can you confirm that the ifdef in idMath::InvSqrt is affecting this?

 

@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 release

[Skaruts 65]

@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 release

I 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...

[stgatilov 1223]

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.

[grayman 2974]

I verified that rev 7788 fixes the missing tris in my WIP.

 

Nice work!

[stgatilov 1223]

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

[grayman 2974]

Ok, then super kudos to both you and Duzenko.

[duzenko 659]

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?

[stgatilov 1223]

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.