I just compile a map I’m working on with 2.2.32, and I notice that all light shader appear to do the same effect as I would have put a light entities above the middle of them.
I find that kinda strange, since it always appear well in the old q3map (RavenSoft EF version) as a whole surface lighting.
Also, all light shader don’t show any burn mark when I shot them, while on the old q3map, I can.
What’s wrong?
Going to get pict of a old compile…
Here we are…
Q3Map2.2.32 :
Q3Map 1.2 (RavenSoft EFRadiant)
As you can see, there is a huge difference.
I know Q3Map2 support bumpmapping+light bouncing, but I won’t use it if I get the same effect as light entities (Thing I hate)
Check the shader to see if it has “surfaceparm nomarks.” If it does, then remove it–that’s what’s preventing marks from showing up on the surface.
Also, if you want the light surface to be more uniformly lit, add “q3map_lightsubdivide 64” or similar to the shader to chop up the light emission from the surface.
EF Q3Map might be based on old source code–where surfaces were subdivided to a default of 64, rather than the Quake 3 standard of 999 units.
y
No, I know surfaceparm nomarks, and I didn’t use it, but it’s not a big deal, only annoying, while the lighting is really bothering me.
Are you trying to tell me that it’s impossible for Q3Map2 to get a light cast as uniformily as the Raven q3map?
And if the Raven is subdivided at 64, like you said, what about q3map2? Not divided at all?
I will try that q3map_ key with all my light shader and do an other compile… 
Damn! I’m not doing a full light radiosity compile, but it’s already damnly slower than the Fast_Vis of Raven’s Q3Map…
Ok…
After 50 mins of “IlluminateRawLightmap” (3383 sec)
I get that :
The lightmap seam smoother and the light cast by the light shader seam more uniform.
However, the range of the light cast seam a lot smaller, and the lightmap darker.
I will have to raise every light shader power. :disgust:
Is it possible to control the light cast range WITHOUT changing the power of the light?
Example, I have a shader that cast light to 256 unit far with a power of 500… Is it possible to make it light up to 512 without changing the 500 value on the q3map_surfacelight?
Damn! It was a lot slower than anything I was used to with Raven’s one.
Of course, a few bump map are already on the map.
It will take me week of compile on the final one! :eek2: :eek3:
Why Q3Map2 give a .bsp close to 1 Mb smaller than Raven’s one?
Is it the way the lightmap is stored?
I don’t understand how Q3Map2 do the litghmap… Why I got point light on the shader? It’s not using the whole shader surface to cast light?
I wounder if I make a texture that is a gradiant from red to green that cast light if I will have a lightmap following that gradiant or only a average of all pixels.
What’s the difference between
“q3map_lightsubdivide 64”
and
a small tesssize?
Hmm… tesssize maybe causes the engine to draw too many triangles unneccesarily?
either way, I’ve noticed that the shader that emits light doesn’t cast light back at itself. That would be cool if it did, y. I already tried that backsplash keyword, but it did nada.
TessSize is use to subdivise the brush in many polygone…
If I understand well that lightsubdivide divise the light source in many sources. But I still don’t understand why Q3Map use point light (Even with a high number of them) to cast light. Of course, it’s highly possible that I don’t understand because I don’t have all the info in hand…