Jump to content


Photo

render issue


43 replies to this topic

#26 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12701 posts

Posted 25 October 2018 - 10:53 AM

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.



#27 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 25 October 2018 - 11:35 AM

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.

Spoiler


  • Zen3001 likes this

#28 Zen3001

Zen3001

    Member

  • Member
  • PipPip
  • 32 posts

Posted 25 October 2018 - 11:50 AM

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

Attached Files



#29 Abusimplea

Abusimplea

    Member

  • Member
  • PipPip
  • 488 posts

Posted 25 October 2018 - 10:44 PM

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

Attached the map to the bug.

#30 Zen3001

Zen3001

    Member

  • Member
  • PipPip
  • 32 posts

Posted 26 October 2018 - 01:04 PM

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.

Spoiler

Yup, that helped


  • Skaruts likes this

#31 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 26 October 2018 - 02:36 PM

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 by Skaruts, 26 October 2018 - 02:37 PM.


#32 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 744 posts

Posted 26 October 2018 - 07:19 PM

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 by HMart, 26 October 2018 - 07:19 PM.

  • Skaruts likes this

#33 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1713 posts

Posted 27 October 2018 - 12:50 AM

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



#34 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 27 October 2018 - 01:15 AM

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. 

 

Attached File  stairs.map.txt   26.15KB   6 downloads

 

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 by Skaruts, 27 October 2018 - 02:05 AM.


#35 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1595 posts

Posted 27 October 2018 - 03:42 AM

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



#36 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 27 October 2018 - 04:21 AM

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

#37 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1713 posts

Posted 27 October 2018 - 09:25 AM

This looks like a bug in dmap logic

 

Does the dmap noopt yourmap fix the gap?



#38 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 27 October 2018 - 10:06 AM

This looks like a bug in dmap logic
 
Does the dmap noopt yourmap fix the gap?

Yup. It does.

#39 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1713 posts

Posted 27 October 2018 - 10:09 AM

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?



#40 VanishedOne

VanishedOne

    Advanced Member

  • Member
  • PipPipPip
  • 860 posts

Posted 27 October 2018 - 10:42 AM

"unknown command 'dmap'"

 

RBDoom3BFG restored it though.


  • HMart likes this

Some things I'm repeatedly thinking about...

- louder scream when you're dying


#41 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 744 posts

Posted 27 October 2018 - 10:52 AM

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. 



#42 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1713 posts

Posted 27 October 2018 - 11:08 AM

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



#43 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1713 posts

Posted 27 October 2018 - 11:50 AM

@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



#44 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 27 October 2018 - 12:45 PM

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



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users