That makes sense. Thanks again for the quick reply. (As an aside, it seems like desaturation could be done in one instruction, e.g. "color.rgb = dot(color.rgb, float3(0.2126, 0.7152, 0.0722));" :)
On Fri, Feb 25, 2011 at 11:13 AM, Maarten De Meyer <maar...@off-limits.be>wrote: > It depends what you put in your part of the combo and what you keep. We > wanted to keep the existing shader behavior and add a desaturation at the > end that can be dynamically toggled on and off. Desaturation is not very > costly, it's only a few instructions, but adding those already pushed us > over the limit of a lot of combos. Since I didnt want to increase the shader > model I cut out a few combos - left out some variables we didn't use anyway > in our maps, until the lot compiled. Depending on what you want in your > vision you won't have a problem - if it's very stylised you don't need to > keep all the existing shader code and you won't have a problem. > > -- Maarten > > > On 25/02/2011 19:37, Zach Brockway wrote: > > Good info. Tony also suggested using a material proxy on #hlcoders. I'll > hopefully have time to look into it some this weekend. However, your mention > of instruction limits is cause for concern. If the alternate vision mode > behavior is controlled by a combo variable, wouldn't the compiler > optimization of the static branching prevent the normal behavior of the > shader from eating up instruction limit? > > I'll also look into replacing the materials, but that sounds even harder to > implement cleanly. > > Thanks. > > On Tue, Feb 22, 2011 at 9:23 PM, Maarten De Meyer > <maar...@off-limits.be>wrote: > >> Wasnt there a replacematerial method? I remember something like that. >> For our alternate vision i ended up making a custom version of all the stock >> shaders with a material proxy allowing me to switch between vision modes in >> the shader itself. Advantages there are the switch is immediate and you can >> change the effects outcome per material, contrary to a postprocess. >> Disadvantages are that you have to be able to do it in a shader ofcourse, >> and that the stock shaders leave very little room for modification before >> you hit the limits of the shader model. >> ------------------------------ >> From: Zach Brockway >> Sent: woensdag 23 februari 2011 0:23 >> >> To: hlcoders@list.valvesoftware.com >> Subject: [hlcoders] Overriding materials, especially while rendering >> world (BSP) geometry >> >> Hi list, >> >> I've been investigating the possibility of being able to do >> across-the-board material overriding. Motivated by an idea for implementing >> an alternate vision mode, it would also entail a few other things like >> rendering alternate view setups into render targets; however, all of that >> seems to be well-supported and you even get the benefit of examples of how >> to do it. The part that I'm really stuck on is the fact that there doesn't >> seem to be a way to affect the material used for rendering BSP geometry, >> since it's all blackboxed away in the engine. >> >> Things I've tried: >> >> 1. Calling ForcedMaterialOverride on modelrender, studiorender, and >> g_pStudioRender, before render->DrawWorldLists is called. This had no >> effect. >> 2. Installing an IBrushRenderer using >> render->InstallBrushSurfaceRenderer. My implementation of >> RenderBrushModelSurface was never called, so I suspect this only affects >> brush-based entities. >> >> Of course, I still have to worry about how to handle the rendering of >> *everything else* if I manage to figure this out, but this particular >> problem struck me as the biggest stretch for the engine. >> >> Thanks in advance for any advice. >> >> -- >> "They've penetrated our code walls. They're stealing the Internet!" >> "We'll need to hack all IPs simultaneously." >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > > > -- > "They've penetrated our code walls. They're stealing the Internet!" > "We'll need to hack all IPs simultaneously." > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > -- "They've penetrated our code walls. They're stealing the Internet!" "We'll need to hack all IPs simultaneously."
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
