Sorry your browser is not supported!

I'm having problems with Dark Light. Or at least, Dark Lights is now highlighting a dormant problem in my code. The two symptoms are that when I add an object to Dark Lights to be light mapped, it becomes corrupted and the vertex data goes all over the place. A secondary symptom that start occurring later is a timer function, in a completely unrelated area of code causes an access violation.

All I'm doing is a simple light map:


This example causes corruption to the object arenaShell->dbObjTop. If I load in a new version of that model, rather than using the one that's already loaded, the light mapping works ok and I don't get a crash.

I can guarantee 100% dbObjTop exists and is genuine, because the model is on screen and gets corrupted when light mapped. So Dark Lights is struggling for some reason with the previously loaded model, but not a newly loaded one.

Having played around with lots of things, my suspicion is that the model data is somehow being interfered with after loading, perhaps by a dodgy array write or something like that (my editor is really complex now). I wonder if it's possible that the model data is being corrupted, so when Dark Lights tries to process it, it jumps into some weird memory positions, messes up the vertex data of my model and also other memory (hence the unrelated timing code blowing up).

Does anyone know how to go about debugging a problem like this? If something else is writing to the memory where the object is stored, how could I track that down?

I'm going to start stepping through the code and making a list of things that get allocated after the arena model is loaded, but perhaps there's a better way?

Edit: Just a note: It's not crashing on timer code, it's crashing on the dbSync() command, so the sync must be struggling with the corrupt object data.

Ok problem finally sussed! After half a day of trawling through arrays and pointer code, checking for possible overflows and other things, I couldn't find a problem. Turns out it's something to do with what happens to an object during a dbSync()

This code works fine:


However, if you add a dbSync() command anywhere in that code AFTER the object load but BEFORE the LMAddLightMapObject() the model data will be corrupted and the program will most likely crash. The reason I was having the problem is my models are loaded in my level editor, loads of syncs happen as the user works on the model and then only when they hit "Render Lights" do the models get added to the light mapper and rendered.

So I think the solution will be:
- Run LMStart() when my program first loads
- Run LMAddCollisionObject and LMAddLightMapObject directly after loading your model (or making it with mesh commands)
- Then you can sync away as much as you like before you make the light maps

Unfortunately this solution won't work for me, as model prefabs may be removed before the light mapping is rendered, and there is no command to remove an individual model from the light mapper. So my only solution is, when the user clicks to render lighting:
- Save all models to disk with all positional information etc.
- Load and rebuild the entire scene
- Render the lighting
- Continue as if that wasn't a pain in the arse

I need to work on scene saving code anyway, so I guess I'll kill two birds.

Also setting the lightmap file names only accepts a single char, rather than a char* as suggested by the manual. So it doesn't look like you can actually name your lightmaps, or give them a directory, which I'm sure is going to cause me massive headaches soon. I think I'm going to have to manually edit the generated DBO files binary to get them to use unique lightmap texture names, then rename the generic 1.png etc. files made. Unless there's something I'm missing? It seems too ridiculous to have a core command simply not work and nobody to have been bothered by that. So I must be doing something wrong?

4 thing you can try:
1. clone objects, delete originals, perform lightmapping on the clones
2. convert object fvf, perform lightmapping
3. convert object fvf, clone object, delete originals, perform lightmapping on clones
4. lock vertexdata for objects with mode 2, perform lightmapping

Good suggestion. I didn't think of that. May give it a try tomorrow. I finished my save/load level functionality today anyway, so I basically save then reload the level before light mapping and that works. Cloning the objects may be cleaner though.

I'll report back if it works. Cheers.

I had issues with Dark Lights too a while ago, thanks for posting possible solutions/work arounds, I may give Dark Lights another chance for my next project.

I'm using it quite thoroughly and finding workarounds/solutions for several problems. Learning a lot about what makes it crash (seems quite easy to do, but so far it's always been something I've done), so if you have any questions about using it, I'll keep my eyes peeled and try and answer them.

Hello,

Does all these features in Dark Lights work (http://www.thegamecreators.com/?m=view_product&id=2023)? Can anybody confirm ?



I am asking this , because I downloaded the demo but it did not work for me!

Yes, they do. I used Dark Lights extensively for my level editor project (back in 2006). It's quite powerful. There are some additional commands not mentioned in the help file. Readme file covers them all. To be honest I haven't experienced any issue described in this thread while using DL- and I did for quite a while.

MapScape (CSG map builder) made by EVOLVED uses Dark Lights for internal light mapping.

I heard the demo doesn't work because it strips out every third triangle (essentially making your models like cheese). It was created solely for testing purposes.

@Olby: Thank you for the confirmation. I was finding myself a bit shaky about the lingering bugs that can trouble us in the middle of our projects. Seems like - it is worth buying.

As with everything from TGC make sure you use it right or you will get into issues sooner or later i.e. stick to the rules. That's my advice. I have had so many issues with DBPro related products just because I tried to achieve something unusual and that's where one usually gets into trouble.

I see.