sorry about the delay (there was no wind here in wellington for a change so I went to the beach this morning)


its working though perhaps to well as u can see the players feet are inside the terrain, perhaps I just flag the terrain as a non occluder (though there looks to be a couple of errors in hiddenB.jpg but thats only cause the ppl are slightly inside the building slightly, which is another issue namely collision detection, do I A/ do accurate stuff B/rough stuff but thats another can of worms)

actually I was wrong above in my post about not having to do step 3

Quote:but I'm not too crazy about the unknown number of extra draw calls

there are no extra draw calls, u do need to render the units first though + the fullscreenpass is required (though perhaps u could combine this with something else)

Thanks Zipster amd Andy, a job well done, at the moment Im not to concerned about performance but If I do have any more insights Ill add to this topic

Quote:Original post by zedzthe fullscreenpass is required (though perhaps u could combine this with something else)

i always attempt to render as many full screen effects in a single pass as possible. It is tricky to get it right but ultimately a much quicker operation. A pass like the one you have here becomes a trivial addition under those circumstances.

30k-40k vertices per RTS unit is at least an order of magnitude more than any vertex budget I've ever seen, so maybe if you have that many vertices you'd go with an approach that only has to process them once. However that is an extreme usage case for this particular feature, and what it may make up for in speed it lacks in flexibility and modular design. And without profiling, there's really no way you can say one is faster than another in the general case. I myself always prefer a better design over performance until the latter actually becomes a problem, because otherwise you're code tends to end up in a very bad place...

Quote:Original post by Zipster
30k-40k vertices per RTS unit is at least an order of magnitude more than any vertex budget I've ever seen, so maybe if you have that many vertices you'd go with an approach that only has to process them once. However that is an extreme usage case for this particular feature, and what it may make up for in speed it lacks in flexibility and modular design. And without profiling, there's really no way you can say one is faster than another in the general case. I myself always prefer a better design over performance until the latter actually becomes a problem, because otherwise you're code tends to end up in a very bad place...

my point was exactly that, my use case is NOT for an RTS game so all bets are off.

btw - programming for design AND performance is an art form in itself and one that has driven my career to where it is now.

Quote:Original post by AndyFirth
my point was exactly that, my use case is NOT for an RTS game so all bets are off.

btw - programming for design AND performance is an art form in itself and one that has driven my career to where it is now.

Fair enough. It's always good to have multiple tools in the toolbox at any rate.