Shadow maping in 4k under linux. [ now with binaries ]

[taj]

Frea,

I think I spotted a problem in your shader code that may be causing the problems people have : cant be sure but its a hunch.

Code: [Select]

const char* vertex = "uniform mat4 lp;\
varying vec4 fragLocation;\
varying mat4 colour;\
void main()\
{\
fragLocation=gl_Vertex;\
gl_Position=ftransform();\
for(int i=0;i<2;i++)\
{\
vec3 lp=normalize(lp[i].xyz-gl_Vertex.xyz);\
float att=dot(lp,normalize(gl_Normal));\
colour[i]=vec4(1-i,i,0,0)*att;\
}\
}";
This looks dangerous as you define lp twice, once as a matrix and once as a vec3. It may be some of the shader compilers are not happy with this.

Taj

[frea]

oh my god . I am surpriced now that it works at all .
i'll check your exes a little later.

edit: btw, i am amazed by the size using crinkler .

The exe works for me, but i am unable to use your project file, although this is somewhat normal for my copy of vc . I am even unable to create an empty project, don't ask me why. I've got an legal version btw.

Seems that i will need to or write my own crinkler for linux, which would be a terribly hard task for me, or start programing under windows, which is even worse ;P.

[taj]

oh my god . I am surpriced now that it works at all .
i'll check your exes a little later.

edit: btw, i am amazed by the size using crinkler .

My exe still includes that bug, here is a new one without it...2 lights, also I reduced the code by about 160 bytes. I'm sure if I worked at it, it could go to 2k but I'm getting tired right now.

Yeah I'm amazed too how much better crinkler is. I'll have a lot more respect for linux 4ks in future.

Taj

[Jim]

Crinkler's not just compressing an exe and putting an unpacker on the front like gzip - it completely rewrites your executable format down at the segment level, eliminating redundant segments and overlaying matching ones, while also compressing relocs, data, and code (some clever algorithms to rewite code to get as many 0s as possible).  It's mightlily impressive since not only is it packing, it's also able to behave like a normal linker.

Jim

[Rbz]

all three of them? even the nof.exe?

Yes, all 3 version doesn't work here including that 2 ones by Taj, black background and withe rotating thing
Seems to me that there's something incompatible with Nvidia cards.
 

[taj]

all three of them? even the nof.exe?

Yes, all 3 version doesn't work here including that 2 ones by Taj, black background and withe rotating thing
Seems to me that there's something incompatible with Nvidia cards.

Nvidia really dont do GLSL right, they focus on CG more. I think the first Nvidia cards to get glsl right are series 8XXX. That said, this is most of the skill in shaders, getting it to work on all cards out there, it can be quite tough. I have my suspicion that another bug or two lurks in this shader - its a very sophisticated one and easy to miss something.

[frea]

even more bugs? :<.

Anyway i just discovered that p7zip is much better, on my 64 bit machine it got from 4.8 kb down to 4.1. Although still more that 4kb.
But hat means i need to test all the tricks again, mabye now something will allow me get better results. That would be nice if i would get it down to 4kb with that 600-700 bytes penalty .

[taj]

even more bugs? :<.

Sorry I should be precise. "This shader and program use so many features of GLSL that its possible that even if its is correct, many cards which do not fully implement the standard will not be able to run it".

For example 2x shadow maps in one shader.
Long if condition wrapping a return
Two returns from one function
Multi texturing with shadow maps
>256 instructions (maybe, dont know)

Without Nvidia hardware here it would be hard to debug all these possibilities. Also I'm worried about the mutitexturing - if it is set up correctly , I've heard, but never done it, that shaders are VERY fussy in this area.

Taj

[frea]

Uh. i am used to much to 100% bullet proof solutions then .
I thought that GLSL was way more a 'standart'.

Anyway, using p7zip i was able to get down with that demo to 4095 bytes on a 64bit machine. Woohooo! . but i needed to change the window size to 512x512, i lacked the two last bytes .

btw in the code the calls to glPopMatrix(), glDepthFunc()  and glEnable( GL_TEXTURE_2D ) are unessesary. Also the call to switching the framebuffer to 0 in setUpShadows() is uneeded.

[taj]

Frea,

I've worked a bit on this and got it down to 2171 bytes from the original 2492 using crinkler. For sure you can use a lot of the techniques in here (loads of opengl calls cut out). It behaves as before though slightly (slightly) slower.

Crinkler says your biggest problem now is the generate terrain function. I've had a go at at and cut it down but fundamentally its big (ąround 500 bytes). Anyway I've tried to comment what I've done but watch out becuase not every change is commented. I dont know how much of thsi will be useful under linux but for sure some of it is.

I can see loads of optimisation if you just do one light, not two of course. More than you might think actually, not just the obvious. However I didn't want to alter what your program does.

Anyway, code included, do as you will. I'm disappointed I didnt get it under 2k in windows but the terrain code is expensive although very nice. I've never seen terrain done like that before.


Taj

[frea]

The main thing that i wanted were multiple lights . On the begining i wanted use 4, but when i saw how 2 look i just understood that noone would see anything in there.
I'll check your code now, hope i'll learn something. I hope i spot all the changes .




edit: when i changed sin to sinf i got few bytes on linux, how it is on windows?
To bad i didn't check the default texture parameters, i would save many bytes

btw why changing the random number generator into a function saved bytes? i tried it too but i got bigger size.

edit2: why does it take SO MUCH memory? 200 mb!

[taj]

The main thing that i wanted were multiple lights . On the begining i wanted use 4, but when i saw how 2 look i just understood that noone would see anything in there.
I'll check your code now, hope i'll learn something. I hope i spot all the changes .

edit: when i changed sin to sinf i got few bytes on linux, how it is on windows?
To bad i didn't check the default texture parameters, i would save many bytes

btw why changing the random number generator into a function saved bytes? i tried it too but i got bigger size.

edit2: why does it take SO MUCH memory? 200 mb!

sinf is necessary under gcc but under vc++ sin is overloaded so , as long as floats get passed in it will use the float version.
RNG: its smaller for me, much smaller. Did you manage to spot the other optimisations in that routine (like & instead of %, no min, only max etc.)
crinkler uses 200mb and doesnt free it afterwards.

Taj

[frea]

i spotted the min/max and &. The & was done automatically by gcc.

this behaviour of crinkler would explain why some demos that required 100mb ram crashed for me. 200 mb or crinkler + 100 mb of demo + windows + ... was more then my ram .

edit: why did you get rid of fbo array? Is it always so that ith fbo is represented by just i ?

edit2: the only thing that i could get in terrain was to split the if( ( i < 0 ) || ( i > n1 ) ) into if( i < 0 ) i = 0; if( i == m ) break;
Nothing more .

[taj]

edit: why did you get rid of fbo array? Is it always so that ith fbo is represented by just i ?

Well I got rid of it because it costs bytes :-). I am assuming fbos work like textures. If true then there is no ith FBO just as there is no "ith" texture. You can use any arbitrary int to represent a texture and I assume you can an FBO too. All the function does is guarantee to return a unique int in the texture case, I hope its the same with the FBO case.

[Jim]

In the terrain code:

If you change the terrain to use a pointer to the top left of the parabola, and a width (always 2r) and stride (n1-2r) then you might be able to save.  Clip the pointer (max(heights, height_ptr)), width before drawing the parabola.


OR

To eliminate clipping altogether, render to a square which is much bigger than your landscape (you need to allocate at least r more pixels round the edge, or, if it's a texture, just go to the next power of 2 and change the uvs when you render, or use glTexSubImage.

Jim

[frea]

1st one. if i do in that way, the calculation of the height of parabola gets more complicated( especialy if using only one pointer ). the problem is rather the amount of loops not the values they go through.

2nd i don't get it. In this code i use textures only as shadow maps. I could make the heights array bigger, but that would eliminate only two if's.

Commenting out those two if's gets me about 10b of diffrence, so not that much .

btw taj, for me the whole terrain generation code is about 300b ( compressed ). interesting that crinkler compresses that worse than p7zip.

[taj]

btw taj, for me the whole terrain generation code is about 300b ( compressed ). interesting that crinkler compresses that worse than p7zip.

I was quoting uncompressed - simply because I cant tell how much compression you would get. Its still the largest single routine in the code before or after compression with crinkler.

[Jim]

Only suggestions   10b compressed is another 10bytes...

Jim

[taj]

Only suggestions   10b compressed is another 10bytes...
Jim

Absolutely true.

[Shockwave]

K++ to Taj and Frea.

The example programs are fantastic to look at