module itself, replacing the special MEM_mallocT/MEM_freeT functions.
Mutex locking is only enabled when threads are running.
There was no good reason to have these separate, it just led to ugly
hacks when calling functions with non-threadsafe malloc from threads.
- Tangent vectors now can also be derived from orcos (No UV needed)
- Normalmaps now properly support tangent space as well
(Patch provided by Alfredo de Greef)
Full log is here:
http://www.blender3d.org/cms/New_Render_features.774.0.html
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.
When a sequencer has mixed use of 32 bits and float images (note, Scene
strip returns float image too), the old 32 bits image should be freed,
otherwise it keeps saving that image.
- It saves a file with indicated type on each change, with number
appended denoting the current frame (like ANIM saving).
- Output filename button supports relative paths ("//")
- Shows optional preview image too
- For now, added a print on each file save as feedback
To make this option work nicely, changed the BKE_makepicstring() function
to have less globals inside, so it is more generic. Todo: allow amount of
digits in filenames to be set (to support files like tmp_123456.jpg)
Preview render in 3d window: when window type changes (like 3d window to
UV window), and you change the window size, and restore to 3d view, the
rendered preview had to be re-initialized.
texture.c: a return was added without value.
- ImagePaint now uses ImBuf directly, and the rect blending functions
were moved into the imbuf module.
- The brush spacing, timing and sampling was abstracted into brush.c, for
later reuse in other paint modes.
Float ImagePaint support.
Textured Brushes:
- Only the first texture channel is used now.
- Options for size and offset should be added, but need to find some space
in the panel, or add a second one ..
N_T: the implementation of this feature isn't 100% nice, it currently does
a full recalc on each redraw, and it doesn't work properly unless it is
recalculated for each frame.
Repeat Image texture was broken... the repeat value for Y was accidentally
multiplied twice, typo... had to change a 1 into 2 :)
Error introduced in 2.41 btw, 2.40 and older were OK.
Render non-osa, with mblur, did not jitter the zbuffering, so it did not
result in basic AA for non moving parts.
Note to self: this now works on < 2.42 level again: it doesn't use
the correct subsampling, which can cause slight errors in rendering image
textures.
- 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.
The raytracer wasn't calling node shaders yet, so results showed only
shading for the base material.
This now works, but there's a conflict in the internal Blender shader that
makes recursive raytracing with nodes unpredictable. Basicaly the conflict
is that when a ray wants to shade a point, it should be able to check the
material for mirror properties, but this is undefined for node trees...
Probably we need to separate raytrace entirely from material shading. Is
a good topic for NodeShader 2.0, when we really split up materials in
shading components.
I'll add a note in the release log about this. Best results you get now
when you don't include mirror/ray-transp insde a node tree, in that case
a regular material mirror can render that material perfectly.
In december, when testing material layering, I've removed the check that
prevented specular and diffuse to become negative, this because it could
work nice for layering.
However, this breaks quite some cases too. For example negative lamps are
only used to cancel out other lights in same material, and should not give
negative (invisible!) peaks that work on a node system. Same goes for
negative diffuse from AO 'subtract' mode.
In fraka the error happened for AO on a translucent material. The inside
of the mesh got a negative AO, cancelling out the positive AO on the
outside.
Anyhoo; this commits ensures that a 'shade_lamp_loop' call will never
return negative values again!
- AO "Use Distances" can not use 'sky texture' for colors, that bug was
fixed in UI (prevent settings to combine), but better also gets fixed
on reading files.
- Backbuf render, when not existed, didn't initialize backdrop color to 0.
Hurmf, then you bring back old backbuffer, and they want to have fields
work on that!
OK... here it is. Although using Compositor features will make this much
easier and advanced to control. :)
- Halos were not sorted, for ages! Meaning that they were rendered in order
of creation, instead of back to front.
- Made ESC testing for halo render to check per halo, is a fast routine now
anyway.
Report noted the slow icon renders for menus, which indeed is an issue,
especially when texture images need to be loaded (not to mention that
will eat up loads of memory).
Added a flag in scene to disable loading of images, makes it 50 times
faster, at least :)
Another thread render issue, now in Image texture, the 'repeat' value was
still a global... how did I think that would ever work? Just forgot about
that one I guess. :)
Render timers were called in the internal render loops (tile processor),
they still had to be moved to the outer loop, so they include fields/blur
or sequencer render timing correctly.
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).
suffered for the entire movie. :)
It only happened when rendering large frames, using a lot of memory and
typically when you also use other software in meantime.
Reason: the main thread does the drawing updating, while rendering is
still continuing. When using Ztransp, there was a free buffer done
when possibly a draw could still be in progress. Only crashed when drawing
is slow... explaining why it only showed up in more complex cases.
A proper check for the error "No Camera" on rendering can only be made
after a renderwindow was initialized. The error menu then shows in the
render window, which appears to not work OK in windows ATI (again!).
So; I've moved the test to before the renderwindow is activated, this is
not a test checking on the entire render pipeline (like Composite nodes or
sequence strips). In case more complex setups cannot render, an error is
printed in the console only.
Not clearing the value for 'parts rendered' caused 3d previewrender to
sometimes fail doing updates (when an escape happens during converting
render data).
Wire render crashes in Linux (only!), but why? Using a calloc instead of
malloc fixes it, but that doesn't solve the real issue in the code.
I can only imagine that bsearch() in linux has a completely different
implementation...
Anyhoo; let's commit the calloc, at least then we got stable wire render!
- when renderwin exists, but not used for render, the ESC timer check still
could return ESC event, due to missing flag clearing.
(For example in sequencer, a scene strip did not update on frame advance)
- option 'single layer' set in combination with render "Do Sequence" didn't
free the pushed layers.
The new Material "LightGroups" only worked with lamps in visible layers.
Now also lamps from the group that are not visible are included for
rendering, ensuring that a lightgroup always works on that material,
disregarding layer settings (unless lamp is type 'layer lamp').
Sequencer:
Removing feature that allowed live updates of render progress while using
scene strips. In 2.41 and older this also happens invisible, and ESC from
it works now anyway.
Two reasons:
- it is quite annoying, especially on quit renders
- new 'render to window' conflicts too much with the sequencer window
option that shows previews (in code as well as functional!)
When faces (like in cubes) have exactly 90 degrees angles with other
faces, the check for a vertex-normal flip became random, caused by the
infamous bad floating point resolution.
Solved with including FLT_EPSILON in the check.
Also: minor optimize for readability and removed dutch function name
(contrpuntnorm -> check_vnormal)
