Irregular shadow buffer, for solid OSA case, suffered aliasing. This caused
by optimized storage of shadow factors in 1 pixel (averaged for all sub
samples). That didn't work well really...
Now the code uses same method as for transparent faces, storing results for
each sample.
http://www.blender3d.org/cms/Shadow_buffer__Halfway.786.0.html
Simply said: by using the average of the nearest and 2nd nearest Z value
in Shadowbuffers you can reduce bias errors very well.
For backwards compatibility it is a new buffer type though.
Full log:
http://www.blender3d.org/cms/Irregular_Shadow_Buffe.785.0.html
In short: this is a shadow buffer approach that always results in crispy
shadows, independent of lamp buffer size or zoom level. This shadow buffer
system also supports transparent shadow.
This is part of work on refreshing Shadow Buffers in Blender. You now can
choose of two types (Classical, Irregular). More types will follow. Also
quality issues for Classical shadow buffers are going to be reviewed,
especially to solve the lousy Biasing.
For the CVS log record; it is based on articles:
Gregory Johnson et al, University of Texas, Austin. (Regular grid method).
Timo Aila and Samuli Laine, Helsinki University of Technology. (BSP method).
Auto-clip Lamp Buffer
Setting a good range for clipping start/end for Lamp buffers is important
for good quality shadow (depth details). That can be quite a hassle, when
many lamps or animated objects are involved.
This option allows to have the clipping range calculated based on the
visible vertices in the spotbundle. For clip start and clip end it can
be set individually. Typically the clip start defines quality most.
The shadow buffer 'bias' value is corrected for this automatic clipping
too, to ensure that ranges that differ give same biasing appearance.
(If this wasn't done, you would see lighted areas become darker or
lighter, or even artefacts, when the range changes suddenly
NOTE: since it only checks for vertices, be aware that large planes can
give errors.
Implementation note: zbuffer values are non-linear (1/z) because that
allows linear interpolation while filling scanlines. That's the main
reason for the precision to be highest close to the eye (or lamp).
It's even a useful feature, since you want details to be precise
when they're closeby.
Since these values are also in the -1 to 1 range, using floats here
wouldn't solve problems a lot. Maybe trying a 64 bits Z once might
be an interesting coding job.
images (like used for rendering icons).
When working during Orange on new render pipeline, I've left this topic
alone for a while... subpixel precision testing is very time consuming and
needs concentration for a while. :)
This commit brings back precision as it was for 2.41. Below a short
explanation of the solved issues.
- the window matrix for rendering is kept constant during all OSA passes,
this to ensure clipping happens for each pass identically.
- a subpixel offset is only applied on filling in the z-buffer
- this offset is inverse corrected for shadepixel code, only on 2 places
Another nasty issue is that for filtered rendering (gauss etc), the tiles
(or entire image) is temporally increased 2 pixel in size. This caused a
'dark' (or sky color) edge on the rendering. During Orange that was solved
with a hardcoded clipping offset value, which only corrected for larger
pictures (like > 500 pixels in size).
Now this clipping offset is correctly calculated, based on render size.
Last issue: the view border in 3d window was calculated using integers,
giving small errors in display too. Now it uses float, so visually the
view border is more close to what a render shows.
- thread render stores per thread and per lamp the last intersected
shadow face
- the Isect struct, for intersections, could use a couple of extra
zeros on start.
Thread render error: a flag was stored in read-only data to indicate
whether top or bottom hemisphere of sky was rendered. That can't work
with tiles (but did work when scanlines were threads).
Code to allow "Env" material to mask out ztransp gave bad AA on edges of
solid faces, when transparant was behind it.
Recoded "Env" to use index -1 in the polygon index buffer, and restored
code that caused the bad AA.
"Backbuf" image render option is back :)
Nicer coded, using Image texture functions.
If you want 100% reliable pixel to pixel accuracy you have to use
compositing. (Old Backbuf didn't do this accuracy either btw).
This commit brings back:
- Field Render
- MBlur Render (old style)
- Border render with or without cropping
Note: Field Render is not supported in Compositor yet. Blurring or filter
will destroy field information.
Both MotionBlur as Field render are done before Compositing happens.
Fixes:
- The "Save Buffers" option only worked on single frame renders, not for
Anim render.
- Found an un-initalized variable in Render initialize... this might have
caused the unknown random crashes with render.
Code restructure:
Cleaned up names and calls throughout the pipeline, more clearly telling
what goes on in functions.
This is visible in the updated first image of the Wiki doc:
http://mediawiki.blender.org/index.php/BlenderDev/RenderPipeline
newline missing at end of file fixes:
TypedConstraint.h WheelInfo.h RaycastVehicle.h VehicleRaycaster.h
CcdPhysicsEnvironment.cpp
radiance_hdr.c fixed the following warning by changing type of local variable:
radiance_hdr.c:357: warning: pointer targets in passing argument 3 of
‘fwritecol rs’ differ in signedness
edgeRender.c,edgeRender.h same thing changed type of local vars to get rid
of warnings about signedness
RAS_OpenGLRasterizer.cpp removed unused variable unit line 1295
Kent
- added a zoom factor for Planar Environment Map, allowing to zoom in or
out on the reflected object. The zoom is corrected when rendering, so it
just gives control over the resolution.
- Planar maps don't cycle anymore, but only render the front plane, using
standard image texture extend mode.
- threaded rendering is back in envmap render
allowing to use it for planar mirrors. Enable it with the new "Plane"
option in the Environment Map Panel.
Current default is to render the cube side that points to the positive
Z axis direction. To make it work, it uses the same image for all
other cube sides, so it will 'wrap around'.
Also made maximum resolution for environment map to be 4096x4096 now.
- Bug fix: the upper tile in a collumn for Panorama render didn't put the
mainthread to sleep properly. Now panorama renders 25% faster if you had
set Y-Parts to 4.
- Enabling Compositing in Scene for first time now adds a "Composite" node
too, so render output gets applied.
- An attempt to render with "Do Composite" without "Composite" node will
throw an error and stops rendering. In background mode it will just not
render at all, and print errors.
- Errors that prevent rendering now give a popup menu again.
- Having MBlur or Fields option on will now normally render, but with an
error print in console (not done yet...)
The old implementation was added quite hackish (talking about 10 yr ago).
You also had to make a small image slice, which was extended Xparts in
size. That also required to adjust the camera angle. Very clumsy.
Now; when enabling the Panorama option, it will automatically apply the
panorama effect on the vertically aligned tiles. You can just enable or
disable the "Pano" button, to get a subtle lens effect like this:
(without pano)
http://www.blender.org/bf/rt.jpg
(with pano)
http://www.blender.org/bf/rt1.jpg
For Panorama render, the minimum slice size has been hardcoded to be 8
pixels. The XParts button goes up to 512 to allow that. In practice,
rendering 64 slices will already give very good images for a wide angle
lens of 90 degrees, the curvature of straight lines then is equal to
a circle of 256 points.
Rendering a full 360 degree panorama you do by creating an extreme wide
angle camera. The theory says camera-lens 5 should do 360 degrees, but
for some reason my tests reveil it's 5.1... there's a rounding error
somewhere, maybe related to the clipping plane start? Will look at that
later. :)
Also note that for each Xpart slice, the entire database needs to be
rotated around camera to correct for panorama, on huge scenes that might
give some overhead.
Threaded render goes fine for Panorama too, but it can only render the
vertically aligned parts in parallel. For the next panorama slice it has
to wait for all threads of the current slice to be ready.
On reading old files, I convert the settings to match as closely as
possible the new situation.
Since I cannot bump up the version #, the code detects for old panorama
by checking for the image size. If image width is smaller than height, it
assumes it's an old file (only if Panoroma option was set).
the ones that get changed within threads, to communicate with the main
thread.
(Part of the long quest to get threaded render safe, especially in Linux)
passes in single file. Code is currently disabled, commit is mainly to
have a nicer method of excluding OpenEXR dependency from render module.
This should compile with disabled WITH_OPENEXR too.
Reason why EXR is great to include by default in Blender is its feature
to store unlimited layers and channels, and write this tile based. I
need the feature for saving memory; while rendering tiles, all full-size
buffers for all layers and passes are kept in memory now, which can go
into 100s of MB easily.
The code I commit now doesn't allocate these buffers while rendering, but
saves the tiles to disk. In the end is it read back. Overhead for large
renders (like 300 meg buffers) is 10-15 seconds, not bad.
Two more interesting aspects:
- Blender can save such multi-layer files in the temp directory, storing
it with .blend file name and scene name. That way, on each restart of Blender,
or on switching scenes, these buffers can be read. So you always see what was
rendered last. Also great for compositing work.
- This can also become an output image type for rendering. There's plenty of
cases where you want specific layers or passes saved to disk for later use.
Anyhoo, finishing it is another days of work, and I got more urgent stuff
now!
- Button option "Single" in render-layer panel will enable to only render
the currently indicated render-layer. It will also skip compositing.
- Brought back the 'Local View' render. This will only render the visible
objects, but with lights from the original view-layers.
To make the option useful, it also temporal enables 'Single', which has
the a disadvantage that you need to set the correct render-layer.
It is a bit a tricky option though... since its quite invisble and
confusing for people who don't know the feature. This might become either
a button in 3d header, or use a popup requester to confirm, or... will
need to think over!
At least; both options display in render window a text to denote the option.
large scenes... this because it has to make 3 entire databases to find
the vertex-speed to previous and next frame. Even though most of the
prev/next database was freed, the parts I kept were spread all over
memory.
This commit copies from the prev/next database only the two screen aligned
speed vectors and stores that in temporal per-object structs. Even whilst
it takes more memory, it then can free the entire database, making space
for the next database to be built.
Tests reveiled it saves quite some... well, if you want to believe the
'virtual memory' total unix gives... :)
sampling have been activated for UI. Check the pictures here:
http://www.blender.org/bf/filters/index2.html
I also did do tests with anti-aliased shadowbuffers:
http://www.blender.org/bf/filters/index3.html
But this needs more thinking over still...
I noticed still several cases where the Imbuf library was called within a
thread... and that whilst the Imbuf itself isn't threadsafe. Also the
thread lock I added in rendering for loading images actually didn't
work, because then it was still possible both threads were accessing the
MEM_malloc function at same time.
This commit nearly fully replaces ImBuf calls in compositor (giving another
nice speedup btw, the way preview images in Nodes were calculated used
clumsy imbuf scaling code).
I've also centralized the 'mutex' locking for threading, which now only
resides in BLI_threads.h. This is used to secure the last ImBuf calls
I cannot replace, which is loading images and creating mipmaps.
Really hope we get something more stable now!
as triangles, with a tag bit to denote which triangle was which part of
the quad. That was hardcoded bit 0x800000, which allows a maximum of
about 8 million quads...
I've made this a nice #define, set to be 16 times larger. So, now the
facejunkies can go up to 128 Million faces, were it not that this will eat
up a load of memory!
I only have 1 Gig in this machine. A test with 9M vertices and 7.5M quads
eats up 912 MB of memory already. If this becomes a real issue, I know
tricks how to make the vertices 20 bytes smaller, and faces 4 bytes, which
would in the above case save about 200 MB. Not much... but probably worth
the try? A much better method is of course 'bucketing' the renderdata per
tile. It's a spec of the render recode, but not a quicky to add.
Also: bug fix in curve code. There was a short counter still, crashing on
large curves with resol set to 1024 :)
- ZTransp render now also delivers Z values and Speed vectors in passes
Note that speed vectors accumulate within a pixel to store the minimum,
so rendering ztransp on top of a non-moving plane won't give speed...
Best results you get is by rendering it in a separate layer.
The Z value stored is the closest visible transparent face in the pixel.
Fixes:
- Render to 'spare page' has been enabled again. Because of the strict
separation of Render and UI, but especially because a 'render result' now
can consist of unlimited images, I've not made this a Render feature.
Instead, the render-window itself stores the 'spare' image... I also
had to change the convention for it a bit.
Now, instead of having two "render buffers" (which was a render feature),
the RenderWindow will store each previous frame on a re-render. This
storing will only start after you've pressed 'Jkey' once, but then always
will happen for as long the rendered image is same size as previously.
For clarity, I've also renamed the window title, to 'previous frame'.
- RenderWindow shows alpha again on Akey
- Display of the Zvalues in ImageWindow has been tweaked. White now denotes
closest, and the color range goes from camera clip-sta to clip-end.
- Bugfix: on splitting/merging/duplicating windows, the 3D Previewrender was
not always freed correctly, potentially causing crashes or memory leaks.
After a couple of experiments with variable blur filters, I tried
a more interesting, and who knows... original approach. :)
First watch results here:
http://www.blender.org/bf/rt0001_0030.avihttp://www.blender.org/bf/hand0001_0060.avi
These are the steps in producing such results:
- In preprocess, the speed vectors to previous and next frame are
calculated. Speed vectors are screen-aligned and in pixel size.
- while rendering, these vectors get calculated per sample, and
accumulated in the vector buffer checking for "minimum speed".
(on start the vector buffer is initialized on max speed).
- After render:
- The entire image, all pixels, then is converted to quad polygons.
- Also the z value of the pixels is assigned to the polygons
- The vertices for the quads use averaged speed vectors (of the 4
corner faces), using a 'minimum but non-zero' speed rule.
This minimal speed trick works very well to prevent 'tearing' apart
when multiple faces move in different directions in a pixel, or to
be able to separate moving pixels clearly from non-moving ones
- So, now we have a sort of 'mask' of quad polygons. The previous steps
guaranteed that this mask doesn't have antialias color info, and has
speed vectors that ensure individual parts to move nicely without
tearing effects. The Z allows multiple layers of moving masks.
- Then, in temporal buffer, faces get tagged if they move or not
- These tags then go to an anti-alias routine, which assigns alpha
values to edge faces, based on the method we used in past to antialias
bitmaps (still in our code, check the antialias.c in imbuf!)
- finally, the tag buffer is used to tag which z values of the original
image have to be included (to allow blur go behind stuff).
- OK, now we're ready for accumulating! In a loop, all faces then get
drawn (with zbuffer) with increasing influence of their speed vectors.
The resulting image then is accumulated on top of the original with a
decreasing weighting value.
It sounds all quite complex... but the speed is still encouraging. Above
images have 64 mblur steps, which takes about 1-3 seconds per frame.
Usage notes:
- Make sure the render-layer has passes 'Vector' and 'Z' on.
- add in Compositor the VectorBlur node, and connect the image, Z and
speed to the inputs.
- The node allows to set amount of steps (10 steps = 10 forward, 10 back).
and to set a maximum speed in pixels... to prevent extreme moving things
to blur too wide.
- RenderLayers with 'view layers' set, now also take visible lights into
account. Works just like for scene layer settings.
- On ESC from render, compositing (if set) is being skipped too
- While rendering with multiple RenderLayers it will end with a display
of the current RenderLayer (as in Scene buttons)
- Enabled Groups to execute in Compositor. They were ignored still.
Note; inside of groups nothing is cached, so a change of a group input
will recalculate it fully. This is needed because groups are linked
data (instances use same internal nodes).
- Made Composit node "Viewer" display correctly input for images with
1/2/3/4 channels.
- Added pass rendering, tested now with only regular Materials. For
Material nodes this is quite more complex... since they cannot be
easily separated in passes (each Material does a full shade)
In this commit all pass render is disabled though, will continue work on
that later.
Sneak preview: http://www.blender.org/bf/rt.jpg (temporal image)
- What did remain is the 'Normal' pass output. Normal works very nice for
relighting effects. Use the "Normal Node" to define where more or less
light should be. (Use "Value Map" node to tweak influence of the
Normal node 'dot' output.)
- EVIL bug fix: I've spend almost a day finding it... when combining AO and
mirror render, the event queue was totally screwing up... two things not
related at all!
Found out error was in ray-mirror code, which was using partially
uninitialized 'ShadeInput' data to pass on to render code.
- Another fix; made sure that while thread render, the threads don't get
events, only the main program will do. Might fix issues reported by
people on linux/windows.
- Live scanline updates while rendering
Using a timer system, each second now the tiles that are being processed
are checked if they could use display.
To make this work pretty, I had to use the threaded 'tile processor' for
a single thread too, but that's now proven to be stable.
Also note that these updates draw per layer, including ztransp progress
separately from solid render.
- Recode of ztransp OSA
Until now (since blender 1.0) the ztransp part was fully rendered and
added on top of the solid part with alpha-over. This adding was done before
the solid part applied sub-pixel sample filtering, causing the ztransp
layer to be always too blurry.
Now the ztransp layer uses same sub=pixel filter, resulting in the same
AA level (and filter results) as the solid part. Quite noticable with hair
renders.
- Vector buffer support & preliminary vector-blur Node
Using the "Render Layer" panel "Vector" pass button, the motion vectors
per pixel are calculated and stored. Accessible via the Compositor.
The vector-blur node is horrible btw! It just uses the length of the
vector to apply a filter like with current (z)blur. I'm committing it anyway,
I'll experiment with it further, and who knows some surprise code shows up!
-> Rendering in RenderLayers
It's important to distinguish a 'render layer' from a 'pass'. The first is
control over the main pipeline itself, to indicate what geometry is being
is rendered. The 'pass' (not in this commit!) is related to internal
shading code, like shadow/spec/AO/normals/etc.
Options for RenderLayers now are:
- Indicate which 3d 'view layers' have to be included (so you can render
front and back separately)
- "Solid", all solid faces, includes sky at the moment too
- "ZTransp", all transparent faces
- "Halo", the halos
- "Strand", the particle strands (not coded yet...)
Currently only 2 'passes' are exported for render, which is the "Combined"
buffer and the "Z. The latter now works, and can be turned on/off.
Note that all layers are still fully kept in memory now, saving the tiles
and layers to disk (in exr) is also todo.
-> New Blur options
The existing Blur Node (compositor) now has an optional input image. This
has to be a 'value buffer', which can be a Zbuffer, or any mask you can
think of. The input values have to be in the 0-1 range, so another new
node was added too "Map Value".
The value input can also be used to tweak blur size with the (todo)
Time Node.
Temporal screenies:
http://www.blender.org/bf/rt.jpghttp://www.blender.org/bf/rt1.jpghttp://www.blender.org/bf/rt2.jpg
BTW: The compositor is very slow still, it recalulates all nodes on each
change still. Persistant memory and dependency checks is coming!
A full detailed description of this will be done later... is several days
of work. Here's a summary:
Render:
- Full cleanup of render code, removing *all* globals and bad level calls
all over blender. Render module is now not called abusive anymore
- API-fied calls to rendering
- Full recode of internal render pipeline. Is now rendering tiles by
default, prepared for much smarter 'bucket' render later.
- Each thread now can render a full part
- Renders were tested with 4 threads, goes fine, apart from some lookup
tables in softshadow and AO still
- Rendering is prepared to do multiple layers and passes
- No single 32 bits trick in render code anymore, all 100% floats now.
Writing images/movies
- moved writing images to blender kernel (bye bye 'schrijfplaatje'!)
- made a new Movie handle system, also in kernel. This will enable much
easier use of movies in Blender
PreviewRender:
- Using new render API, previewrender (in buttons) now uses regular render
code to generate images.
- new datafile 'preview.blend.c' has the preview scenes in it
- previews get rendered in exact displayed size (1 pixel = 1 pixel)
3D Preview render
- new; press Pkey in 3d window, for a panel that continuously renders
(pkey is for games, i know... but we dont do that in orange now!)
- this render works nearly identical to buttons-preview render, so it stops
rendering on any event (mouse, keyboard, etc)
- on moving/scaling the panel, the render code doesn't recreate all geometry
- same for shifting/panning view
- all other operations (now) regenerate the full render database still.
- this is WIP... but big fun, especially for simple scenes!
Compositor
- Using same node system as now in use for shaders, you can composit images
- works pretty straightforward... needs much more options/tools and integration
with rendering still
- is not threaded yet, nor is so smart to only recalculate changes... will be
done soon!
- the "Render Result" node will get all layers/passes as output sockets
- The "Output" node renders to a builtin image, which you can view in the Image
window. (yes, output nodes to render-result, and to files, is on the list!)
The Bad News
- "Unified Render" is removed. It might come back in some stage, but this
system should be built from scratch. I can't really understand this code...
I expect it is not much needed, especially with advanced layer/passes
control
- Panorama render, Field render, Motion blur, is not coded yet... (I had to
recode every single feature in render, so...!)
- Lens Flare is also not back... needs total revision, might become composit
effect though (using zbuffer for visibility)
- Part render is gone! (well, thats obvious, its default now).
- The render window is only restored with limited functionality... I am going
to check first the option to render to a Image window, so Blender can become
a true single-window application. :)
For example, the 'Spare render buffer' (jkey) doesnt work.
- Render with border, now default creates a smaller image
- No zbuffers are written yet... on the todo!
- Scons files and MSVC will need work to get compiling again
OK... thats what I can quickly recall. Now go compiling!
- Image textures use float colors now, when present. Works for mipmap too,
and for AO skycolor (probes)
- Backbuffer option uses float buffers too. Note that rendering OSA will
resample the backbuffer, filtering it... will need to be solved with the
new composit stage
- LMB sampling in image window now shows float color too
+ bugfix in imbuf, filtering for float buffers had an error.
(WIP, don't bugs for this in tracker yet please!)
- New Panel "Layers" in Material buttons, allows to add unlimited amount
of materials on top of each other.
- Every Layer is actually just another Material, which gets rendered/shaded
(including texture), and then added on top of previous layer with an
operation like Mix, Add, Mult, etc.
- Layers render fully independent, so bumpmaps are not passed on to next
layers.
- Per Layer you can set if it influences Diffuse, Specular or Alpha
- If a Material returns alpha (like from texture), the alpha value is
used for adding the layers too.
- New texture "Map To" channel allows to have a texture work on a Layer
- Each layer, including basis Material, can be turned on/off individually
Notes:
- at this moment, the full shading pass happens for each layer, including
shadow, AO and raytraced mirror or transparency...
- I had to remove old hacks from preview render, which corrected reflected
normals for preview texturing.
- still needs loadsa testing!
I've been going over the zbuf.c code, which is indeed very ancient,
with a load of old optimizing and redundant code in use.
Added more 'modern' Span support, which fills per face two arrays
with the scanline information in it. That way you can zbuffer a quad in one
run as well. It was also exactly that code that's copied all over in zbuf.c
For now, to prevent issues for the release, the 'render a quad in 1 run' is
only in use for the strand render. Tests reveil a speedup of about 33%.
Will work on this recode later... which would also result in making zbuf.c
threadsafe.
And: bugfix #3398
When using the new 'render emitter' for particles, the orco array for
particles was accidentally used by mesh too.
- The ortho render recode had a weak method to calculate the Z value of the
render coordinate (shi.co[2]). Worked OK for normal render, but not in
unified, giving big errors in Ortho Unfied render.
Solved with proper math, using face equation a*x+b*y+c*y=d. Dunno why I
didn't do it in first place. :)
- Bug fix#2493. Edge render gave much different result for Ortho. This
was due to overflows in the integer math filtering zbuffer values.
Cleaned it op properly, preventing any integer overflow now.
submitted by Alexander, changes/improvements are:
- Moved to new Panel in Scene buttons "Post Effects". Together with other
postprocessing options, such as Edge render. It is also not called DoF,
this because that's a bit pretending too much then. It's a zblur still!
- Made it render Alpha as well
- Made it use and deliver float buffers
- Huge cleanup of zblur.c code, was very messy. It was alling things in render
code without need even (win matrices, transform faces, etc)
- Fixed errors in using Z values (zbuffer is signed int)
- Removed very weird gamma corrections for front/back half
- Tweaked gaussian table, allow variable 'Sigma' to be set for gauss curve
- Didn't copy 'auto focus' yet. Use of this is very limited, and gives
false expectations, nor works for rendering anims with deamons well.
Main issue remains: it's not a very advanced feature... I still doubt
very much if this deserves to be released. Spent 2 days on trying to get
the key issues solved, with not much results.
- gauss filter code has weird side effects on large blur size
- having unsharp (blurred) in front also blurs what's around in back.
only blurred in back with sharp in front works a little bit
- severe aliasing errors... also due the code splitting in 2 halves
- doesnt work with unified yet
- won't work for halos, spot halos or transparant faces
Anyhoo... It was promised to be committed, so now artists can play with it.
Who knows it's useful after all, or some fixes can be implemented. :)
- Maximum faces/halos per pixel was 500, which wasn't correctly applied in
all cases, causing errors in AA
- Moved maximum up to 1000 now
- made halos become clipped away from filling in buffers when behind a
solid face. That saves a lot of rendertime!
Unified remains weak with halos...
- removed ugly pointerhack from OSA render (negative indices denoted
pointers). this should solve memory errors when using >1.5 gig mem
- cleaned up usage of zbuffer values. These are signed in Blender, and
treated as unsigned all over, giving confusing code
- fixed incorrect gamma-adding for halos (caused in after xmas commit)
And bugfix #2101; wire render didn't give correct rendering for mist.
This caused by fact wires are 2D pixel lines, and not correctly filled
in faces. Retrieving the 3d coordinate while render cannot use a face-
equation then. Solved by retrieving 3D coordinate based on zbuffer value.
Still todo here: calculating correct texture coordinates for wire-edges
that are no faces.
Alpha for halos was always added, even when "Add" slider was zero. Fixed.
(also; made BROW define BROW16, to distinguish from int version in
BKE_utildefines.h)
- zbuf; error caused by using unsigned int as counter (while >= 0) in radio
- backbuffer didnt load in initrender (was removed from sky render)
- unitialized variable in envmap.c
