[r774] Models dissapear when standing at certain angles

[Nash]

I realize this has been brought up at least once, and probably acknowledged as unfixable or whatever.

However, since Graf Zahl isn't maintaining the port anymore, I'd like to file this as a bug because I really think it's not supposed to happen. Hopefully with this bug report open, whoever who decides to work on GZDoom's GL features might consider fixing this.

Models which are large will disappear if the sector that they are placed in is out of the player's view.

Load the example file and observe look at the blue guy's feet. Now rotate your view until the water sector is out of view. Model magically disappears.

There are situations where big models have to be in small sectors (gigantic monsters perhaps). If they so happen to be (or die) in a small sector, it is annoying to see their geometry suddenly disappear.

http://files.drdteam.org/index.php/file ... U/dead.zip

[Enjay]

Yes, I raised this some time ago myself. The answer that I got, however, was not that it is a model based problem, but standard Doom behaviour. If the sector that an actor is in is not visible, then the actor is not displayed. This holds true for sprites as well as models. It just tends to show up a bit more often with models because models are often bigger than sprites. Given that it is standard behaviour, I don't think a "fix" is likely any time soon.

[Gez]

Why do you expect this to be addressed now that the GL renderer is no longer maintained?

The only solution I can give you is to make sure that the sector the model is in remains always in the field of vision. IIRC, it's the sector that matters, not the subsector, so you can cheat by making advantage of Doom's disjoint sectors.

The "fix" would be to always render things even when they aren't supposed to be visible... As if not enough people complained about performances... By the way you get the same thing with really huge sprites, it's just that they're less likely to be used.

[Graf Zahl]

This has nothing to do with the GL renderer as such. If anyone finds a solution for this in the software renderer it'd take 10 minutes at most to port it to the GL renderer. But nobody has found a working solution for this problem yet.

[Spleen]

When you are saying a monster has to be "in" a sector, does any part of it have to be in the sector, or does its center have to be in the sector?


If the latter, this seems awfully reminiscent of the blockmap hitscan bug, and could possibly benefit from the same fix - letting each sector any part of the monster is in know about it.


Gez's suggestion could be implemented as an *option*, for those of us with stronger hardware.

[Gez]

If the latter, this seems awfully reminiscent of the blockmap hitscan bug, and could possibly benefit from the same fix - letting each sector any part of the monster is in know about it.

But that requires assuming that the sprite or model width does actually really correspond to the "radius"...

Gez's suggestion could be implemented as an *option*, for those of us with stronger hardware.

It's not a suggestion.

[Enjay]

But that requires assuming that the sprite or model width does actually really correspond to the "radius"...

Indeed, and even in a simple case that breaks down. If we imagine an enemy model that is the same size as the revenant sprite, the initial model will be around 40 units wide and 90 units tall (the underlying actor will be 40 units wide and 56 units tall - already a disparity). Now, if our enemy dies and his death position leaves him lying flat on his back, he is now 90 units wide in one direction but only actually 40 units wide. ie, the model gets wider but the actor does not.

Also, Doom actors are all square in plan view, so models such as cars, space ships etc will tend to be longer than their actual width in one direction or narrower than their actual width in the other even if you do try to match the size of the underlying actor to the model - not forgetting the "sticking out bits" that could easily be on these models.

Unless GZdoom starts keeping track of the position of all the model vertices (and doing collision detection based on them - which would be very nice) I don't really see this idea flying I'm afraid.

[Nash]

Well, that's just too bad then.

[Dethernal]

maybe new DECORATE flag (+ALWAYSDRAW ?) (draw from special list, after standard drawing cycle) can solve this SERIOUS problem.

[Gez]

Unless GZdoom starts keeping track of the position of all the model vertices

-- which would require an OpenGL developer working on it, of which there are none at the moment --


I can't stress this enough. The OpenGL code in GZDoom is not going to be changed (until, I suppose, Graf resumes working on it). I'm not going to make any change to it, other than the minimum needed to adjust it to ZDoom changes, or fixing blatant* bugs. Do not expect new features.

(* By blatant bugs, I mean something that involves no algorithmic error. Just stuff like a missing null pointer check, a division by zero or the likes. Something that can easily be traced when debugging, and that can be fixed without risking unforeseen side effects. I don't feel qualified to do more involved work.)

maybe new DECORATE flag (+ALWAYSDRAW ?) (draw from special list, after standard drawing cycle) can solve this SERIOUS problem.

If it's a serious problem for you, just make sure your huge models are in sectors that are always in sight when they themselves are in sight. This is easy to achieve even with tiny dummy sectors sprinkled here and there given that Doom sectors can be disjointed.

[Dethernal]

If it's a serious problem for you, just make sure your huge models are in sectors that are always in sight when they themselves are in sight. This is easy to achieve even with tiny dummy sectors sprinkled here and there given that Doom sectors can be disjointed.

In general, this is impossible. particularly in the modes and maps with dynamic geometry.

[Enjay]

-- which would require an OpenGL developer working on it, of which there are none at the moment --

Indeed. Perhaps I wasn't careful enough in my phrasing. I didn't mean it to come across as a feature request or even something that I believed might happen any time soon - if ever. It was merely a bit of musing on things that would be nice but are highly unlikely to happen - recognising that there is no-one working on the OpenGL renderer aspect of GZdoom ATM.

In general, this is impossible. particularly in the modes and maps with dynamic geometry.

Not impossible, just tricky. I've done it, Rex has done it and I'm sure lots of other people have too.

[Spleen]

Gez's suggestion could be implemented as an *option*, for those of us with stronger hardware.

It's not a suggestion.

I mean the idea of drawing everything. That could be an option for people with uber hardware, that would of course be disabled by default. Though I dunno who would implement it, lol..

which would require an OpenGL developer working on it, of which there are none at the moment

If we're lucky, maybe Torr will add more OpenGL features to Skulltag and share the code so we can port them to GZDoom.

[metroid014]

Just as the topic title states, if I stand at some specific angles while looking at a model. It will vanish. However if I slightly change my position it re-appears.

Model Appearing Fine (Bricks on the ground):


Model Vanishing:

[Rex Claussen]

One issue with models in GZDooM is that as soon as the sector in which the model is located is out of sight, the model goes out of sight too. This is typically a problem with larger models. In your case, however, there does not appear to be a problem with outsized models, so I'm not sure why this is happening.

Are these models in their own sectors (e.g., for blocking purposes)? If so, try one thing that may solve the problem. Create a sector for the blocking, but within it create a sector and give it the sector reference of that of the main room. [I.e., if the main room has a sector number of 0, and your brick sectors have sector number(s) 1-3, create sub-sectors within sectors 1-3, and make the sub-sectors have sector number 0. How you do this may depend on which map editor you use.] Place the models within the sub-sectors. In this way, whenever you can see sector 0 you'll be able to see the models.