Ha, I figured out how to fix the LOD in my new file. You simply have to check “True level triggering” on the always actuator that activates the python script(under the logic settings of the object “terrain”). It’s a bit embarrassing on my part that I overlooked that.
Anyway, it should all work fine, now.
Hi benj, you’ve done good job dude… I’ve tested it with the data I did for Arma2 maps(up to 225 square km) and it worked just fine. I’ve found a small bug, when moving my view from ground up to the sky in certain point whole terrain disappears, but when I move view up or down terrain gets back again.
This is an truly nice work, I’ll love it!.
I noticed that too. It’s because of BGE’s view frustum culling. The mesh that is displaced to make the terrain is initially completely flat, so BGE assumes that the whole terrain must be out of your view when you look up. One possible fix is to select the terrain mesh, go into edit mode, and add a single, very small traingle to the mesh, placed very high up, to make the terrain’s bounding box taller so Blender will not hide it when you look up.
Hello!
Nice to see something new 
@ laserblaster: unfortunately your changes doesn’t work on my computer… The shader fail to compile, because “openGL does not allow constant arrays” (according to the system console)… sounds weird…
I already noticed the “ghost” light problem, it seems that when you create a light, then delete it, blender keep it in memory until you create new ones “over” it… The only solution I found was to create 8 black lights to “reset” this, and use one of these when I need a new light … 
@dreamak : Nice to hear that it was usefull to you! It would be nice to see how it looks with your arma2 map
About the disappear bug, laser blaster is right, placing an ultra-small triangle on the top make things back to normal
@ benj- Hmm, it doesn’t work for you? “openGL does not allow constant arrays”? Well, no offense to your compiler, but that’s seems incorrect to me. As of version 120, glsl does allow constant arrays, and I specified #version 120 at the top of the shader. It seems like an issue with your driver’s compiler to me, however, there are a couple of things I could do to fix it. I could use uniform arrays instead(but that wouldn’t allow the compiler to unroll the loop, leading to inferior performance), or I could try adding “#version 120” to the top of the vertex shader as well(maybe your compiler requires that).
Later, I’ll PM you a few lines of code that you can use to replace the old ones and see if it fixes it.
I’ll just post the potential fixes here, because they’re so short.
Okay first, try adding “#version 120” on it’s own line at the top of the vertex shader, minus the quotes, and with no semicolon. If that doesn’t fix the problem(and it probably won’t), go down to what is currently line #259 of the script. On that line, there is a string that reads ‘const int lvecs[’. Simply change that string to ‘int lvecs[’. That will probably fix it.
this is quite beautiful and interesting thanks a lot benj. a+
@ littleneo: thanks
@ laser blaster: Okay, changing the line #259 make the shader to work Great work!
But the framerate is very low… Do you think the python array or the lighting process is longer ?
Hm… You get a very bad framerate? That’s unfortunate. Note that I wouldn’t expect the framerate to be great, seeing as the shader is already complex, and the scene has 3 lights in it by default. But if it’s really low, then there might be another issue. I know it’s not the Python script, though.
Maybe your compiler isn’t unrolling the for loop, like I wanted it to? To fix this, you could try replacing line #259 with:
Arrays = [NL+’#version 120’+NL+’#pragma unroll’+NL+‘const int lvecs[’+str(lightcount)+’] = int[’+str(lightcount)+’](’]
Or, try adding a new line right above the for loop on line 195, and on that line put “#pragma unroll”
Or, if you have a Nvidia card, try replacing line 259 with:
Arrays = [NL+’#version 120’+NL+’#pragma optionNV(unroll all)’+NL+’#pragma optionNV(fastprecision on)’+NL+’#pragma optionNV(fastmath on)’+NL+‘const int lvecs[’+str(lightcount)+’] = int[’+str(lightcount)+’](’]
There is one space between fastprecision and on, and one space after the equals sign. These optimizations give me over double the framerate.
Or maybe your gpu is slow with ints? You could try replacing my interger index array(appended to the shader with Python) with an array of floats.
If none of these ideas work, then the only remaining thing to do would be ditch my index array and use gl_LightSource directly, which means the user will have no control over which lights are use, and even spot lights will be used. It might also lead to problems with “ghost lights”. But if it speeds things up, then that would be good.
Hey!!! Im going to use this in a game!!! I was working on making a huge open world, when i just happened across this thread on accident!!! 
ill use it.
thanks, would you like credit in the credits?
@ laserblaster: Well, it seems that you have been deep in this system, I’ll try all of this when time will be on my side
I guess using directly gl_LighSource could be a good solution (optimisation, compatibility, etc. )
@RudeDood : Hey I’m glad to know it will be used for an actual game Yes, name in the credit would be appreciated, thanks ! And let me see some pictures if you already have some
And feel free to ask any question about how to use it or how to adapt it to your game !
Hello benj
you’re a magician!
What a wonderful demo file ( and work)!
I get a great 60 FPS ( sometimes 80) with my “very old” comp: Athlon X2 3200/GFX 9800
Thank you very much for sharing!
Thank you too, HG1, to feed the 2.49 nostalgia, but your demo doesn’t work very well?! 
Bye
Hey benj, maybe you could change your original post to include my multi-light version(although you don’t have to). It seems that a lot of people are overlooking it(or maybe they just don’t like it enough to mention it? No hard feelings, though).
Hey, I’ve edited the post where I gave the demo .blend, I added yours just next to it.
Maybe people overlook it because the LOD doesnt work directly and because of the problems I had (shader compilation fail)… Maybe you could update your demo ?
What you did is really cool, I actually plan to update my demo file and merge our work. Also try to increase the framerate and make the setup of the system easier. I think I’ll have more time this summer.
I’m using Blender 2.63
when i running i got this
[ATTACH=CONFIG]207137[/ATTACH]
what is the problems? 
your method is amazing, and I think you could solve the collision issues, PM me, I have another use for this system for real time modifiable terrain. Can this Displacement map be edited by brushes?
To fix the player interactions-
So instead of actual collisions I think you can use boundary objects with forces so the player actually sinks just slightly into the terrain, real people step in dirt, not on it… this would look convincing enough if the CPU could handle all the dynamics for all the NPC’s/player doing this, and not have to use the faces that they are stepping in, but when they are far away, you could just have there moments be not physical, until X distance. this could save a lot of CPU cycles,
Wow! I just need something like this for the collision. It does not have to be very exact, because it is not going to be visible in game, just cant have things falling through it.
Do things pass through it, or is it just inaccurate when it is rendering? If the collision works still, I would love to use this in my game
It looks like you’re running in MultiTexture mode, as well as being in Shaded mode. Switch to Textured mode in the view, and I would assume that you would need a GLSL-enabled graphics card (like one that can play modern 3D games).
