Render:
- New; support for dual CPU render (SDL thread)
Currently only works with alternating scanlines, but gives excellent
performance. For both normal render as unified implemented.
Note the "mutex" locks on z-transp buffer render and imbuf loads.
- This has been made possible by major cleanups in render code, especially
getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct
OSA or using Materials or Texture data to write to.
- Made normal render fully 4x32 floats too, and removed all old optimizes
with chars or shorts.
- Made normal render and unified render use same code for sky and halo
render, giving equal (and better) results for halo render. Old render
now also uses PostProcess options (brightness, mul, gamma)
- Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer
after render. Using PostProcess menu you will note an immediate re-
display of image too (32 bits RGBA)
- Added "Hue" and "Saturation" sliders to PostProcess options
- Render module is still not having a "nice" API, but amount of dependencies
went down a lot. Next todo: remove abusive "previewrender" code.
The last main global in Render (struct Render) now can be re-used for fully
controlling a render, to allow multiple "instances" of render to open.
- Renderwindow now displays a smal bar on top with the stats, and keeps the
stats after render too. Including "spare" page support.
Not only easier visible that way, but also to remove the awkward code that
was drawing stats in the Info header (extreme slow on some ATIs too)
- Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping
defines.
- I might have forgotten stuff... and will write a nice doc on the architecture!
It appeared that the method as used in unified render for "render all sub-
pixels" isn't very well resistant to having large amounts of faces in a
single pixel. The bug file had about 16x70x2 faces per pixel... causing
tremendous slowdown and even wrong render.
I've disabled the option (was coded by Nzc in NaN days) and made it
sampling in the main render loop. Goes much faster, error free. Only loss
is in that it doesnt use superiour subsamples for gauss anymore. Here the
normal render performs slightly better. Not a real issue though. Hard to
notice.
Combination of:
- render movie
- with border set
- and "crop" set
Crashed.
Was due to feeding movie initialize code wrong frame sizes. Another oldie!
Also found that crop+border+parts doesnt work. This now is prevented with
warning and return.
that could popup error() boxes. These dont work then, and need to be
disabled by keeping R.flag on R_RENDERING
This is a half fix for a report Rob H works on. Will wait for his test.
- Stucci now accepts it too (for normals and color)
Note; stucci doesn't return a single value, like marble or wood, that's
still so, to disable it coloring the "Col" Map input by default.
- Magic texture now accepts Colorband
Five fixes in this commit...
- the normals for nurbs surfaces still were calculated pointing wrong in some occasions
- recoded ray-transp rendering to accept normals pointing any direction; it just counts how many times it passes a "glass" layer, and flips normals appropriate then. This means rendering will go fine on models without manually setting the normals. You can also move a camera inside a 'glass' object.
- rendering of the inside part of glass now uses correct normal too... specularity happen on a solid glass inside now.
- And an inside reflected mirror ray will keep bouncing inside glass
Related to rendering localview: old convention to render localview, but with the lamps in the normal layers, has been restored.
Please note; render happens based on active window. You *only* get a localview or 'unlocked layer' render when that 3d window is active = mouse in window.
- New channel for "Map to" added, "Warp"
- Use the slider next to the option to set amount of influence the texture
will have on the coordinates of the next texture.
- Warp uses for this the same values as for Normal or Displacement mapping
- Warp remains active for all channels, until replaced (or zeroed).
While going over the code, I found out the "nabla", the size of offset
vectors for calculating derivatives of a texture, is a built in constant.
Even worse, the value was different for new noise types (musgrave etc).
So I've added a new slider for it in the procedural texture panels, which
by default is set to 0.025, the value of the old constant. Also made sure
it works with equal effect in all procedurals.
NOTE: a small Nabla will give sharper, detailed bump, but the effect also
becomes smaller, correct that in the Mapping Panel of materials.
For better & compliant control over the bumpmapping, I've also included
the Colorband output in derivatives calculus, so the bump output then
matches the color created. It's also a nice tool to finetune output of
textures for bumpmapping in general.
Bug fix; clicking on the rightmose 'item' in ColorBand didn't activate it.
Found out the ColorBand was slightly drawn off (2 pixels).
causing weird results on camera moves or object rotations.
Added: support for "normal maps". See for example:
http://members.shaw.ca/jimht03/normal.html
The Image panel in Texture buttons has new option "Normal Map" for it.
When this is used, normals are read straight from RGB values, and blended
with the current normal.
channels to link texture to.
The amount of code changes seems large, but is mostly getting rind of
hardcoded values (6 and 8) for channels, replacing it with MAX_MTEX.
Further did some fixes;
- Ipo for Lamp showed too many mapping channels
- Texture MapTo buttons for lamp missed the slider to blend texture color
- Lamp texture mapping "View" only worked for Spot, now it uses lamp-
view vector for all types. (Nice for projections!)
Unified render added sky with alpha=1. Found the way how to fix it, didnt
dare that yesterday. :)
Now sky is rendered with alpha=0, like normal render.
Thanks to the recent reports, a lot of old issues with unified render have
been solved. This is going to be pretty OK!
When using a backbuffer with alpha, but alpha is not premulled, you can
get weird rendering results with halos or lens flare. This was caused by
optimize rule in alpha routine that assumed alpha==0 means color is zero.
Removed for the the halo case.
Halos with Flare option didn't render correct in Unified render, they were
added twice!
Also noticed errors in applying alpha for 'Premul' alpha in Unified. Fixed.
Combining panorama scene and Sequencer effect on scene (like glow) crashed.
Found two other issues;
- on click in sequencer, the image output window didn't redraw correct, but
only when a render window was opened. Caused by missing 'activate' call
- added a pause in dragging-frame loop to make it idle friendly
In unified render, halos can give black/colored overflows. Found it this
happens with halos that are behind the camera clipping range. Halo clip
just had some weird code for panorama corrections...
In the provided .blend of report found 3 more glitches;
- after render particle system with Material Ipo, values for material were
not restored correctly
- Meshes with particles didn't draw axis (draw extra) on correct location
- Same as above, axis didn't draw in selected color.
For composting sky behind alpha, a gamma corrected alpha_under was used,
but Blender didnt make the gamma tables unless OSA was set.
Old bug!
Changed; while rendering with "Backbuf" that doesn't exist, blender still
renders, but without backfbuf now. It used to stop render and return, with
only a print in console... confusing.
Gaussian sampling/rendering now supported too!
Also corrected gamma corrected adding of colors, which gives better alpha
and blending with sky than normal render does. The latter I could check
once too...
Thanks to Brecht & Valgrind, found 2 cases for unitialized variables in
the render code. Both were for 2D texture input (Window and Sticky) which
didn't initalize a the third coordinate. Goes fine for 2D textures, but not
for 3d ones :)
Crash in this situation;
- one blender file with more scenes
- render image
- goto another Scene with no camera and larger output size for image
- render
Render buffer has to be freed then :)
- Ztransp material didn't raytrace at all (now just traces it entirely,
remember too set the transp depth for it)
- tramsparent material reflected wrong in mirror material, due to
specular being added without alpha.
- Cleaned up some code to improve raytrace speed some. The old conventions
from before the AA recode were still there, this allowed coherence for
octree traversal. Current AA doesn't allow this anymore.
Added is improved check for 'first hit' on shadow render, per lamp this
now is stored
All in all, render with ray trace improved about 10-15%.
Two accumulating errors, causing 'scanline' errors too, but now based on
using different filtering values for transparent shadows.
Was another 2 cases of unused variable render as well. :)
with the zblur plugin for faster dof (or other seq.plugins that need the
zbuffer).
I don't think the conversion to a blender zbuffer value is quite correct,
but at least it does produce usable results for zblur without too much
differences with the blender render (at least not for the short tests that I
could do in this short time...)
- onlyshadow material defaulted to black when no shadow calc was used, is
now 100% transparent
- AO 'shadows' were not included in onlyshadow material
- alpha render appeared to be wrong since 2.32... it was gamma corrected
giving difference in OSA render with 'Gamma' on
That alpha issue i am going to tackle once, it is not well functioning, and
might be combined with new 'transmission' colors idea
In DisplayButtons, Panel "Output", a new slider "Dither" allows to add
random noise dither to rendered output. It works on sky as well as solid
and transparent. Note however that in OSA render, the Unified Render gives
much better results, since that render nicely delivers full scanlines of
high definition color. The old render mode isn't well suited for this
postprocess.
A dither value of '1.0' will exactly add maximum of 1.0/256.0 to the
pixels.
Potential improvements for next releases;
- regular patterns
- dither per color channel
- not only add, but also subtract dither
Also note that this gives best results for print work or stills. Animating it
gives slight visible noise. Also runlength compression wont really work, and
Jpeg needs to be given higher quality too.
This was something users found since tracing got into blender, having
sometimes small 'dots' or bright pixels or missing reflection rays in
an image. Thanks to the very simple sample file I could disect it...
it appeared to be an incomplete check for all numerical exceptions when
you traverse the octree nodes. Very technical, but clear comments are in
the code to explain ;)
raytracer. Instead of only tracing the current subpixel it did all
(or most) of them.
Solves reports on slow AO in 2.34, but also will affect ray_mir and transp
Extended the range of the depth and cdepth parameters as reqested by leope.
Bumpmapping should now be a bit more similar to the Blender render.
Added support for all remaining lightsources in yafray, tried to make use of
as much of the existing Blender parameters as possible.
Blender Lamp: added switch to enable rendering with shadowbuffer ('softlight' in yafray).
All other parameters are similar to the Blender settings, for yafray both the
bias parameter and the shadowbuffer size can be lower than equivalent Blender
settings, since the yafray buffer is floating point. Remember that 6 shadowmaps
are created in this case, so can use quite a bit of memory with large
buffer settings.
When 'ray shadow' is enabled for this lamp type, it is possible to set a light
radius to create a spherical arealight source ('spherelight' in yafray),
when this is 0, it is exported as a pointlight instead.
Blender Spot: as in Blender now supports 'halo' rendering.
Halo spots always use shadowbuffers, so when enabled the buttons for shadowmap
settings will appear. The 'ray shadow' button can still be used to disable
shadows cast onto other objects, independent of halo shadows.
One thing to remember, halo's don't work with empty backgrounds, something must
be behind the spotlight for it to be visible.
And finally, the photonlight:
probably the most confusing (as more things related to yafray), the photonlight
is not a real lightsource, it is only used as a source to shoot photons from.
Since indirect lighting is already supported (and looks better as well)
only caustics mode is supported.
So to be able to use this properly other lightsources must be used with it.
For the photonlighting to be 'correct' similar lightsettings as for the 'source'
light are needed.
Probably the best way to do this, when you are happy with the lighting setup
you have, and want to add caustics, copy the light you want to enable for
caustics (shift-D) and leave everything as is, then change the mode to
'Photon'.
To not waiste any photons, the photonlight behaves similar to the spotlight,
you can set the width of the beam with the 'angle' parameter. Make sure
that any object that needs to cast caustics is within that beam, make
the beam width as small as possible to tightly fit the object.
The following other parameters can be set:
-photons: the number of photons to shoot.
-search: the number of photons to search when rendering, the higher,
the blurrier the caustics.
-depth: the amount of photon bounces allowed, since the primary use is for
caustics, you probably best set this to the same level as the 'ray depth'
parameter.
-Blur: this controls the amount of caustics blur (in addition to the search
parameter), very low values will cause very sharp caustics, which when used
with a low photonnumber, probably lead to only some noisy specks being rendered.
-Use QMC: Use quasi monte carlo sampling, can lead to cleaner results, but also
can sometimes cause patterns.
Since the photonlight has no meaning to Blender, when using photonlights and
switching back to the internal render, the light doesn't do anything, and no
type button will be selected. The lightsource can still be selected, but unless
switching to yafray, no parameters can set.
Apologies to Anexus, I had no time to really do something with your code,
I'll still look at it later, to see if I can improve anything in my implementation.
