Does ET foliage use repeatable values?

(G0-Gerbil) #1

I’m thinking of using ET foliage (a la Radar’s terrain) to create obstacles for the player.
As an example, imagine I want to litter a valley (might be Helmsdeep, might not be ;)) with lots of rocks.
If I use the foliage parameters to create these rocks, which will be distance culled so they don’t impact framerate too much, then of course they are not solid.
Now, if I were to (presumably painstakingly) locate the position of each of these rocks manually and put a rough solid clip brush there, then I’d have the ‘best’ of both worlds within reason.

Now, two issues:

  1. Does the foliage routine use a simple placement algorithm so I could in fact calculate where to put these clip brushes rather than me have to do it manually, and
  2. In what way (if any) are the results of the foliage creation the same between compiles? IE does recompiling each time generate a different random result? If not, does adding more foliage brushes elsewhere give different results, etc. etc.

Ideally to my joy I’d discover that placement is based on a top-down grid system that never varies (apart from when you change the frequency of said models in the shader itself).

Just trying to get the info together to see if this is even worth persuing :slight_smile:

(LowLife) #2

The times i used foliage, it always was the same placement on every compile.
But think over this, if you clip distance culled objects, it will look pretty weird, from a distance, when players are standind on those objects.
I think it would be better to use the tree planter.

(WolfWings) #3

Or, the other option…

…manually use the ‘alphaGen portal’ shader keyword, and just blend out the rocks at a distance manually.

You could even put in an autoSprite polygon in the middle then, that wouldn’t fade out, to get around the ‘standing on mid-air’ problem, if that’s even possible with how you’re placing the rocks. If I’m not mistaken, you’d more likely be using the effect for rocks that couldn’t be realistically gotten onto in the first place, so it would be a moot issue. :slight_smile:

(rgoer) #4

WolfWings’ solution sounds cool.

(G0-Gerbil) #5

I’d thought of the autosprite thing, but really it all revolves around how consistent their locations are, and how much effort it is for me to find them and track them down. IE no point in looking further if it ain’t worth my time to do.

As for the portal idea, it did indeed sound cool, until I realised that in fact this would more than likely make the rocks even slower than if I’d just plonked them there in the first place.

Remember, I’m not simply trying to make them look like they fade in, I’m trying to cut the CPU load by not having stuff drawn at a distance - the portal thing will mean they are drawn constantly, even in the distance, just they now have an additional distance calculation for how strong the alpha is, as well as now making all my normal rock shaders require an alpha pass etc. etc.

I guess I may have to prod around into the actual q3map2 code to see how the positions are generated. Urk!

(rgoer) #6

what if you combine foliage and fog (or are you trying to avoid fog)

(G0-Gerbil) #7

I’m just looking for answers to my questions - not alternatives. The thought is appreciated though :slight_smile:

I just think foliage could be very useful, but currently it’s only really applicable to non-collision stuff, and even then it’s a bit of a joke.
I want to use it to provide additional detail that can be interacted with - it’s potentially more useful than normal stuff because of it’s the only thing in ET that is distance-culled. It’s that part of it that’s something nice I’d like to get into.

Of course… it now occurs to me that maybe Ydnar could re-do the foliage stuff slightly to be of use.
I mean, ET obviously has a distance-culling means of displaying a model. All foliage does is automate this model creation and placement.
How about if we had a new entity, something like misc_foliage_model or misc_distance_model that was essentially the same as …

OK I like the idea so I’m not going to waste my time here, but start a new thread - hopefully it’s more likely to catch Ydnar’s eye that way :wink:

(G0-Gerbil) #8

Scrap that for now, forgot I need to play with the distancecull shader parameter.
It may well be that the foliage stuff simply places the models, but it’s the distancecull shader that actually deals with the cull, which if true means I can make anything be distance culled which would be nice.

Will report back :slight_smile:

(G0-Gerbil) #9

Hmmm not much luck yet, although it might be because I haven’t tried a model in MD3 format (I tried ASE but that’s pretty much compile-time only ASAIR).
I was going to try with the actual radar foliage MD3s, but… they don’t appear to be there? in models/foliage/ I just have 3 grass textures, but no md3s?
Anyone got 'em?
I’ll try to knock up a quick md3 using those shaders in milkshape but I R crap in milkshape so it may not work…

(rgoer) #10

why not just test it with a cube md3… you can whip out a cube from milkshape, right?

(G0-Gerbil) #11

Well, kinda - milkshape was one of those things I bought with high hopes of getting to know well, but I never seemed to get around to it.
So far I’ve only used it for changing shaders on existing MD3s.

However, even that limited knowledge was enough for me to conduct my tests, and the results are…

  1. Only models generated using the q3map_foliage shader command are stored as part of the culled models
  2. It only works with MD3s
  3. The MD3s used MUST include the distancecull shader command

Now it’s not as bad as all that, I’m reasonably sure I can with a bit of effort build my models in radiant, export to ASE and then find some convoluted means of turning them into MD3s - that’s not something that concerns me - actually building my models :slight_smile:

The good news is…

I’ve found a simple way of specifically placing a single foliage model. Pretty obvious once I’d thought about it.
Basically create a shader along the following lines:

textures/culltest/specific
{
	qer_editorimage textures/mml_church_se_a1/grass.tga
	q3map_foliage models/mapobjects/culltestmodels/grasstest.md3 1.0 256 1.0 0
	implicitmap textures/mml_church_se_a1/grass.tga
}

The important part is, of course, the q3map_foliage line. I’ve set the probability of a model being used to 1, IE always. Then I’ve set the area for which this probability is used to 256 (IE big).
Now if you create a small brush, say 4x4x4 units and paint the top face with this shader, you will always get a single foliage model in it’s corner.

Now, I think from this I should be able to create a prefab easily enough.
Make the above shader basically clip, and build your model’s clip brush, painting the bottom surface with the foliage clip shader.

You now have a brush you should be able to place anywhere that is the invisible clip version of the foliage model that will be generated. Hurrah!

The only issue I can think of now is that I believe the foliage thing may rotate the foliage models randomly, in which case you are pretty much limited to circular shapes (or the clip shape won’t always match it) but for small rocks etc this is fine.

If you also include an autosprite shader as part of it (but obviously smaller than the foliage model so it doesn’t extend beyond it when they are both drawn) then you’ve got (hopefully) a prefab that generates a higher poly model up close and uses a low detail model far away.

I’ve almost certainly missed some important part of the equation that means the above isn’t really that useful.
It occurs to me the autosprite hit needs to be much lower than the full polygon model, so if you are only using simple MF3s, you are probably better off skipping the autosprite stage, otherwise they’ll cancel each other out or possibly even be slower than just plain using the md3s.

But until then, I’m happy :slight_smile:
Bring it on :slight_smile:

(G0-Gerbil) #12

Here’s the end result btw:

(G0-Gerbil) #13

Urk I misjudged, each little block has TWO versions of the model, not one - back to the drawing board for now grrrr :slight_smile:

(G0-Gerbil) #14

OK seem to have sorted it now.
The trick is to use tiny triangles not squares.
And having looked some more, it appears the models are never rotated, which makes clipping accurately easier.

Now, whether it’s actually going to save on framerates, well, testing is the key again, but at least I know what I want to do can now be done.

(ydnar) #15

OK, need to clear the air here a bit.

  • The foliage will appear in the same place between compiles.

  • Clipping foliage is a Bad Idea. The engine can’t deal with that much clipping/collision data.

  • Using a single foliage model is slower than simply using a single misc_model. The foliage code is tuned to draw lots of foliage and optimizes for that case.

  • Using alphaGen portal is not the same as the foliage fading. The foliage code doesn’t draw foliage past the transparent distance, whereas the alphaGen portal code still renders the passes, but with 0 alpha, resulting in no speedup. Additionally, the foliage alpha fade code is optimized for lots of vertexes.

To recap, use folaige for rocks, debris, grass, and other things where collision doesn’t matter. Use clip brushes with misc_model entities of simple models if you want physical barriers.

I plan to fix some bugs in the foliage code to eliminate the “clumping” seen now.

y

(G0-Gerbil) #16

But there’s surely benefits of using ‘foliage’ (a misnomer of course since you don’t have to just use it for that!) is that it’s culled?
Say you set up trees in a forest using this, then you’d need at least rough clipping.
I’m not implying you’d use foliage with as many models as the grass in radar - part of the problem with radar is there was too much grass.
But you could use much MUCH less frequent models, and not all over the map (eg the trees thing again, for localised clumping).
Would this seem like a bad idea?
IE the clipping data is very simple (box), the culled model is high detail, but not as frequently displayed as radar grass (which in my example would result in a forest you can’t actually walk through!). Surely this is more beneficial than simply having all the models displayed, which in a long visibility (eg no farplane stuff) map would result in horrific framerates?

I think you are working on the assumption that any use of foliage stuff will be to get tons and tons of models, but that’s not what I’m aiming for - less models just higher polygon count, with distance culling for speed gains. Foliage code may not be as optimised for drawing models as a simple game model, but surely there’s some area where slow drawing but only up close is better than faster drawing but even in the distance which may be considerable, meaning tons more of them to draw?

Also, how does the culling work exactly? Is it a ‘player to each model origin’ check, or are the models batched up with a bounding group distance check?