Yep… this may piss some people off. (That is not my intention)
And yep… I wanted to share the approach I am taking anyways (for a couple reasons)
It’s in it’s suuuuuper infancy stage… just working with grass atm. The custom mesh (for grass at least) creates a single mesh with as many impostors as you need. It uses some internal texture atlas-ing and the GPUAnimationFactor for movement. Lemme show a vid, then I’ll ask the questions I have.
To get transparency and lighting to work properly with this (yes... I want light to effect the impostors and thus far, it looks pretty nice), I'm having to use alpha test & alpha falloff. This has a significant impact on performance. Is there a way around doing this? Objects do not take themselves into account when rending transparency, so I am not sure what else to do.
I think the only reason alpha test would cause a performance drop is because you are rendering more fragments… which you’d be doing anyway if you had some kind of proper transparency. ie: when the scene looks right, more fragments are rendered than when it doesn’t look right. Regardless of solution.
Furreh. And i dont really think it will piss pl off, since this is whats it’s all about, pushing ourselves to new heights… and stuff… that sounds so gay >.>
@pspeed said:
I think the only reason alpha test would cause a performance drop is because you are rendering more fragments... which you'd be doing anyway if you had some kind of proper transparency. ie: when the scene looks right, more fragments are rendered than when it doesn't look right. Regardless of solution.
At first I had subdivided the quads thinking I would be using vertex deforms, but it ends up the texture deform is the key to creating the effect, so I simplified the impostor to a total of 24 verts / 12 triangles (4 verts/ 2 triangles per side). That helped a lot! Thanks for this info!
@Setekh said:
Furreh. And i dont really think it will piss pl off, since this is whats it's all about, pushing ourselves to new heights.. and stuff... that sounds so gay >.>
Anyway, liking it.
That didn't really come across like I meant it too... I mean frustrate people that I would be building something that is already built and then asking questions about how to handle things as I plod along.
@t0neg0d said:
That didn't really come across like I meant it too... I mean frustrate people that I would be building something that is already built and then asking questions about how to handle things as I plod along.
@t0neg0d said:
Yep... one exists.
Yep... I'm doing this for my own benefit.
Yep... this may piss some people off. (That is not my intention)
And yep... I wanted to share the approach I am taking anyways (for a couple reasons)
My take on this "upset feelings". It's not so strange. If I write feature X and share it (and feel both responsible and proud of it) and someone comes along saying. I'll write feature X' it solves the same problem. I'd wonder why. There are (at least) two answers and mixing them up will cause confusion.
a) "There is something wrong/missing with X". Then I'd probably think that making X better/more flexible is the way to go instead of reinventing something. In this way it is more gain for everyone (I'd think - and also maybe a little bit insulted that my version of X seems so bad it must be rewritten).
b) "I want to learn how to make X". Then I'd say - great, more knowledge to more people is very good.
You are clearly doing it for b) and also sharing the process of learning to make X which I think is pretty darn nice of you.
Myself I have no aspiration in writing a procedural vegatation system, I'd happily use whatever module is available in the SDK, but I still enjoy the discussion since I'm learning by your journey.
@nehon said:
you can try with the alphaDiscardThreshold instead of the alphaFolloff.
It will discard the transparent pixels so you'll skip the lighting computation for them.
That is if you use the lighting material
Oooo.. this made a world of difference! I commented out alpha test and alpha threshold... it seems to have the proper effect still and much faster. The additional render states are unnecessary after setting the alpha discard, correct?
This is really nice... I was able to add some 600+ impostors (still a single mesh) and put the camera directly in front of them with minimal to no framerate loss. Once they are past a certain distance it is moot, due to mipmapping, but it was the "up close" stuff that was the concern. Can't thank you enough for pointing this out!!
@oxplay2 said:
hmmm, it would be good, if you would be possible to "not render" hidden parts.
anyway, good luck!
Back face culling is on, which (if I understand correctly) would keep the hidden portions from rendering. I still get a little confused about how the culling works. When I think of back faces, I think of vert groups drawn with faces in two directions, like:
0, 2, 3, 3, 1, 0 and also mapping 3, 2, 0, 0, 1, 3 (which draws a second triangle facing the opposite direction.. against the normal though)
But I THINK back face culling removes faces that are not in view, not faces that opposite to the vertex's normal.
@t0neg0d said:
Back face culling is on, which (if I understand correctly) would keep the hidden portions from rendering. I still get a little confused about how the culling works. When I think of back faces, I think of vert groups drawn with faces in two directions, like:
0, 2, 3, 3, 1, 0 and also mapping 3, 2, 0, 0, 1, 3 (which draws a second triangle facing the opposite direction.. against the normal though)
But I THINK back face culling removes faces that are not in view, not faces that opposite to the vertex's normal.
Anyone by chance able to clarify this?
Backface culling happens on the GPU during rasterization. If backfaces are culled then the back faces of a triangle are not drawn.
@pspeed said:
Backface culling happens on the GPU during rasterization. If backfaces are culled then the back faces of a triangle are not drawn.
Quick question about this... when creating a mesh, this requires that you map the indexes in both directions to create a backface, yes? I noticed if I map them with the normal only, nothing is rendered on the opposite side, no matter what the culling is set to. Um... going off of memory here, but I think that's what happened.
And, second question... if you're using lighting on a quad, it would require you to double the vertices and draw triangles to both sets, with the normals flipped on the second set. correct? or the lighting would be messed up on one side due to the normals facing the opposite direction?
Trying to solidify what I've learned thus far. It seems to work this way, but... better to hear it from someone who knows then assume what I am seeing is what is the correct way to do this.
@t0neg0d said:
Quick question about this... when creating a mesh, this requires that you map the indexes in both directions to create a backface, yes? I noticed if I map them with the normal only, nothing is rendered on the opposite side, no matter what the culling is set to. Um... going off of memory here, but I think that's what happened.
False. If you set face culling to Off then you will see both sides. You must have done something else wrong.
@t0neg0d said:
And, second question... if you're using lighting on a quad, it would require you to double the vertices and draw triangles to both sets, with the normals flipped on the second set. correct? or the lighting would be messed up on one side due to the normals facing the opposite direction?
If you want proper lighting then you will need a separate front and back face, yes.
@pspeed said:
False. If you set face culling to Off then you will see both sides. You must have done something else wrong.
The thought crossed my mind that when I tried this, I might have not set culling to Off. But couldn't remember, so I thought I would ask. Thanks for both answers!
I'm trying to figure out how to proceed with elevation & dispersal without linking it to any particular terrain generator. I have a few thoughts on how to do this, but wanted to get some suggestions before jumping into it.
