limiting decorate object viewing distance

[real_trisk]

Hey all, from what I've seen I'm guessing you can't but is there any way to limit the visibility of a decorate object? I want to populate a large outdoor area with particle grass, but with them all visible all at once the framerate tanks. I'd like to be able to have them fade out as particle grass does in all modern games so that the engine only needs to render the ones that are around the player, like 512 map units or something.

I can't find anything, but there are so many functions, maybe I missed something in the wiki? If there is nothing, it's a serious oversight that stands in the way of making modern graphics in GZDoom.

Any help would be appreciated.

Thanks,
Ben

[edward850]

I'm not sure there is much you could do with this. Anything I could think of would be pretty redundant, as it require the objects to be rendered anyway. Speaking of which, what could you possibly make that would slow down (G)Zdoom that much? Seeing as I can get a decent framerate rendering the entire nuts.wad field, I must honestly see this thing you created that slows Zdoom down to 1FPS.

[InsaneFury]

http://zdoom.org/wiki/A_LookEx

make the grass look for a target with minseedist, maxseedist.

If http://zdoom.org/wiki/A_JumpIfInTargetInventory is a player and http://zdoom.org/wiki/A_JumpIfTargetInLOS and http://zdoom.org/wiki/A_JumpIfCloser then show
else start again.

I'm guessing doing this over 512 map units will slow the game down even more? Question is, what's slower: displaying the objects, or having them around invisibly yet looking for players each couplebof tics.

[edward850]

The problem with that method is that it still requires you to take a pause, which means it still needs to render a frame, defeating the entire point. Infact, if his situation is as bad as he says it is, then this would mean it would go slower, as he now has to waste processing time doing a distance check on every single piece of grass (I'm unsure in how much that will slow things down, but it sure isn't going to speed anything up in this case).

[NeuralStunner]

Question is, what's slower: displaying the objects, or having them around invisibly yet looking for players each couplebof tics.

To answer this:

nuts.wad

I can render it just fine as well - but once AI kicks in, the framerate drops to slideshow proportions. The monsters in that map ARE using A_Look, so it apparently doesn't actually take as much processing as the chase routines. So InsaneFury's trick might actually work.

Is TNT1A0 actually nonrendered?

[edward850]

It does exist in zdoom.pk3, but it's a 1x1 pixel PNG.

[NeuralStunner]

Actually my image editor won't open it... and then there's this:

TNT1A0 is not a provided blank sprite. It's actually a special case check by the engine to render nothing. That is, even if you load a PWAD that provides a TNT1A0 sprite with actual visible graphics, it will still be invisible.

[Xaser]

The image is never rendered, that's true -- whether or not it has any actual impact on performance, I can't say. Intuition points to 'yes', but that's just a guess.

[edward850]

Hmm, then it might actually work. I still would like to see this 'grass slowdown' in action.

[NeuralStunner]

Oh, and another way to save on processing is the +NOINTERACTION flag. This obviously could be troublesome if the object was on a floor that could move.

[Ceeb]

Phocas 2 used an effect like this... It seemed to work.

[Gez]

I'm guessing doing this over 512 map units will slow the game down even more? Question is, what's slower: displaying the objects, or having them around invisibly yet looking for players each couplebof tics.

I'd say the latter, especially given how line-of-sight computation are very CPU intensive.

[Enjay]

Would this be useful?

http://zdoom.org/wiki/A_CheckSightOrRange

[real_trisk]

I did try the +NOINTERACTION flag and it bought me absolutely nothing.

I'm taking a look at the other thoughts here, see what I can figure out. I'm worried though, that having a code string on thousands of objects will in fact make things worse...but we'll see.

[Nash]

I think I've seen screenshots of what you're trying to do on the Prodigal website (of which the point-and-click that I've played; good job! Didn't finish it though...)

Are you using sprite grass or model grass? If you're using sprites, what're the dimensions of the sprite? I imagine thousands of high-res grass sprites is going to slow down the engine. If you're using models, what's the poly count on them?

If your map is single-player-only, maybe what you can do is divide your map into sections and only have 1 section have grass at any one time... any other far away sections that aren't visible to the player will have grass objects removed. It goes a little more complicated than this when it comes time to code this, but that's the basic idea.

EDIT: Here's an idea.

1) Setup "grass cluster center" whose sole function is to spawn "clusters" of grass around it. So placing one "center" will cover a 256 x 256 area full of grass, for example.

2) Cluster center does not spawn anything by default; check distance between cluster center and player. If center is close to player, proceed to spawn clusters of grass. Otherwise, destroy grass. There are several ways to keep track of the spawned grass. Child-master relationship, similar TIDs between cluster center and spawned grass, etc.

It requires a looping distance check and obviously the more cluster centers you have, the more things needed to be checked... but if you setup your loop with a high delay then you can save some CPU cycles.

Again this is a very rough concept and might be too much work for little gain, but that's the idea I had.