after the “outdoor beautyfullyizing”-thread has gone from beginner to advanced, i have decided to start a new one, with even more advanced questions and answers…
so, thats my engine for now :
(you need to know that i have 6 texture-units)
it blends 3 greyscaled detailtextures together, adds a 1024*1024 colored basetexture (which is created out of a lot of small tiling textures), then adds a random noise texture, which alltogether looks pretty nice.
the whole landscape is octree-and-frustum-culling-able.
my plans are:
by using a second renderpass, i want to add 3 more layers of this time non-greyscaled textures : a path (can be everywhere), leafes (under the trees), and shadows (under the trees, to give the illusion of real high detail shadows)
then i got 3 more tex-units waiting for orders. with them, i want to implement a possibly never-done-before-lighting-method.
the 4th unit contains a coverage-factor texture.
the 5th and 6th contain 2 lightmaps, one calculated for the sun being at the “morning-position”, the other contains the lighting-data for the evening.
texures 1-3 use the coverage-factors of tex unit 4.
textures 5+6 use the value i tell them by using glcolor4f to blend from 50% nothing 50% morning-shadow to 100% nothing (mid day) and then to 50/50 nothing/evening.
is this possible, or will my lightmaps simply override everything rendered before ?
You can blend any way you want, as long as you output the appropriate alpha and color values, and set the blend function appropriately.
I don’t think lerping between “morning” and “evening” will work all that well. It’ll look like two different shadows in different amounts. What you really want is a single shadow which moves (like a sun-dial) during the day.
My suggestion: Use one texture unit for a shadow texture you render dynamically instead.
what u can do because the sun aint moving that quickly over the screen at once.
break up the calculations into small pieces
eg one frame do 16x16 area (from a 1024x1024 area)
next frame do another 16x16 area etc.
i do something similar for procedural terrain (though not lighting)
Zed’s suggestion is a good idea. You can have three lightmaps, blending between previous and current lightmap, while at the same time calculating the next one, which is ready to be used when you need it.
Alternatively you can use a shadow algorithm for the shadows and per-pixel lighting for local lighting. Just have a normalmap for the terrain instead of a lightmap. Perspective shadow maps have the potential to make your engine really great, and seem by far the best shadow algorithm for the outdoor/sunlight situation. But it’s a pretty unexplored area, and I have my doubts on them…
One more thing, bear in mind, that at some point you’re going to want more lights than just the sun. A fireplace, village at nighttime, explosions and so. For those lights the perspective shadow maps will propably totally suck, so in that way the lightmap is a safer option.
i just discovered a simple method for night/day shift :
create a simple texture, whose color changes from white to dark blue, stretch it a lot, so its bigger than the map, then use automatic texture coord generation and combine it with just everything.
then just scroll the daynightshifttexture slowly…
btw because of i’m using an octree :
how many glbindtexture-commands are “allowed” in opengl ? (i don’t want to kill the performance) but for every node i need about 4 glbindtextures…
or should i divide every node into 4 displaylists (one list for every texture) and then get all nodes i have to draw, and run through this array 4 times, every time drawing other objects, saving binds ?
[This message has been edited by HamsterofDeath (edited 02-03-2003).]
If the sum of unique textures you bind in one frame is larger than available card VRAM (minus frame buffers, z buffer, etc) then you’re likely to start suffering performance degradation because of texture swapping to main RAM.
It used to be a good idea to remember all geometry to be drawn with each texture, and then bind each texture once and draw all geometry for that texture. That’s not necessarily true anymore; for example, if you want to set up a lot of state per mesh (say, a skinned mesh with lots of bone matrices) you may be better off setting up that state just once, and swapping between textures within that object.
that will make it easier for me happy
btw my ftp is on : ftp://hamsterdevelopment.homeftp.org
just a little but slow because of emule uploadind stuff (8kb/s are free for upload…)
Technically there’s a little more to day/night shift than just changing colors, since the direction of the light changes too. Is there something wrong with using opengl lighting? Propably the fact that it’ll mess up your texture blending. Maybe you could store the coverage factors in a texture instead of colors.
But if shifting the colors with a texture looks good, by all means use it. Try not to get stuck with details, terrain lighting isn’t that big a problem.
at the moment, my planned engine will use 3 coverblending detailtextures, AND 2 more coverblended textures (stony-earthy-path & leafes under the trees or maybe i’ll make shadows by this…i could scroll teh covertex-holding texture to do this (would look good i think) and do the leafs by using decals.
so the first 6 texture units will be used just for lighting-free-texturing
in the second renderpass, i’ll enable lighting, draw the base tex, a noise tex, and the morning/night/evening color, some decals…so everyone with a geforce fx ultra turbo or radeon 9900² will be pleased ^^
right now i’m implementing a frustum culling-algorithm (octree has just been finished, is now able to accept any objects like trees without messing up the landscape happy)