Better Foliage

Level design, models, animations, physics, etc.
40 posts Page 2 of 4
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Wed Feb 11, 2015 4:17 pm
@
User avatar
Nils


Interesting. How did you set up the materials/models so they don't deal with backshading?
Nils
Posts: 160
Joined: Thu Feb 05, 2015 3:32 am
 
by Nils » Wed Feb 11, 2015 4:29 pm
JeffR wrote:@Nils

Interesting. How did you set up the materials/models so they don't deal with backshading?


Very planar; a few planes stuck together with animated double-sided texture and one extra LOD with an auto-billboard. A bit of AO to simulate a bit of shadow, in T3D it doesn't come out very strong but without shadows (bugged) it runs smoother anyway. No costly shaders, no normal maps. If you need to render so many shapes it's best to strip it all clean. All the ground cover objects in the the pic share the same atlas map.
Last edited by Nils on Wed Feb 11, 2015 4:54 pm, edited 1 time in total.
Nils
Posts: 160
Joined: Thu Feb 05, 2015 3:32 am
 
by Nils » Wed Feb 11, 2015 4:50 pm
So stripped from everything that decreases performance you can
really populate the shape in great numbers and still run perfectly in-game.

The 1920 x 1080 shot below is taken with all settings to max (AA 4x, FA 16x etc.) with a 3 year old graphics card and still it's >40fps

3d_Grass_Ingame_T3D2.jpg
3d_Grass_Ingame_T3D2.jpg (252.44 KiB) Viewed 2230 times
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Wed Feb 11, 2015 6:39 pm
I'm still not sure how you're not seeing shading on polies that face away from light sources like the sun though. That's the single biggest cause of ugly foliage in T3D.

Also, what's the tri count on your high-res grass mesh?

Pretty awesome shot there at though :)
Nils
Posts: 160
Joined: Thu Feb 05, 2015 3:32 am
 
by Nils » Thu Feb 12, 2015 2:55 am
I'm still not sure how you're not seeing shading on polies that face away from light sources like the sun though. That's the single biggest cause of ugly foliage in T3D.


That's because the downwards facing mesh normals will appear too strong on ground cover objects in T3D. You can edit the normals in your 3d application to make them look brighter by pushing them upwards.

Also, what's the tri count on your high-res grass mesh?


The green grass mesh in the 1st shot has 27 vertices at LOD 0 and 4 at LOD 1 (auto billboard)
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Thu Feb 12, 2015 3:39 am
Would a potential engine side solution be a material property that overwrites the normals that are writtten into the gbuffer for that material with upward facing ones? You could enable it on the grass material and the grass would be lit as though it had all upward facing normals.
Nils
Posts: 160
Joined: Thu Feb 05, 2015 3:32 am
 
by Nils » Thu Feb 12, 2015 5:47 am
Would a potential engine side solution be a material property that overwrites the normals that are writtten into the gbuffer for that material with upward facing ones? You could enable it on the grass material and the grass would be lit as though it had all upward facing normals.


For the lazy artist it would be handy solution :P :P :P

Editing normals in a 3d application is work that can be done in a matter of seconds. An artist could choose to fine tune the normals to fake a bit of shadow; of course depending on the amount of faces used in the mesh.
JeffR
Steering Committee
Steering Committee
Posts: 740
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Feb 12, 2015 3:44 pm
Well, for example, blender doesn't have very good tools for manually editing normals.

As well as if you're trying to use art packs in the engine - needing to crack those open and manually fix them is kind of an annoying step that slows down prototyping and the like.

It's not a hard fix, but streamlining the art pipeline is generally a good thing where possible ;)
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Thu Feb 12, 2015 4:43 pm
Maybe if the normals were just weighed heavily in the Z+ direction using a configurable value in the material from 0 - 1. That way it wouldn't be so cut and dry as all upward facing normals, but instead let you scale the normals towards Z+ using a value from 0 - 1.

I'm trying to avoid having to place a new material info flag into the gbuffer to flag foliage and light it differently. If I could provide a workable solution from altering the normals before the lighting stage that would be ideal. Worse case scenario I'll just bite the bullet and make a custom lighting flag for foliage.
Steve_Yorkshire
Posts: 202
Joined: Tue Feb 03, 2015 10:30 pm
 
by Steve_Yorkshire » Thu Feb 12, 2015 7:59 pm
@
User avatar
Nils
Looks nice! Any video?
8-)
40 posts Page 2 of 4

Who is online

Users browsing this forum: No registered users and 1 guest