Grassy area - scatter test

[simmsimaging]

To do grass with a 1x1m proxy requires some strict scene conditions.

Agreed, but it was fine for my purpose at the time. The geometry came in as 4-5 separate types/clumpings of grass that I have since broken out as even smaller and separate vrayproxies, which could be used on uneven terrain I think, but I haven't tried it yet.

I also found the 1mX1m was hard to use on larger areas because even with VrayScatter it was crapping out and not rendering with too many instances. I think each proxied section was about 2.5-3 million polys, so it got pretty heavy fast.

Still, works fine for foreground areas and then you can shift to even 2D mapped grass for mid/background stuff where it doesn't matter much anyway.

b

[Shimakaze]

What computer did you render these on? 20 minutes is pretty fast.
Guess everyone has the luxury of a huge render farm except me...

[voltron7]

computer

What computer did you render these on? 20 minutes is pretty fast.
Guess everyone has the luxury of a huge render farm except me...

Just 2 machines total.
Workstation is...


Slave is a Q6600 @2.66, 4GB RAM, running XP Pro x64

Working on an animation test now...

[Shimakaze]

Hmm that's not so different from mine. Your slave is faster then my dual core, but my main should be a bit faster then yours (Core 2 Quad Extreme X9650).
I recently rendered a forest scene that took 2 hours and it had much fewer proxies then these pictures (granted they were Onyx Trees, but still)...
What render settings did you use?

[voltron7]

....
What render settings did you use?

BF & LC and BTW, each of my grass proxies was 7,511 polygons. i also use Onyx and usually the trees for further away can even be 15-25K polygons...(at least for me.) I tried it using the grass posted on the MW forum, referred/found by simmsimaging and it wasn't much slower, but it seemed to take more cpu power/RAM...I haven't done a poly count for that, but it was a whole lot more polys than my patches...
thanks

[voltron7]

"quick" MOV

I had some more "free" time so I tried a test animation...
http://www.maine-ais.com/WIP09/Adir-...r-Test0000.mov

It was 200 frames, each frame was from 3:30 to 6:48 to render as .png
Lightcache @2000 samples was saved (it took about 22 minutes to build.)

I reduced the resolution a bit and took the DMC down a bit so there is some noise, sorry...
This is essentially my first animation trying Vray, so I know there might have been mistakes (So far, I have only been asked for stills.)

One thing was the saved light cache was +660MB!!
I think it was because I switched the filter to "fixed" @ .04" (default) and I think it was a mistake, lol.

[3LP]

@ simmsimaging :

Your grass is just awesome, may I ask if you could share some secrets of your mats ?
is it done with 2sidemat, fastsss2?
maybe a screenshot

thanks a lot, congrats

[simmsimaging]

@ simmsimaging :

Your grass is just awesome, may I ask if you could share some secrets of your mats ?
is it done with 2sidemat, fastsss2?
maybe a screenshot

thanks a lot, congrats

The materials are what I wanted to go back and fix actually It's just a basic Vray material, no SSS and no translucency at all. It was meant for more distant shots, but I decided to render some closer images just to see how it looked.

Relevant settings are in the attached image in any case. The texture map is just a flat grass map so it creates some variations in the greens.

[digitalx3d]

wow... really nice work everyone. Anyone want to take a stab at animating their proxies?? It's really tempting for me to set up a scene and test this out myself, but unfortunately don't have the time right now. It might be possible to substantially reduce the thickness of the grass patches if the underlying surface has some kind of grass texture mapped to it. That's worked well for me when using Vray Fur to do large areas of grass.

Does anyone know if it'd be possible to use a bitmap to rotate/lean the little bundles of grass?? For instance if the grass were sitting above a white area, the blades would lean off to one side so many degrees. Vray Fur does this and I was able to simulate mowing strips this way which lended a lot of credibility to the grass. (see below) The grass in the image is mostly linear (or close to) because Fur was choking up and render times were too slow, but with proxied geometry and curved blades that show the highlights/reflection/sss, realistic looking grass is finally here! Very exciting....

[simmsimaging]

I only work in stills so have no experience with animating - can't help you there

The samples I posted do use a grass mapped 2D plane to fill in the holes, it works very well at any distance, but up close you still need a fair number of proxies.

I have been playing with this stuff in the odd free moment and I have broken it down into much smaller clumps of grass and it scatters around a contoured plane no problem at all. Works like a charm, and it's actually easier to control the variation of the grass types that way too. No chance to do any real renders yet.

b

[xte]

Hi,

your renders are very nice. After having looked at your tests I wanted to try something similar, but able to adapt to irregular terrains and with more control on the distribution of the grass.

The goal is to be able to produce grass as detailed as in those wonderful renders posted on cgtalk.

I'm not sure if my idea is worth much, but basically here is how I did:

1.create the blades for the grass. (extremely simple geometry here, more or less like your blades on first page.)
2.scatter a large amount of blades on the target terrain with particle flow.
3.turn the pflow to mesh and save it as a proxy (replacing the actual geometry).
4.change the seed of the position operator in pflow.
5. repeat steps 2 to 4 until the grass is dense enough.


good points:

-grass can follow exactly the terrain
-avoiding repeating tiles of grass.
-we can use all pflow tools to draw/place/randomize different types of grass. So its possible to use maps for the type of grass.

problems:

-the process of converting particles to vrmesh was buggy with xp32 when a lot of polygons are involved, I will try on xp64.
-long/boring
-you have to repeat the process for each terrain.
-probably not worth it for very large terrains.
-uses more ram to have different proxies instead of repeating the same proxy, but I think it should be very useable on a 64bit system.

here is my quick test on a 10m*10m terrain with 6 proxies (grass is not dense enough but I was lazy):


I will try with better grass geometry and a better material later. (geometry and material were done in 3mins)

[MikeeMax]

Same technique




as you can see when the terrain is really curved, the direction of the straws follows the normals... in the real world, it points upwards/// vertical i mean.... if anyone has a workaround...

your technique looks cool xte. i'llgive it a try. thanks

[Shimakaze]

I believe this method kinda defies the purpose of proxies.
When using proxies the idea is to store an object as a separate entity and then use it many times. Then, when rendering, the computer only has to store the object once in memory and can discard it when it's not needed. When you convert such large objects as proxies and only use them once you don't gain any benefits because the whole object has to be loaded into memory regardless.
The only real plus of converting them to proxies is it speeds up the viewport.
I'm not fluent on the technology so someone else please correct me if I'm wrong, but it seems to me in this case converting to proxies would slow things down instead?

The images are really good though and proves this technique can be used.
As for the pointing the wrong way thing, you can change the way objects are aligned in PFlow. Just use world space instead of surface normals.

[MikeeMax]

I believe this method kinda defies the purpose of proxies.
When using proxies the idea is to store an object as a separate entity and then use it many times. Then, when rendering, the computer only has to store the object once in memory and can discard it when it's not needed. When you convert such large objects as proxies and only use them once you don't gain any benefits because the whole object has to be loaded into memory regardless.
The only real plus of converting them to proxies is it speeds up the viewport.
I'm not fluent on the technology so someone else please correct me if I'm wrong, but it seems to me in this case converting to proxies would slow things down instead?

The images are really good though and proves this technique can be used.
As for the pointing the wrong way thing, you can change the way objects are aligned in PFlow. Just use world space instead of surface normals.

i didn't used pflow in the images. when i said "same technique" i was referring to the one in the first post of the thread

[simmsimaging]

Another rough test using the same geometry as before, only broken into smaller clumps and scattered using VrayScatter. 5 different clumps/proxies scattered maybe 100-200K times.

Rendered pretty quick as I recall but I did not note the actual time.

b

p.s Don't mind the airborne grass, that is just me messing up the distribution settings.