Issue was caused by wrong camera motion stored in device in cases
when first render layer does not have vector pass enabled.
Solved by forcing device camera update in cases when scene's motion
changed since previous device camera update.
Move center tile acquiring code into own function. Should be
easier for time being when we'll want to support other tile
render orders.
Also now there should be a single bucket growing from center
when multi-GPU is used. Can't test this here tho.
This commit solves couple of issues appeared with new integrator:
- Render job progress bar is now shows progress based on number of
rendered tiles. This is the same as Blender Internal does.
This still requires some further thoughts because for GPU it's
better to use single tile and in this case progress bar should
be based on number of rendered samples.
- Removes "global" sample counter from progress descriptor. There's
no more global-being sample which makes sense.
This counter was replaced with tile counter.
- Use proper sample number when copying render buffer to blender.
It used to be final sample number used which lead to tiles
appearing from complete dark to normal brightness as they're
being rendered. Now tile would be displayed with proper
brightness starting from the very first sample.
Use sample counter stored in render tile descriptor and pass
it to update / write callbacks.
This was tested on CPU and GPU CUDA rendering.
Additional change:
OpenCL rendering now should be cancellable before it finished
rendering all the samples (the same change as for CPU/CUDA from
a while ago).
This part of commit wasn't actually tested, would do it later.
Remove limit for number of textures when using CPU rendering,
so huge scenes from Mango could be rendered properly.
Re-arranged float and bytes textures for this, so now float
textures goes before byte. This is needed to make alignment
stuff easier for variable number of textures.
Also replace code-generated CPU kernel structure's members
with an array, which makes it easier to access textures
without adding bunch of cases in switch.
Should be no functional changes when rendering with GPU
or OpenCL devices.
Update samples displayign in the interface once in a whiel only
(currently once in 1 sec). This still keeps rendering interactive
enough for artists and it eliminates slowdown caused by constant
uploading sampels from GPU to host.
This also allowed to get rid of hack with storing render result
in render buffers, due to it's not so big overhead ow to create
render result when sample needs to be updated.
Tests made with different files shows that now render speed is
really close to oroginal speed from before we started hackign
into this stuff.
There still some issues with interactive update when rendering
several render layers, but that seems to be irrelivant to all
this sampels commtis, so woudl look into this as a separate
patch.
This fixes memory overflow caused by creating render result every time
RenderResult is creating when updating sample and not being freed until
tile is fully rendered.
Solved in probably not best way -- RenderResult is being stored in
RenderBuffers, so it's creating only once.
This solves memory issues, but while was looking into this issue
discovered dramatic slowdown caused by samples update in some files
from mango svn.
Solving this slowdown is becoming first priority from now on.
Was requested by Mango team to improve feedback during rendering.
Known issues:
- Updating of samples are accumulative, meaning that visually samples
would be dark in the beginning becoming brighter during progress.
- Could give some % of slowdown, so probably should be disabled in
background mode.
Still to come: update of samples when using CUDA and OpenCL.
selecting Box instead of Flat as projection, and then setting the blend value.
Blend 0.0 will not do any blending between box sides, higher values will give
a smooth transition between the sides
This is useful for mapping image texture without too obvious patterns in a
way that looks seamless, without the need for UV mapping. This works basically
the same as the mango node setup that was posted, just a bit faster:
http://mango.blender.org/production/blended_box/
- images that can't be loaded because of the limit are printed in the console.
- textures that can't be found show up as pink (so we know somethings wrong).
save memory during render and cache render results.
Implementation notes:
In the render engine API it's now possible to get the render result for
one render layer only, and retrieve the expected tile size in case save
buffers is used. This is needed because EXR expects tiles with particular
size and coordinates.
The EXR temporary files are now also separated per layer, since Cycles
can't give the full render result for all render layers, and EXR doesn't
support writing parts of tiles.
In Cycles internally the handling of render buffers and multi GPU
rendering in particular changed quite a bit, and could use a bit more
refactoring to make things more consistent and simple.
direct and indirect lighting differently. Rather than picking one light for each
point on the path, it now loops over all lights for direct lighting. For indirect
lighting it still picks a random light each time.
It gives control over the number of AA samples, and the number of Diffuse, Glossy,
Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample.
This helps tuning render performance/noise and tends to give less noise for renders
dominated by direct lighting.
This sampling mode only works on the CPU, and still needs proper tile rendering
to show progress (will follow tommorrow or so), because each AA sample can be quite
slow now and so the delay between each update wil be too long.
The particle data is stored in a separate texture if any of the dupli objects uses particle info nodes in shaders. To map dupli objects onto particles the store an additional particle_index value, which is different from the simple dupli object index (only visible particles, also works for particle dupli groups mode).
Some simple use cases on the code.blender.org blog:
http://code.blender.org/index.php/2012/05/particle-info-node/
* More fixes for r41599, removed clouds and distorted noise textures and ported the Noise texture to OSL.
ToDo: Color output is still commented, needs a closer look.
* Some more fixes (comments, uninitialized variables)
* The random output had a range from -0.5 to 0.5, added an offset of 0.5 to bring it into the 0.0 / 1.0 range, which is in alignment with Shader Node Guidelines.
Patch by Agustin Benavidez, thanks!
pass index, and a random number unique to the instance of the object.
This can be useful to give some variation to a single material assigned to
multiple instances, either manually controlled through the object index, based
on the object location, or randomized for each instance.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Object_Info
