Not logged in, Join Here! or Log In Below:  
News Articles Search    

 Home / General Programming / Direct3D texture managment Account Manager
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

June 03, 1999, 06:01 AM

Hi, sorry for my English.

I coded simple quake like renderer using automatic texture managment in DirectX 6.
It worked fine but when I added lightmaps, two problems came.
The first problem is that some faces have damaged lightmaps, actually random data. I'm
always checking returned error values of DirectX methods but they returns ok.
The secound problem is performace. When part of scene is first seen, engine is stopped
up to secound like with disk swaping. All lightmaps are althogether about 500KB.
I think this is caused by number of lightmaps - about 9000. Lightmaps are few pixels large.
But is D3D managment limited
to few thousands ? SDK does't say it. (it doesn't say anythink)

I want to composite more lightmaps on larger bitmaps. I also don't want much unused space on
bitmaps. Is there already algorithm to do it effectively ?

Jaap Suter

June 03, 1999, 08:57 AM

You pointed out the solution yourself already. I really would suggest managing your lightmaps on one larger texture (say 256x256). Even if your solution would work you should still do this just for the performance hit.

Conor Stokes (aKa DirtyPunk)

June 04, 1999, 06:38 AM

Jaap Suter wrote:
>>You pointed out the solution yourself already. I really would suggest managing your lightmaps on one larger texture (say 256x256). Even if your solution would work you should still do this just for the performance hit.

Yes, you are right. But, more importantly, you have not pointed out every thing.

One - Is there some way to find the maximum amount of texture size? The proxy texture system
can be used in OGL.

Two - Last I spoke to Martin, he was going to use a simmilar vis system to me, so I imagine
he can find other optimisations. Eg Having lightmaps for a certain area in one texture, and
uploading it as that area becomes visible (you may wish to do this with the octree). This
works great for a PVS system.

Three- Updating the WHOLE lightmap square would be a waste, opengl 1.1 allows subtexture
updates, I am not sure what dx6.0 does. But it is great, because you only have to update
for dynamic lights. And it saves time doing this.

Four- System memory isn't the restriction to lightmap size in this situation (if you only have
500k worth) it is probably either bandwidth or texture memory. I am pretty sure that you
will increase the amount of texture memory available by LODing far off lighting. Eg if
something is far away use smaller maps, of linear shading. This will mean you can increase
the general size of your lightmaps, and not worry about the end consequence as much.

Another good way to show the beauty of lightmaps is to test the lumels
to see how linear the relationship is. This means that if you generate larger lightmaps at
precalc time, you can test the size per lumel on the surface, and use a threshhold to see
if you can decrease it. So if you have a polygon that is covered by almost linear light,
you save space. But if there is hard shadows and such, with contrasting light and hi-lights,
you can get that on other maps. Play around with the values and balance them up.

Conor Stokes


June 07, 1999, 03:33 AM

Thanks for great tips, Conor.

I hope I'll not rude when I say you that it is not new for me (except OGL tips).
I want to composite lightmaps that are near to satisfise PVS. I want them to have
unique size (I chose 32x32). I already implemented this and speed is ok. I implemented
it as preprocess and store list and coordinates of patches. I don't use subtexture -
I have separate maps with dynamic only lightmaps (there are few dynamic on test levels).
DirectX support this by locking rectangle on maps.

But resulting textures have together 2.5 time more space - it means there
is lot of empty space. I want to check if there is already some clever algorithm
for this preprocess. I coded this algorithm: find nearest lmap and store it. Then find
another nearest lmap with similar height and put it next (in the same line). When line
is full go the next line and repeat until map is full.

This thread contains 4 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.