Q3Map2 will recognize either _blocksize or blocksize, but prefixing the keys with the underscore character ( _ ) is the preferred method. For lists & definitions of previous keys, please consult your users manual or this list.
http://shaderlab.com/mapcenter/q3map/cel_dm17.jpg
In order for celshading to work properly, you must use -meta when compiling the BSP.
The funny little nonplanar/shadeangle/invert/offset nonsense in cel.shader is what makes it work properly.
You'll know when it's working when it starts taking about 10-20x as long to make the BSP.
// ink shader for maps
// to use, add “cel” to shaderlist.txt
// add a “_celshader” key to worldspawn entity with a value of “cel/ink”
textures/cel/ink
{
qer_editorimage gfx/colors/black.tga
q3map_notjunc
q3map_nonplanar
q3map_bounce 0.0
q3map_shadeangle 120
q3map_texturesize 1 1
q3map_invert
q3map_offset -2.0
surfaceparm nolightmap
surfaceparm trans
surfaceparm nonsolid
surfaceparm nomarks
//deformVertexes wave 100 sin 2.0 0 0 0
//cull back
{
map gfx/colors/black.tga
rgbGen identity
}
}
(ydnar) OK, got misc_model surfaces celshaded. They look for a celshader in their entity, then fall back to worldspawn.
(RR2DO2) what is your worldspawn key?
(ydnar) _celshader
Doing this on a large map can be time consuming. Celshading is a trick that Jet Set Radio pioneered in video games. It's a simple technique for simulating ink outlines around 3d objects. The ink drawsurfs are huge non-planar black meshes, and the “ink” drawsurfaces are a big non-planar continuous mesh. The metasurface merger solves all the discontinuity issues. However, celshading demands an absolutely anal mapper.
h0rst-ds) wtf is celshading
RR2DO2) http://www.gamedev.net/reference/programming/features/celshading/
RR2DO2) cel-shading
ydnar) hmm, gonna make it per-entity, so you can have func_groups w/o ink
ydnar) ok, flatshading is working. doing this in 3 parts: Flatshading mode, to force everything to solid average texture color. Then cel-surfaces. Then lighting fixups, for cartoon style lighting. Nifty thing, though, is that it can be applied to any map.
RR2DO2) hmm, that geometry competition… if you use a detail texture, and a white layer that you color through the shaders rgbGen, you have unlimited color.
BirdDawg) does _celshader make the bsp stage work differently? It's taking forever all of a sudden. Does it just kill the console?
ydnar) Yeah. The metasurfaces stage for the “ink” takes long time.
BirdDawg) ok ydnar
ydnar) gonna have to go through the shader pipeline and remove the textures/* dependency
RR2DO2) just merge Q3Map with synapse
ydnar) in due time. no real desire to start putting c++ into Q3Map, it's unstable enough as is.
rr2do2: It is very easy for level designers to add this to the map. It’s a 2-step thing. First you add a _foghull shader key to your worldspawn, pointing to the shader you want to use as your foghull. Make sure this is a sky shader, the textures it point to can be very small ones, and will have the fog color.
Enough people kicked me.
http://www.shaderlab.com/mapcenter/q3map/foghull_01.jpg
http://www.shaderlab.com/mapcenter/q3map/foghull_02.jpg
http://www.shaderlab.com/mapcenter/q3map/foghull_03.jpg
http://www.shaderlab.com/mapcenter/q3map/foghull_04.jpg
http://www.shaderlab.com/mapcenter/q3map/foghull_05.jpg
http://shaderlab.com/q3map2/q3map_ydnar_2.zip
http://shaderlab.com/q3map2/q3map_ydnar_2_readme.txt
Readme
Added _foghull worldspawn key. Use in conjunction with
"_farplanedist" to set up fogged maps with max visibility distance
and no HOM.
The last screenshot demonstrates a normal skybox as the foghull.
Also in is q3map_normalmap support for bumpmapping of lightmaps. Use with
lightmapped terrain or high resolution lightmaps for best results. Format: q3map_normalmap
path/to/image.tga
Note this version will generate larger visdata on certain maps. This is
because the BSP is split on BLOCKSIZE in Z as well as X and Y. This is to make
the far plane culling more effective.
[CODE]
textures/shaderlab_foghull/fog_black
{
qer_trans 0.75
surfaceparm nolightmap
surfaceparm nonsolid
surfaceparm noimpact
surfaceparm trans
surfaceparm fog // !!FOG!!
fogparms ( 0.0 0.0 0.0 ) 512
}
textures/shaderlab_foghull/foghull_black
{
qer_trans 0.75
surfaceparm nolightmap
surfaceparm nonsolid
surfaceparm noimpact
surfaceparm trans
surfaceparm sky // !!SKY!!
skyparms textures/shaderlab_foghull/hull 0 -
}
[/CODE]
Special props to RR2DO2, as this is his code. I simply rearranged it and
stuffed it under the hood.
y
Oh, and in case nobody's figured this one out yet, the reason that fog
breaks at the origin when you cover an entire map with it is because the fog
brush entirely encompasses the map, with no exposed face.
X = 0 is the break point, which also happens to be the first plane in the BSP,
as well as the default in/out of fog boundary for fog volumes.
Leave a little "chimney" somewhere on your structural hull that the
fog peeks through and the fog will work properly across the map:
"-" = fog
"_" = hull
_
----|-|-------
____| |_______
Found this out testing the foghull stuff this eve...
[]
[]
_lightmapscale scales the samplesize. It’s a little more flexibility. It’s an entity key with a floating-point value. It scales the default samplesize for a given surface belonging to that entity. For instance, “_samplesize 2” on the worldspawn entity sets the sample size for every brush in the world to 32. Brush models, such as func_doors or func_statics, are left as-is. They need their own unique “_lightmapscale” key to affect them.
In tests, most maps look just fine with “_lightmap scale 2.0”. This makes the lightmap load (as well as compile time) roughly 1/4 of what it used to be. Fewer lightmap texels = faster compiles = smaller bsp = faster download. Another benefit is that you can set up func_group entities with different _lightmapscale values. Take for instance a floor underneath a complex grate, with dramatic shadows. You’d use “_lightmapscale 0.25” on a func_group entity that was made up of the brushes on the floor. What most mappers don't understand, is that on very complex maps, a lot of the bsp’s file size results from the lightmaps. Very often, there are large amounts of wasted space in areas with very little shadow detail. Those areas are ideal candidates for coarser lightmaps (higher lightmapscale).
To recap:
_lightmapscale 0.5 = 8 unit samples
_lightmapscale 1.0 = 16 unit samples (default)
_lightmapscale 2.0 = 32 unit samples
“_lightmapscale” key for brush entities (worldspawn, func_*).
This lets a mapper scale the lightmap samplesize per-entity. For large constructions, a value of 2.0 or 3.0 is just fine, and keeps the bsp size down and compile times low. For those areas that you want to have high-detail shadows in, make a func_group, and use a value of 0.25 or so. It will scale the samplesize value for the surface's shader (default 16) or the samplesize argument.
Note: A surfaces' samplesize is now stored in the bsp. This change makes bsp's generated from this version incompatible with all other Q3Map.exe’s. The upside is that samplesize (N) is no longer necessary on the light stage. This feature is necessary to support the “_lightmapscale” key.
(sedric) will mapmodels be lightmapped soon? I think that would be a great feature.
(ydnar) nope, never.
(sedric) hmmm...ok, have to wait for doom i guess.
(ydnar) well, yeah, but there are severe restrictions. meshes have non-convex non-planar not-easily-integrable geometry, and…
for misc_models (1.0 = default)
This was for proper RTCW support, and is available for Quake3 maps as well. It lets you scale mapmodels in the world, getting around the .md3 size limitation. The next build of GTKRadiant has Spog's code built-in to support this, so you can see what effect scaling has.
[]
[]