Here's the explanation. No I have not coded a render to texture feature into Darkplaces.
All it is is an animated texture. A series of images are swapped over, the scripting of this is handled by a shader.
First you need to get some video. If you're going to use in game footage, you can use the cl_capturevideo to record to an .avi file. I would suggest recording a demo first and then capturing this. You might also want to change settings at this point to get it how you want it to look. As the video will be used as a texture, you need it in a texture size, eg. 512x512, 256x256, 128x128, 64x64. I've used 256x256 for my example and this for use on a big screen. For a small monitor in game, 64x64 would be fine. You can get Darkplaces to set the output video size using:
- Code: Select all
cl_capturevideo_width 256
cl_capturevideo_height 256
Also set the FPS to something sensible. Do not expect this to be the same as you play at in game
. Default is 30 which will use far too much space. 10 is OK for a low quality video, try 15 or 20 if you want things to look better at the expense of disk space.
- Code: Select all
cl_capturevideo_fps 10
Stop the video capture with cl_capturevideo 0.
Now exit the game and look in ~/..nexuiz/data/video. There will be a file called dpvideo001.avi or some higher number. Play it in your video player to make sure the file is OK.
You now need to convert this into a set of JPEG images, one for each frame. Mplayer can do this:
- Code: Select all
mplayer -vo jpeg dpvideo001.avi
This will give you a mass of numbered JPEG images in the same directory. Now is the time you'll realise if your framerate or image size is not actually such a good idea. I hope you a few gigabytes free if you've not really thought things through.
If you want to do any kind if image editing, do it now.
You should also now do your cutting to get rid of segments you don't want, add in stuff from other videos, still images, etc. If you're adding in still images which are just hard edged text, use PNG, not JPEG.
To reduce the size of the images I would strongly recommend using jpegoptim at this point to strip any comments, lower quality setting and optimise huffman encoding. Use JPEG quality sparingly. 75% will be the most you'll want to use.
- Code: Select all
jpegoptim --strip-all *.jpg
jpegoptim -m 75 *.jpg
The two passes are there because of an unusual behaviour that jpegoptim sometimes has.
Now copy all of the files into a textures directory. Eg. ~/.nexuiz/data/textures/[mapname]/. You now also need to rename all of the files and append _gloss to them so that they are used as a gloss map. You want the screen to glow afterall, if you use them as basic textures, it'll look crap.
Now you need a dummy texture to use as the base colour of the screen for the gloss map to be applied to. Create a 1x1 grey PNG into the same textures and create a copy of it that corresponds to each gloss map you have just created. The grey that you use influences the brightness of the screen. You can adjust this later.
Your directory listing should look something like this:
- Code: Select all
-rw-r--r-- 1 ed root 7731 2008-09-21 23:01 00000202_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000202.png
-rw-r--r-- 1 ed root 7772 2008-09-21 23:01 00000203_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000203.png
-rw-r--r-- 1 ed root 7651 2008-09-21 23:02 00000204_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000204.png
-rw-r--r-- 1 ed root 7623 2008-09-21 23:01 00000205_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000205.png
-rw-r--r-- 1 ed root 7785 2008-09-21 23:01 00000206_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000206.png
-rw-r--r-- 1 ed root 7573 2008-09-21 23:01 00000207_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000207.png
-rw-r--r-- 1 ed root 7482 2008-09-21 23:02 00000208_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000208.png
-rw-r--r-- 1 ed root 7529 2008-09-21 23:01 00000209_glow.jpg
-rw-r--r-- 1 ed root 140 2008-09-21 22:39 00000209.png
If there is a way to use a texture as it's own gloss map that would be much better as it would mean no need for the dummy images.
You now need to write a shader, here is an example:
- Code: Select all
// Video screen shader
textures/[mapname]/video001
{
qer_editorimage textures/[mapname]/00000202_glow.jpg
q3map_lightimage textures/[mapname]/00000202_glow.jpg
surfaceparm nomarks
q3map_surfacelight 400
{
map textures/[mapname]/00000201.jpg
animmap 10 textures/[mapname]/00000202 textures/[mapname]/00000203 textures/[mapname]/00000204 textures/[mapname]/00000205 textures/[mapname]/00000206 textures/[mapname]/00000207 textures/[mapname]/00000208 textures/[mapname]/00000209
}
{
map $lightmap
blendfunc filter
rgbGen identity
tcGen lightmap
}
}
The animap value gives the FPS for the video to be played at. You can vary this to change the speed of the video. After this list all of the images to cycle through in sequence.
Now if you use the video001 shader in your map and compile it, you should get full motion video in game.
Ways to improve it:
You might want to add some kind of watermark to your images. You could for instance add 'Replay' to alternate half second segments of video so that it looks like a replay of a previous amazing frag.
You could also grab the sound from the video and put it coming from a speaker or pair of speakers for stereo near the screen in the map.
If the video you export from Darkplaces would be in a lossless format, the image quality would be improved in the JPEG images as there would be no transcoding artefacts.
I have not seen any way of setting different display times for different images within an animated sequence. If that is possible then holding a still image would be much better. Currently you just have to have multiple copies of it as different frames. This may take more memory but will not greatly increase the size of the PK3 as long as your ZIP compression program is any good.
As textures are loaded on the level load there is no way of updating the images from the current game. This would require render to texture. If that did become a possibility in future I would also suggest not using this makeshift JPEG method and instead being able to run a .dem file to a texture.
I'll update this thread as some kind of howto.
by Ed » Sun Sep 21, 2008 10:29 pm 
