| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10
Comments:
<0> well, usualy you only need a pixel shader when rendering the object that recieves the shadow
<1> but how does this "work" ?
<0> but if for some reasion you need to, you can write a pixel shader for rendering the depth values to the texture if you're using shadow mapping
<0> what do you mean?
<1> when does the the pixel shader need the shadow information ?
<0> you render depth values to a texture, then you apply that texture to all objects you render using texture coordinate generation to project the texture onto all objects from the light source
<1> when determing it's influance by the light ?
<1> deltib: and then you use the pixel shader ?
<0> then you just make sure the pixel shaders for all the objects your rendering have code to check if the objects pixels are beyond those in the depth map or not
<1> aaa
<1> hmmm
<0> the pixel shader always needs the information
<1> but don't you need N * 2 shaders then ?
<1> one for with and one for without shadows ?
<0> no
<1> and even more for each feature you wish to be able to enable and disable ?
<0> oh, yeah
<1> deltib: So Shader * 2 ^ (feature swtiches) ?
<0> well, you can use the shadow shader for non shadow objects, and just bind a blank texture to the shadow texture unit, but that would be doing work that's not neccersary
<0> well, yes, you need different shaders for every different configuration of features
<1> so "just switch on or off some effects" is not possible ?
<0> not as such, no
<1> isn't there a way we can can do this inside the pixel shader ?
<1> so they "autoconfig" ?
<1> like a preproccesor statement ?
<0> what do you mean?
<1> and upon change you reload the pixel shader
<0> you could set up something like autoconfig
<1> Pixel shader{
<1> #IF Drawshadows then
<0> you could write some sort of definition language
<1> Pixelshader part needed for shadows
<1> #endfi
<0> and proccess it when loading the shaders
<1> aaa ok
<0> I think there are some shaders that allow for that
<1> bad idea
<0> of course it's only evaluated at compile time
<1> at compile time ?
<1> darn
<1> so not during runtime ?
<0> well, it can be done, but it'll still end up in a large number of different shaders
<0> you definately wouldn't want to recompiling the shaders every time you change the render state
<0> it would be WAY to slow
<0> no, shaders can't make any decisions runtime
<1> deltib: i don't care if it's slow :)
<1> deltib: you don't switch constanstly :)
<0> ....
<0> uh. yes you do
<0> every time you go from one object to the next, you're changing stuff
<1> deltib: only when you enable or disable a feature you regen the shader
<1> deltib: aa like that
<1> deltib: no i'm taling about Graphic -> Options -> Enable shadows [X]
<0> infact, if the engine is flexible enough, you could be changing multiple times per object
<1> deltib: i have NO itention to change it during render
<1> deltib: i was talking user options
<0> "shader"? you mean "shaders"?
<0> oh
<0> what? so everything is rendered by the same one shader unless the user changes an option?
<1> no
<1> i mean
<1> the shader is only recompiled when the user changes an option
<1> to remove the shadow part from the pixel shader for example
<1> orelse the gpu would still be burdenend with the shadow stuff
<0> but what about when rendering a different option, with different effects requires the changing of the shaders?
<1> deltib: that's something the shader will have to do ... somehow
<0> no...it's not
<0> as I just said, the shaders don't make choices runtime
<0> they do the same thing everytime they're run, you can't tell them to not do something
<1> i know
<1> what i mean is when you recompile the shader because an option changed
<1> and then use that shader
<0> okay
<1> the "recompile shader" will have to determen what part of the shader to trow out
<0> you're still going to need a lot of shaders for all the different conditions
<1> well i only want 1 with some #ifdefs or something (IF possible)
<0> how are you going to do it with only 1 shader?
<1> IF possible
<1> so no ifdefs in a shader ?
<0> even if there are (depending on language) that's a compile time issue as I said, and you can't go recompiling hundreds of times per frame
<1> i don't recompile hunders of times per frame
<1> only when a GLOBAL option that applys to ALL shaders changes
<1> i'm talking about the game options here : like enable shadows, texture quality, "use 2.0 pixel shaders" ....
<0> then how do you plan on changing things between objects?
<1> i don't
<1> eitehr user another shader because it's an other material
<0> ...
<1> but no "shadow option" per object
<0> then how will you change the rendering state when you start rendering a different object with a different effect
<1> load antother shader ?
<0> so you'll need more than one
<1> ofcours
<1> one per effect
<0> two
<1> but not one per effect * 2 ^(user graphic options)
<1> deltib: 2 ?
<0> you'll need a vertex shader as well
<1> deltib: a well i see that as "one" for now :)
<0> oh, okay
<1> what i feared was that i has to make a new shader PER user grapgic options
<0> I mean, you don't have to use 2
<0> but for most effects, you'll need custom vertex proccessing as well
<0> I see
<1> and that would be hell :)
<1> because then i could only have like "enable all effect / disalb ethem all"
<0> I suppose
<1> a ok :)
<1> good
<0> what about multiple light sources?
<1> how is this an issue ?
<0> will you just use multiple p***es for that?
<1> you can do it in 1 p*** ?
<0> there are two ways to do it in one p***
<0> no wait, three ways
<0> one way is to write a different shader for each number of lights
<1> btw you said "define your shader langauge" ?
<1> deltib: that's JUK :)
<0> the other is to write a shader that supports all the possible number of light sources, but only adds the result from the number of lights active (it will however proccess light sources even if they're not used)
<0> the last option is shader language 3.0 which allows you to use flow controll and loops
<1> deltib: also juck
<0> why?
<1> then i will be using multiep*** i'm afraid :)
<1> even if its slower
<1> deltib: well the 3
<1> 3.0 is not juk
<0> even if you have 3.0 availble?
<1> the fixed max number or per light number is
<0> oh, I plan on using single p***es wherever possible
<1> deltib: no then i will be using 3.0 =)
<0> yeah, but sometimes you have to do stuff like that in shaders
<1> deltib: then i'd rather not support it ....
<0> like when it comes to point/directional light sources
<1> because it's tomuch work to maintain
<0> unless you use two different shaders for that (wich should be easy enough if you're using multiple p***es
<0> heh, you can't not support lighting, it's kind of the corner stone of 3D graphics
<1> i think i'll only be using 3.0 shader and not 1.1 and 2.0
<1> they 1.1 and 2.0 sound "bad"
<0> ...
<0> so you're going to restrict yourself only to the latest graphics cards?
<1> deltib: ofcours you need lights :)
<1> deltib: and the oldest :)
<0> oldest?
<1> deltib: well give the fact that i need again <normal amount of shader> * n
<1> i don't like that
<1> i like to program <normal amount of shader per effect> * 1
<0> oh, you mean vertex shading
<2> Qantourisc, do atleast 2.0
<1> gaminggeek: but you need like a thousand of shaders !
<0> well, that's not really how 3D graphics works I'm afraid
<0> you do need to change things when you want to do different stuff
<1> 1 for pointlight, 1 for directional light ...
Return to
#lgp
or
Go to some related
logs:
htpasswd2 packet
supython
#suse
#linux
#linux
perl die on warning
ubuntu apt-get openswan
ubuntu php5 could not start up
#physics
#perl
|
|