Filter problem

Hello all.







I’m having trouble with my lightmaps. What you see in the picture are very low resolution lightmaps that is filtered with FM_LINEAR. It seams to me that the filtering use rather few colors when calculating the transition betwen pixels. Is there a way to affect the filtering settings?

I'm not quite sure what you mean, but you affect the filter settings by setting the filter in the Texture class. You might also try ansiotropic textures during the creation of the texture. However, looking at the screenshot, it might be you are getting that result because the lightmap is low res.

This is how the texture is created:


TextureManager.loadTexture(loader.lightmaps[i], Texture.MM_LINEAR_LINEAR, Texture.FM_LINEAR, DisplaySystem.getDisplaySystem().getRenderer().createTextureState().getMaxAnisotropic(), false);



(Is this what you mean by anisotropic textures, or is there something else I can do?)

The lightmaps are basically very low resolution black and white textures. When I create the lightmaps with FM_NEAREST it looks like this:


As far as I understand when using FM_LINEAR the texture is smoothed out by adding alot of colors in between the pixels in the original texture making a smooth transition between the color values. What I'm wondering is if there is some way to control how this is done or if all I can do is to switch it on or off.

those lightmaps are too low res. Check you are doing the artwork using well the lightmap bitmap space.



For that scene, I wouldn't use less than 1024x1024, unless you aim at low spec machines. Then try several of 256 or 128.





also, always in art side (only side I know)  no filter at all , bilinear, trilinear , or anisotropic are the typical filters done by the 3d card, but all eat resources. Much very specially anisotropic. beware that.



An old trick for low res lightmaps is blur em A HUGE LOT…is something I guess BSP technique did a lot, besides very clever lightmap packing.



I see that you even have a pixel of lightmap for a facet of a column…



edit: can u show the lightmap tga? the 2d file I mean

These are the lightmaps:






I see that you even have a pixel of lightmap for a facet of a column


Sorry I don't understand what you mean. Probably just that it's very low res.

Thanks for the advice.

btw its made with gtkradiant and q3map2

Edit:Do you have any advice on a software to use to create lightmaps?

they seem way too low res…





if the sofwtare allows it, just do it higher res…



yes, i know and use other tools, but are more complex, and often not so good.



I think those editors you use avoid you the need of messing with Uvs, and othe rproblems.



configure them to use a much higher lightmap size.



Ie, like 1024x1024 each. And check the results.




though probably they are limited due to bsp limits…

I can probable do it somehow, q3map2 has alot of switches and shader commands.


yes, i know and use other tools, but are more complex


This makes me very curious about what tools you are using but I understand if you are unwilling to say.

Thanks again, to you both.

not unwilling to say , sorry.



just tired



I meant I'd say tomorrow…

You're not still running in 16bpp are you?

16 bits? yup, that's no good for gradients, so no good for lightmaps, either.

change to 32 bits in graphics if u can…



Anyway, hugest prob you have is resolution.



Look, I am very busy solving stuff in the art side of things for my own project, but in a few little hours I will post a collection of the free ways you can have to lightmap an scene without wasting a $…



Also was not only as I was very tired yesterday…was as I think you'd better try first solve the problem with radiant, as is way easier than "by hand" lightmapping techniques, requires extra knowledge, and also, free tools have all one problem or another. I had learn to overcome all them, but these days i use a comercial one, called Giles. Or simply Max at work.



Later, I will write a paragraph and a list of tools and links, ok?



But first I must solve an strong issue we have with our project…





edit: for your won good, try force GTKradiant to output huge lightmap size…OR…what is the way old BSP used to work…the tiny 64x64 or 128x128 were though to be used as parts of a puzzle…if u joined together all pieces, you'd get a huge graphic file…it's called lightmap partitioning, so you'd have a lot of pixels in total for the whole scene, while being no big files…indeed, those years I doubt you could put any 1024x1024 texture into any card…if I remember right, only my gfti4200 128mb, was one of the first cheap ones to allow that…at least for ut2003 engine…



That is, probably old BSPs used small chunks of 64x64 pixels, but usinga lot of those for a simple room…not one for ALL…So, while I never use game editors, but 3d packages, I have a suspiction you could configure GTKRadiant to use the maps for lightmap in the way i tell you…can be just a simple setting…dig well the preferences and the setting spread all over the software UI…Somewhere there must be…

llama said:

You're not still running in 16bpp are you?

No I'm not. I was playing around with it before because I know some users could be oblivious of their screen color quality settings. I just wanted to make sure It looked as good as it could in 16 bits.

All screenshots I have posted in this subject are caught running in 32 bit color.

I found something interesting while playing around with the code this morning.

I have analyzed some of my screenshots and have found that all those grey fields that lie next to each other are at least two steps apart in color value.



The rgb values I sampled are displayed in the screenshot. Thats one whole bit loss in precision right?

After testing all sorts of changes in the code, I found that commenting out the setCombineScaleRGB(2); line in where the lightmap is added restores the precision.

Texture lt = lightTextures[face.lightmapID];

edit_: curious thing u discovered, if it is as you say…Would worth a look by the programmers…

Also, yep, by all means, try to rescale the brushlightmap setting, or whatever is needed, all my solutions bellow are way harder.







ok



sent a bunch of test files to my poor friend. Time to wait a bit and add here an explanation and links.





You have two big ways t ogenerate lightmaps.  3d packages, or typical game editors. game editors are initially thought for gamers, modders or fans. Reason why, tend to be less complex (though depends on the case…)



Making a lightmap nicely in Max is harder than in a game editor like gtkradiant or the like.



There are very few free lightmap  tools (I mean, those in the 3d package style) available, and those existing are uncomplete or with some serious lack. yet though , can be used, using tricks and stuff. Yet though, rarely you will get the quality of Max using Final Render , brazil, or the like, at maximum quality, with a free tool, even in its maximum config.



A mesh needs to have 2 uv channels at least, to be able to carry a lightmap. Max usually puts it in channel3 (Max can have till 99 channels) I have made though, lightmaps be in any channel I want, is just dealing a bit with the lightmap window inmax.



usually, the main problem here is the support in formats and inside tools. Blender for example, does not have it, not even a procedure practical enough to bake lightmaps even in channel1 (a method very poor is bake lighting in same texture channel, but then u can't do tiling. And then unless you can use large textures of a whole wall, and walls are not too big :wink: , you'r lost)



Formats supporting uv channels are very few, also. OBJ only support one. Not dishing it, ASE has a lot of problems which OBJ doesn't. To me OBj is the best format out there, not the most advanced , but is solid, and most of all, way spread in all the packages.



ASE supports 2(or more). And I see is the only one format for this in jME. To port lightmaps here.



I have helped in tools for lightmapping and engines, that what did was take two objects, and grab the uv channel of one of them, for th elightmap, grab the uv channel of the other obj, fo rthe texture channel, and so, build a own format file with the two channels. Was like a msdos command tool, quite comfortable to use, to me at least.



There's probably the possibility of doing some sort of this, stuff for the coder of the project (ahem) , which would be take 2 OBJs, one with each of the infos.



This would certainly avoid all sort of ASE issues…but having ase work well sound to me more compact and comfortable for the artist :wink: I'll dig about it so(in the art side).





I mean, the usual path in free tools is not easy, and often is a big deal with formats.



-first of all, Lightmapmaker. Was a comercial sofware. Surely company stopped functioning. As was given away freeware just very near to the moemnt the domain stopped to be there. I have found no other place on the net…So I guess I did well in keeping a copy :wink: Download, is one of my temporary uploads to savefile, so, there must be only one or 2 days lasting…it still works now, this fule, as just checked…in the page that appears, loook at the right botton corner, a nice button saying download (at the left bottom appears name of file.)



savefile.com - This website is for sale! - File Sharing Resources and Information.





edit4_looks like 0.38 was a good version.It has b3d export (is a rich format, supporting a lot of scenery features, among them, ), vrml97, x (x has 2 uvchannels export support, but in certain version ) Also, I didn't kno, but looks it also have radiosity and caustics. I have just checked and looked nice…



This one above is usrely the best solution for free. Aceppts smoothing normals, and has good quality. I'd try that one as main solution.







-Slimshady. Nice one, but also a bit hard to handle, and wont support smooth shading. That is, only faceted shading. Good for when there are no curved surfaces in the level (ie: pipes, archs.)



download latets version ( 0.3, possibly)

melog.ch





-a more high quality lighting and render, is one based on radiosity, called FSRAD. Is way cool, but once again, no support for smoothing normals…If I understood correctly(look at the cone example, how it is faceted in the lightmap generated http://www.fluidstudios.com/rad/ also notice what nice lighting it produces… )… I have used this one, well, like all I mention. And its great. But quite hard to learn. And usually involves a long and complex workflow along several utilities: is even harder than the expensive packages way…So, harder would be this sort of utilities , then coemrcial packages, then game editors (the easiest)

Lord trancos made a modified version of it, which involves generate some special material in some of the scene materials,or etra polies, which will be the "emittors" .It's involved some fiddling with dos utilities, and editing text files, I must warn you.

http://www.geocities.com/dxlab/tmp/fsrad.html



I made it work nicely in my samples, too.



-Same author(of fsrad modification above, as fsrad is open source from certain company) made a similar tool to slimshady. Even simila rin the fact of not supporting smooth shading, but only faceted.



http://www.geocities.com/dxlab/



later on, and in a less "oficial" manner, he put an alpha for testing in some forums. But You'd probably need install the other, as I think this alpha is just the exe, or something like that…

http://www.geocities.com/dxlab/tmp/lmtools_alpha.html



edit 3__That alpha's main advantage is …it does support smoothing normals. No radiosity, only direct illumination, less quality or "feel" , but surely also faster and averagely good enough :slight_smile: problem like most of this tools can be workflow…Easy for me and other freaky users, but not so much for who comes anew into these sort of complex workflows…



-Finally you could use blender, mount your scene with lighting, etc…bake the stuff into a tga in uv channel 1. Export as obj. Also export as OBj and its materials, the standard textured file. With the two OBJs, you'd have to mount in code a multiuv file so to have a lightmapped scene. basicly, the texture in its typical way, and the second uv bitmap, loaded in , for example multiplyx2: a lightmap. But I would not recommend loading into game both meshes , just build a combo of it with one mesh, but generating a second uv channel.  Darkbasci pro used to load both models, in some sort of fake, and it duplicates processing. Among other issues.



Blender is at Blender.org . And you'd need a plugin, Macouno's Raybaker.

Is probably one of the hardest ways.


edit two:
blender's plugins :

-text2uv baker is included in Blender 2.41, in scripts window, I think.

-The other possibility, Macouno's raytracer, is here
http://www.alienhelpdesk.com/index.php?id=22

-Blender is at www.blender.org


As you see, the main problem is having the software export load into jme.

Indeed I am having issues even with a comercial a very good software like Gile
Lightmaps tend to be a complex stuff.

pd: sorry the grammar and other faults. I don't speak english.

Thanks alot, This will come in handy. GTKRadiant is great but I have been looking for alternatives where you have more control over lightning.

Rik said:

After testing all sorts of changes in the code, I found that commenting out the setCombineScaleRGB(2); line in where the lightmap is added restores the precision.


Out of curiousity, why'd you decide to add that line in the first place??? I mean, it's meant explicitly for reducing the color range when applying a texture filter.. (to speed things up a bit). Did you copy it from an example or something? (as far as I can see no jME example uses it.)

I’m using a port of the Quake3Loader from Xith3D that was posted here http://www.jmonkeyengine.com/jmeforum/index.php?topic=2597.0 The line is in that sourcecode. I can’t tell for sure but it doesn’t seem to be used for the purpose you are describing. My first guess was that it’s used to increase the contrast of the lightmap. It seems to have that effect at least. Now I just increase the contrast of the lightmap before its loaded (to compensate for removing that line) and my problems have disappeared.