Light mapping concept
Light mapping concept
So i was thinking about a fast way to do light mapping for use with 3ds levels. My first idea was to have max export all the coords where the lights should be in the map then have the code open the text file exported from max and add the lights at all those coords. It seems to me this is the method that others on the forum may be using, but in all fareness doesnt seem all to efficent especially on load times. So i started thinking of way to do a compiled light map. Im thinking the max plugin could generate i .c file or even a .asm file wich writes all the code to add these lights and then the mapper could compile this file as a dll(or something) with one entry point wich includes all the code max generated then the main game has a refrence to this dll and calls the function wich would then add all the lights. Would this way be faster, more optimal way of doing lightmaps? Has anyone expermented with an idea like this or has an even better one?
First of all read this and choose what you like
http://irrlicht.sourceforge.net/phpBB2/ ... php?t=6074
http://irrlicht.sourceforge.net/phpBB2/ ... php?t=6074
Sorry that sounded kind of rude, thank you for the link though i may use some of those tools to do some things. My idea is buiding a world using all dynamic lights so the shadowing looks really slick, it seems like a good way to make a beautiful world! Those tools look like there makinbg a precompiled light system wich is going to be on par with maybe bsp style lights, wich arent to swift compared to newer games such as doom3 wich is using tons of dynamic lights.
Like i said my idea is to use 3ds MaxScript to export all the code to generate a new dynamic light. For example you would drop a cube in the level set its attributes in 3dstudio max to a light using this plug-in (just as dropping a new light entity into a bsp maker like qradiant or worldcraft). You then export with the plug-in wich will write a out a .c file or .asm (for the simplicty of the explanation we will use a .c and a new dll). After max has generated this file you will then create a new dll then put all of it's code in this dll files entry point. The pseudo code for the game will go
So there you go when it call light.dll's entry point it runs all the code max gereated to make the new dynamic light with the mappers specified coords and attributes.
So does this idea make seanse, and what does someone think about it? Would it give that much of an advantage than just opening a new text file will all the info you need reading it then writing a function in the game to draw all the lights based off the text info. Now in real life im more thinking about acually having the maxscript export it as asm then you would assemble an obj file and call that from your game code, its alot easier to grasp the concept with c and dlls though since most people are familar with those concepts.
Sorry im just really excited about this idea and would like some feedback!
Like i said my idea is to use 3ds MaxScript to export all the code to generate a new dynamic light. For example you would drop a cube in the level set its attributes in 3dstudio max to a light using this plug-in (just as dropping a new light entity into a bsp maker like qradiant or worldcraft). You then export with the plug-in wich will write a out a .c file or .asm (for the simplicty of the explanation we will use a .c and a new dll). After max has generated this file you will then create a new dll then put all of it's code in this dll files entry point. The pseudo code for the game will go
Code: Select all
do a bunch of init crap
load some entities
draw some stuff
call light.dll's entry point
render scene
So does this idea make seanse, and what does someone think about it? Would it give that much of an advantage than just opening a new text file will all the info you need reading it then writing a function in the game to draw all the lights based off the text info. Now in real life im more thinking about acually having the maxscript export it as asm then you would assemble an obj file and call that from your game code, its alot easier to grasp the concept with c and dlls though since most people are familar with those concepts.
Sorry im just really excited about this idea and would like some feedback!
-
Guest
No offense, but that seems like a bad idea.
You're free to do as you like, but here's my advice:
Using dynamic lights with Irrlicht:
I suppose you haven't noticed yet but stencil shadows are sharp shadows and sharp shadows are often quite ugly. And even though stencil shadows are "fast", they are still heavy, especially when you have a lot of lights.
Lightmaps are precalculated which means they can be soft and don't eat up a lot of performance.
Doom3 apparently uses shadowmapping, which looks good, is dynamic, and is also reasonably fast on current hardware.
AFAIK, Irrlicht doesn't do shadowmapping yet, so right now you're stuck with stencilshadows.
But more importantly, the dll method makes it difficult for you to create/switch levels by having level-specific dlls.
Some potential problems:
-DLLs may remain loaded until the user logs off or reboots, unless you're really careful to unload them manually when you want to switch levels. If your program crashes, it probably remains loaded until the user logs off.
-You restrict your user base to Windows only (that costs you maybe 10-20% of users, so not a very big deal I guess)
-You need to use your C compiler every time the level is modified, or the changes aren't applied.
-The dll would presumably have to create irrlicht entities, which means it needs to be compiled against the same version of irrlicht, since different irrlicht versions don't seem to like eachother very much.
-if at some point you want to allow users to create their own levels, you're condemning them to the use of a C compiler.
-and what do you do nowadays when somebody sends you an attachment named "light.dll"?
Besides, if you're already doing the "load some entities" bit, what's stopping you from "load some lights"?
You're free to do as you like, but here's my advice:
Using dynamic lights with Irrlicht:
I suppose you haven't noticed yet but stencil shadows are sharp shadows and sharp shadows are often quite ugly. And even though stencil shadows are "fast", they are still heavy, especially when you have a lot of lights.
Lightmaps are precalculated which means they can be soft and don't eat up a lot of performance.
Doom3 apparently uses shadowmapping, which looks good, is dynamic, and is also reasonably fast on current hardware.
AFAIK, Irrlicht doesn't do shadowmapping yet, so right now you're stuck with stencilshadows.
But more importantly, the dll method makes it difficult for you to create/switch levels by having level-specific dlls.
Some potential problems:
-DLLs may remain loaded until the user logs off or reboots, unless you're really careful to unload them manually when you want to switch levels. If your program crashes, it probably remains loaded until the user logs off.
-You restrict your user base to Windows only (that costs you maybe 10-20% of users, so not a very big deal I guess)
-You need to use your C compiler every time the level is modified, or the changes aren't applied.
-The dll would presumably have to create irrlicht entities, which means it needs to be compiled against the same version of irrlicht, since different irrlicht versions don't seem to like eachother very much.
-if at some point you want to allow users to create their own levels, you're condemning them to the use of a C compiler.
-and what do you do nowadays when somebody sends you an attachment named "light.dll"?
Besides, if you're already doing the "load some entities" bit, what's stopping you from "load some lights"?
-
Guest