You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers. No questions about C++ programming or topics which are answered in the tutorials!
@Granyte Actually, is there any newer article describing Flow Control in detail?
Currently the concepts pretty much still apply.
Technology certainly does 'evolve' just not by random mutation! Natural selection anyone?
So I know now to stay away from "if's" but do you guys know how performance behaves on computers with integrated graphics on their CPU? (No actual graphics card)
And then the only way I know to stay away from "if's" is to create a bunch of different shaders, which means a bunch of irrlicht materials. Is there any drawback from having so many? It doesn't eat at my GPU memory, does it?
And if the vertex shader runs per vertex and the pixel shader runs per pixel on screen, how does the vertex know which pixel to send the TEXCOORD(or whatever) data to?
after reading the height map i should have effectivly scaled my texcoord that's planed for the next time i revisit that shader i should also build a normal map generator instead of building it on the fly like i do in the current shader
kevinsbro wrote:Ok, some good advice here.
So I know now to stay away from "if's" but do you guys know how performance behaves on computers with integrated graphics on their CPU? (No actual graphics card)
And then the only way I know to stay away from "if's" is to create a bunch of different shaders, which means a bunch of irrlicht materials. Is there any drawback from having so many? It doesn't eat at my GPU memory, does it?
And if the vertex shader runs per vertex and the pixel shader runs per pixel on screen, how does the vertex know which pixel to send the TEXCOORD(or whatever) data to?
from that i know the data is interpolated betwen the diferent vertex
IGP have BAD performance as when ever you have to load data into your shader it has to go through your cpu memory bus to acces your RAM where a real gpu has it's own memory wich is much faster for the kind of acces the gpu does and also it won't have to fight with the cpu to get data
The if statements and many branching operations may be simplified by the shader code generation step if the shader compiler finds a way to simplify them to a non branched version. It is suprising to see how in many situations the branching operations are reduced to just one or two, and the shader still works the same.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
kevinsbro wrote:Well here's another thought. Does it cost memory or performance to pass a texture to the shader?
Of course it costs memory and performance, you do an upload to video memory when you bind a texture. These uploads have to go through the driver, and driver calls are pretty slow in most cases (hence the reason why should keep state switches to an absolute minimum while rendering). Texture samples in shaders could be costly too, so that's another point to be aware of.
For memory usage you can do the math yourself: Say you have a 1024x1024 texture in an RGBA format, this means you'll have 8 bits per channel or 32 bits per pixel, which comes down to 4 bytes per pixel. Multiply this by your resolution and you get 4 * 1024^2 = 4194304 bytes, or 4096 kb or 4Mb used in video memory
On current-gen cards this doesn't sound like much, but it doesn't mean you should not keep your texture usage in mind
kevinsbro wrote:Well here's another thought. Does it cost memory or performance to pass a texture to the shader?
Of course it costs memory and performance, you do an upload to video memory when you bind a texture. These uploads have to go through the driver, and driver calls are pretty slow in most cases (hence the reason why should keep state switches to an absolute minimum while rendering). Texture samples in shaders could be costly too, so that's another point to be aware of.
For memory usage you can do the math yourself: Say you have a 1024x1024 texture in an RGBA format, this means you'll have 8 bits per channel or 32 bits per pixel, which comes down to 4 bytes per pixel. Multiply this by your resolution and you get 4 * 1024^2 = 4194304 bytes, or 4096 kb or 4Mb used in video memory
On current-gen cards this doesn't sound like much, but it doesn't mean you should not keep your texture usage in mind
If you also use mipmapping (enabled by default) it adds also the 512, 256, 128, 64, 32, 16,8,4,2 and 1 pixel versions of the texture (2 extra megabytes) and the anisotropic filter versions only makes things worse, so, yes, it is costly to add a texture to a shader. Minimize texture accesses, and if you have to access a texture more than once, do it near the first sample, as the hardware also keeps a texture cache that exploits this kind of access pattern. The DX documentation states that the most optimal texture size is 256x256 pixels.
what the 512, 256, 128, 64, 32, 16,8,4,2 and 1 what is this even usefull for
also in my app i experience a wierd behavior when i upgrade my heightmap size from 1024 to 2048 my memory usage jump from 120 mb to 500 mb (6 face X 2048px X 2 planet) so i guess my menory usage is exponential or i'm jjust not cleaning somethig properly in my conversion from RTT to normal texture
1. Why not google mipmapping? Do you want me to do it for you?
2. It is quadratic, not exponential. A 10x10 crossword has 100 squares, a 20x20 crossword has 400 squares.
shouldn't mipmaps add 1,33 of the total size to texture size? so that 4MB becomes 5,33MB?
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me