masking a population

[choronr]

I have a project going where I've made a population of Terragen 'Grass clumps'; and, I'm trying to keep the population not to appear on the water. Tried a number of methods; but, all have been unsuccessful so far. Would appreciate some ideas.

[Dune]

Well, restrict by (water) altitude, I'd say. Reduce clumps, as Bobby advised SAS+, as they may be so big they extend beyond a mask limit.

[choronr]

Well, restrict by (water) altitude, I'd say. Reduce clumps, as Bobby advised SAS+, as they may be so big they extend beyond a mask limit.

Thanks, will try. But, what is SAS+ ??

[choronr]

It worked!! Thanks you very much. Looking back at my 'Wetness' image, I found that those settings were also as you suggested here.

The Grass clump is a great object if you use it correctly.

[Dune]

I meant Wassaquatch, sorry.

[choronr]

I meant Wassaquatch, sorry.

Ah yes, the mystical hairy creature.

[WAS]

*wookie noises*

However, I would consider that a bug if the default settings on clump grass do not allow you to plug a mask in it like anything other object population like trees and obtain perfect masks.

As any population usually works rather well with just a Distribution Shader. But in this case, with the Grass Clump it completely obstructs normal workflow for a lot of fine tuning. That should not be the default behavior.

[Oshyan]

This is just a reality of the size of any object when in a population and masked. If you create a population of 100 meter cubes and the origin point of one cube is right inside the edge of the population border, it is of course not going to cut the cube object off at the edge of the mask. That's essentially what you're asking TG to do for the Grass Patch, which is just a procedural object with a specified size. Individual grass blades would be more versatile in masking and terrain following, but much heavier on the populator.

- Oshyan

[choronr]

Thank you Oshyan, appreciate your reply and explanation. Makes good sense and will remember this for the future.

[WAS]

This is just a reality of the size of any object when in a population and masked. If you create a population of 100 meter cubes and the origin point of one cube is right inside the edge of the population border, it is of course not going to cut the cube object off at the edge of the mask. That's essentially what you're asking TG to do for the Grass Patch, which is just a procedural object with a specified size. Individual grass blades would be more versatile in masking and terrain following, but much heavier on the populator.

- Oshyan

Not at all. I think the default scales could be adjusted to match Terragen Scales. Current Grass Clump is huge in comparison to default mountain with amplitude multiplier of 2000.........

Isn't that the point of TGO objects? So they're TG ready? I've noticed most are at correct and proportional scales and do not require much editing (if any) to follow a simple mask. I'd imagine the internal generator of the Grass Clump to work on those same principles.

I can put ANY tree/bush/grass population in TGO format into TG and plug a distribution shader and have a perfect coastline every time without editing the objects. I've only, as this person had trouble with, found a problem with the Grass Clump, or OBJ not yet TG optimized.

As for the single blades, that would make total sense, but as you said it's not practical, which is why we have grass clumps mainly. Though there are models with nice 'clump' simulation that comes from a single point. Which is nice, but collision is the issue with, lets say, rocks, if it has a close mask.

[Oshyan]

The default grass clump object is 10 meters across. That's not necessarily out of scale, but it really depends on what you use it for. On reasonably flat ground a 10m patch is fine. That being said I would agree that 1-2m might make a better default, it's more versatile for rougher terrain for example. However the problem is that TG scenes are quite large, and objects of 1m scale can get easily lost. The camera in the default scene is 10m off the ground. Look at the size of a 1m grass patch in the default scene. It's tiny! Now think of the average user, creating a grass patch, and even with the default camera *if* it were a 1m patch, it would be hardly noticeable, and certainly if they've moved the camera it will be hard for them to see it. That leads to frustration. We've had users complain in the past about exactly this kind of issue. So the problem is we need to balance multiple criteria, and there is seldom one "correct" answer. In this case we want to balance the visibility of the object with a plausible and useful scale. Perhaps 5m would be a better compromise. But regardless the issue remains, whether at 5m or 1m: an object in a population can extend outside the populated area if its size notably extends beyond its center point in real-world units (meters). Many large objects do. The only *real* alternative would be to have an option to check object bounds and now allow the instance if *any* part of the object were outside the masked area, but that would be a more complex population algorithm by far.

- Oshyan

[WAS]

The default grass clump object is 10 meters across. That's not necessarily out of scale, but it really depends on what you use it for. On reasonably flat ground a 10m patch is fine. That being said I would agree that 1-2m might make a better default, it's more versatile for rougher terrain for example. However the problem is that TG scenes are quite large, and objects of 1m scale can get easily lost. The camera in the default scene is 10m off the ground. Look at the size of a 1m grass patch in the default scene. It's tiny! Now think of the average user, creating a grass patch, and even with the default camera *if* it were a 1m patch, it would be hardly noticeable, and certainly if they've moved the camera it will be hard for them to see it. That leads to frustration. We've had users complain in the past about exactly this kind of issue. So the problem is we need to balance multiple criteria, and there is seldom one "correct" answer. In this case we want to balance the visibility of the object with a plausible and useful scale. Perhaps 5m would be a better compromise. But regardless the issue remains, whether at 5m or 1m: an object in a population can extend outside the populated area if its size notably extends beyond its center point in real-world units (meters). Many large objects do. The only *real* alternative would be to have an option to check object bounds and now allow the instance if *any* part of the object were outside the masked area, but that would be a more complex population algorithm by far.

- Oshyan

5m Would be a better compromise. But I feel, that we all, usually use PFs to simulate grass at some point, because we already assume at 10m it would just need the texture and not necessarily pop at you as it would at 2.5m or 5m even. On a realistic scale that seems logical. In relation, it's like standing and looking down at your carpet. It should be popping out at you, unless you do have some serious shag. Ha. 

Just my thoughts. We all love grass, and when we do use it (and we all do) we do usually like to put are camera very close to the grass anyway for a human/animal like perspective. Anything above, should look like rolling fields of green.

I get the size as it is for a 'visual' stand-point. But for me, who is not very good at math as it is. I often get lost in scale relation, and things like this cause me to overlook terrain, and other objects while working with grass.

[Dune]

I agree with Oshyan, as it's easily changed to whatever size is needed, and noobies first need to see it's there.

[N-drju]

From time to time I use grass objects even when I'm some distance above the surface. The ground gets an appealing, fuzzy, sexy look then. Something which requires some work with fractals and displacement. I don't even care that I get half a million grass patches - it's worth it.

However, like Oshyan said, grass is useful on a flat land. If you have a mountain chain, then the placement and alignment of even small-sized patches can go horribly wrong.