render option "save result to disk" and ESC from rendering, it crashed...
Note; reading partially saved exr files still crash... but that's an issue
within the openexr lib. I've mailed the openexr dev list for assistance
how to properly close a partial saved tile-file.
now the button works as meant to be.
Still working on the feature though... I noticed exr files dont read
back when only part was saved (on user break). Working...
New option "Save Buffers", in first Output panel of renderbuttons, will not
allocate all render buffers, but instead save the rendered tiles to exr.
For each scene rendered, a single exr file then is created.
After rendering, the files get read, and only then the memory allocation is
done.
The exr files are saved in the temp dir (from user settings), and have
names derived from the filename+scene name. That way these buffers remain
relatively unique, and can be re-used later too.
Saving all render-layers and passes in a single file (as F3 command) will
be done later. Also reading back the current muli-layer exr files is not
supported yet (will read black). The purpose is that these files then can
be used as input for the Compositor.
One fun thing I added; after rendering once with this option, close
Blender, and restart it. If you have a Composite set up press 'R' on an
active RenderResult node. This will refresh the node(s) and load the exr,
so you can composite again without a re-render.
for faces can give inaccuracies resulting in UV values in the hundreds
range. The UV values now are being clipped.
This should fix weird 'shooting lines' for vectorblur on hair renders.
Schlaile; do you have a weird texteditor setting or so? It breaks up
function calls in a very strange way, with each argument of a call
on a new line. That's not code that way, that's movie credits! :)
(Check the diff below to see)
* move declaration to start of function. Again I repeat: these *have* to
be at the start. GCC users should check themselves always, as GCC allows
this kind of atrocities :)
/Nathan
* Begin of the week, so I wanted to fill my commit quota right off the bat.
Add CC and CXX defaults for mingw, too. Unless we have invisible configs
this should be the last one :S
* These changes bring cross-compiling Blender for Windows on Linux one step
closer to reality. The 'biggest' change is in makesdna SConscript to make
sure a linux native makesdna is built, that can be run, too. Next to that
proper checks for env['OURPLATFORM']=='linuxcross' are added in various
places.
Switch change in pluginapi.c was necessary, and AFAIK it should work like
that also on WIN32, if not, slap me.
Note: everything *compiles* now nicely, it is just that the final *linking*
doesn't work (yet). Anyone who fixes this will be the
hero of cross-compilers :)
- Renderwin still used a thread-unsafe malloc, in the header text print
- Setting clipping flags in vertices for parts required a mutex lock after
all... I thought it would go fine, but noticed on renders with small
amounts of faces that sometimes faces disappear from a render.
(was doing movie credits, so all faces are visible! Otherwise it would
have hardly been noticable...)
Note : this part of code was quite a mess with things called twice when
not needed, tests for not updating when we want to, and hsv sliders not
handled properly.
I tried to figure what was useful and what was not but cannot garantee i
spotted everything or even fixed it the most proper way, the event callback
nesting making hard to figure what really happen.
However it does work again now
standard for film scanning, 10 bits/channel and logarithmic. DPX is
derived from Cineon as the ANSI/SMPTE industry standard.
DPX supports 16 bits color/channel, linear as well as logarithmic.
Code has been gratefully copied from CinePaint and was integrated in
Blender by Joe Eagar.
According to CinePaint's dev Robin Rowe the DPX code defaults to log
colorspace. Can't find in the code clues yet how to enable/disable that.
However, tests with write/read of DPX seems to show no visible loss by
log conversion code. Might be because it uses the entire 16 bit range...
CinePaint dpx files have been succesfully imported in a Quantel IQ HD/2K
finishing/grading set without problem, so for now I guess we can
use it! :)
Changes in code: added tests for image magic numbers before entering
the actual reading code. Prevents error prints, and makes it faster too.
(Note; this because Blender doesn't check for extensions, but calls
reading functions on every file until one accepts it. :)
- 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...)
for leftover initialized max-speed values, and clears it. Also gives
a giant print then... I want to know when it happens, and howto redo!
(error print = "tsk tsk! PASS_VECTOR_MAX left in buffer...")
also could use correction for it.
The current perspective projected blur would look in 180 degree view like
this:
http://www.blender.org/bf/p2.jpg
(circle of planes rotating around camera)
After some fight with my rusty highschool gonio I got it fixed; nice
cylindrical projected speedvectors:
http://www.blender.org/bf/p1.jpg
Ctrl+RMB in local sticky mode now selects as if in sticky mode. This used
to work only in non-sticky mode, but now with local sticky as default,
it's nice to have this functionality working there also.
- if you add new theme colors, you need to initialize them correctly and
add that in the usiblender.c version patching for saved themes
- the code for detecting group membership was highly confusing
- group colors were even used for non-groups
Further; I didnt add group theme colors yet, that's not a bug. It's a todo
item I preferred to tackle with having a decent wirecolor system once.
Rotating UV coordinates with snapping was image aspect ratio 'corrected'
for non square images. Only snapping for translation should be affected
by the aspect ratio.
The bug reported here was already fixed some weeks ago, but there were
more issues. Modifier display in face select and paint modes was never
properly finished.
This fixes some small drawing update glitches, and only allows modifiers
that preserve a mapping to the original mesh to be applied. Otherwise
selection and painting isn't even possible.
A bug fix and an enhancement:
* fixed bug when adding or deleting faces from a mesh which has
vertexColors; mesh->mcol was not being updated
* changed edges.extend() and faces.extend() to accept integer vertex
indices in addition to MVerts; this should make scripts simpler and
in general make things run faster
