Vis and Func_Rotating, Vertex lighting and final compile ?'s

(MountinYew) #1
  1. Func_Rotating. I have an area in my RA3 map (ra3map14) that is constantly visible (if you use r_showtris) throughout the entire map. Through several floors, walls, etc.

I’ve tried compiling using the default Q3Map that’s in GTKRadiant. I’ve tried compiling using the Q3Map2 that’s installed in GTKRadiant. I’ve downloaded the latest Q3Map2 and compiled outside of Radiant.

I’m not doing a -fast or anything like it. In fact i’ve been TRYING to do a final compile (more on that later).

Is this a bug? Is there a way to disable this? Help please. I have testers waiting on me, and the next patch to RA3 will include this revised version of RA3Map14.

  1. Vertex Lighting. Q3Map2 is amazing at how fast it accomplishes excellent lighting compared to Q3Map. Q3Map however blows Q3Map2 out of the water when it comes to vertex lighting. In Q3Map2, brush faces end up with inexplicable “shadows” in impossible places. It’s darker than the the q3map vertex lighting as well.

Are there any specific remedies I can try to improve the vertex lighting in Q3Map2? I’m not looking forward to a 2 day compile using Q3map - but I may have to if I can’t resolve the poor vertex lighting of q3map2.

  1. Final Compiles. I’ve searched Google, I’ve read the manual, looked at the FAQ, searched MB’s (here and at Quake3World) and can find no examples of a “uber” compile or final compile command line.

There are several provided “examples” in Q3Map2GUI, and Q3MapToolz, however, I have no way of knowing if any of these are the “final” compile example i’m looking for. Reading the manual, and other resources have helped “somewhat” with my attempt at this, but there are several switches that may indicate that they be included in a final compile. Yet when I try to research the switches, it’s either techno speak, which leaves me more confused than before - or they are notated something like “need to explaing this one more”, etc.

Time really isn’t an issue, if I know that what I’m doing is gonna be the best q3map2 can do, I’m just looking for the best framerates and most realistic and even lighting possible.

Any help would be greatly appreciated.

(ydnar) #2

  1. If an entity crosses too many vis clusters, it is flagged as “broadcast” and is therefore visible throughout the entire map. If you really, really want to hide it from other parts of the map, assuming it’s a complex entity, then simplify the structural hull around or near the func_rotate ent. You may have to shift the map so the entity doesn’t cross a blocksize boundary as well.

  2. Q3Map2’s vertex lighting is derived from the lightmap data. It’s darker than Q3Map’s because shadows are taken into account. Dark vertexes are usually a symptom of sloppy brushwork. Find the offending dark verts and see if they’re buried inside other geometry. If so, clip the brushes so the verts are exposed to air & light.

Alternatively, add a _minvertexlight key with a value between 1 and 20 to worldspawn.

3, Final compiles really depend on what kind of map you have. Maps with large amounts of non-planar lightmapped geometry, for instance, don’t look as good when compiled with lightmap filtering. Some maps don’t respond well to radiosity. That said, for a final compile on an agerage map, I’d use:

-light -fast -samples 3 -bounce 8

If you want softer, filtered lighting, substitute -filter for -samples 3.

y

(MountinYew) #3

K, guess i’m still a newb at this, but what is, and how do i find a “blocksize boundary”, and how would I find or view “vis clusters”?. As to the size of the func_rotating, here is a SS of it (it’s only value is speed: 40):

Would changing this worldspawn value/key pair have any effect on the func_rotating getting flagged? (_blocksize)

Thanks for the insight re: the shadows in vertex lighting and the _minvertexlight key.

Which brings up another ? When using the -fast switch for lighting, even with bounce: 8, the map ends up around 30% darker for lightmap. Granted, I think it looks better and more realistic this way, but players would SURELY complain. Is there a switch or a worldspawn entity like the vertex one I can use to combat this? When not using the -fast switch the lighting is perfect, but the compile times hurt…heh.

Thank you for the final compile response!

Are there any -switches that make the compile take longer, but result in better vis’? I’m not sure, but it seems like the q3map2 map version seems to draw more of what can’t be seen…sooner than q3map. The only reason I ask is that hinting a map, even after reading MANY tutorials on the subject always reduces me to a gibbering pile of gibs.

No offense to the more technical peeps like you, but alot of the times, people with the knowledge don’t “dumb down” their explanations enough, and those of us without the brains for math, etc. feel like were listening to a Carmack discussion of 3D engine technology.

Example: “Maps with large amounts of non-planar lightmapped geometry”

Huh? My best guess is that means maps without many straight walls/ceilings/floors?

Anyhoo, just wanted to say thanks and get some clarification.

(Codey) #4

Maybe I can say something here that will get you on the right track without stepping on toes?

“blocksize boundary” is where a portal is located between two blocks at a resolultion of the _blocksize parameter in worldspawn, so for example if you had “_blocksize 512 512 512” in worldspawn and the mid point of your func_rotating is at say 2048, 1024 or so on, it will line up on the “blocksize boundary” by default.

Also if you have structural brushwork nearby cutting up the blocks, creating more portals, that will cause the same “blocksize boundary” problem.
you could compile your map with the “-saveprt” option on, and then use the portal viewer in gtk to see where that func_rotating crosses boundaries and try to illiminate them, adjust the “blocksize” parameter in worldspawn, move the rotate section of the map a bit or a combo.

:beer: Codey

(ydnar) #5

The -light -fast mode isn’t for test compiles. It’s a valid, usable lighting mode for final compiles.

From your screenshots, it appears that you map is largely, nee mostly, lit by shader lights–which are exactly the kind of lights that -fast optimizes. See, the deal is this:

The -fast code adds an “envelope” around the max area that a shader light can affect. It’s a sphere that simulates the distance from which the light is so dim, it’s under 1 unit of brightness. Anything beyond that won’t be lit up.

You can try -areascale on the commandline, after -fast, to scale up the brightness of your shader lights like so:

-light -fast -areascale 1.5 -samples 3 -bounce 8

The -bounce 8 bit is optional. Give it a go and see if larger/smaller values give you what you want. Alternatively, increase the amount of surfacelight your lights give off in the shaders.

y

(hummer) #6

I’m guessing this is all done at compile time? For example, if we’ve exported the lightmaps and brightened them manually, then imported them back into the map, the vertex lighting is unaltered, correct?

(Matt) #7

MountinYew, I’ve run into the problems of the Q3Map2 vertexlight myself. The visual artifacts over some areas of my map forced me to basically compile in fullbright, to emulate the old vertexlight. (Even though I’m in extreme opposition to the use of vertexlight, as it is a cheat, or a shadow hack.)

To do this, set your _minvertexlight to 255.