This patch is mostly a usability patch for the sequencer, mainly written by
Anders Gudmundson and twisted a little bit by me.
- Lock Time to other windows
- Possibility to switch the X-Axis between frames and seconds-display
- IPO-Frame Locking for plugins (T-Key)
- Additional Popup to add HD-Sound and Movie at once
- In Timeline-Window: Sequencer windows only playback
- Make the IPOs a little bit IPO-Frame-Lock friendlier (doesn't jump;
the frame that is drawn has the right dimension)
- Wheel-Mouse buttons make the sequencer window zoom again.
- The "This is not a sound/movie-file message" now reads "... or
FFMPEG-support not compiled in!" since I learned some prominent
people who complained, that hdaudio does not work for them ;-)
- Make SPACEKEY open up the "Add Strip"-Popup on the timeline and start
playback in the preview window.
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.
- 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...)
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. :)
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.
front/back is selected), the UV coordinates for curves should also be
corrected.
This commit re-uses the same code as for Nurbs, to make sure UV coordinates
wrap around nicely.
BUT! I've noticed that Daniel's commit of august in this code actually
broke this UV correction... in his craze to cleanup old code, he missed
the actual functionality. Meaning that in 2.40 and 2.41, "UV orco" texture
coordinates wrap around ugly in Nurbs Surfaces, something that was fixed
in NaN days.
Got no time for tracker now... but I'm sure it's in there! :)
with each having different scenes, changing screens didn't call the proper
set_scene() call, which left quite some stuff improperly initialized.
With depsgraph code even causes crashing.
This prevents eternal loops. It prints error message in console.
Note that the Shader nodes dont need this, since they're just executed in
presorted order. The compositing nodes use threading, with a call asking
for the next job... if this includes cyclic nodes, the 'next job' will
always return NULL.
- blur works again (this was a serious bug in gamwarp...)
- seperates all sequence effects into a seperate file with a clean interface
- thereby fixing some obscure segfaults
- seperates the scope views into a seperate file
- adds float support to all effects and scope views
- removes a bad level call to open_plugin_seq
- FFMPEG seeking improved a lot.
- FFMPEG compiles with debian sarge version cleanly
- Makes hdaudio seek and resample code really work
Sofbody simulation happens in global coordinate space, and this was also
used for baking softbodies. Too bad you cannot re-use or further animate
the baked softbody then... :)
If you now use the new "Local" button in the Bake menu, it will allow to
animate or move the baked object.
This modifier allows to make arrays of meshes, with multiple offset types:
- constant offset
- offset relative to object width
- offset with scale and rotation based on another object
The number of duplicates can be computed based on a fixed count, fixed length
or length of a curve. Duplicate vertices can be automatically merged.
Nice docs and example files available in the wiki:
http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
animation systems, all transforms of all duplicated group members have
to be set first, before drawing or converting for render. This because
then still deformation can be calculated.
same composit3_pixel_processor() function. gcc even gives nice warning:
node_composite.c: In function `node_composit_exec_mix_rgb':
node_composite.c:1437: warning: passing arg 9 of `composit3_pixel_processor' from incompatible pointer type
floats were read as pointer...
It still needs some work but at least now it doesn't crash.
Basically it changed composit3_pixel_processor so that its using full
vector instead of first element (fac variable in the code).
In reality though its just pushing where its looking at the first element
of the vector to another function (do_mix_rgb)
which is calling ramp_blend with fac[0].
Kent
issues in parallel... So this commit contains: an update of
the solver (e.g. moving objects), integration of blender IPOs,
improved rendering (motion blur, smoothed normals) and a first particle
test. In more detail:
Solver update:
- Moving objects using a relatively simple model, and not yet fully optimized - ok
for box falling into water, water in a moving glass might cause trouble. Simulation
times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot
might also cause slowdowns.
- Additional obstacle settings: noslip (as before), free slip (move along wall freely)
and part slip (mix of both).
- Obstacle settings also added for domain boundaries now, the six walls of the domain are
obstacles after all as well
- Got rid of templates, should make compiling for e.g. macs more convenient,
for linux there's not much difference. Finally got rid of parser (and some other code
parts), the simulation now uses the internal API to transfer data.
- Some unnecessary file were removed, the GUI now needs 3 settings buttons...
This should still be changed (maybe by adding a new panel for domain objects).
IPOs:
- Animated params: viscosity, time and gravity for domains. In contrast
to normal time IPO for Blender objects, the fluidsim one scales the time
step size - so a constant 1 has no effect, values towards 0 slow it down,
larger ones speed the simulation up (-> longer time steps, more compuations).
The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect).
- For objects that are enabled for fluidsim, a new IPO type shows up. Inflow
objects can use the velocity channels to animate the inflow. Obstacles, in/outflow
objects can be switched on (Active IPO>0) and off (<0) during the simulation.
- Movement, rotation and scaling of those 3 types is exported from the normal
Blender channels (Loc,dLoc,etc.).
Particles:
- This is still experimental, so it might be deactivated for a
release... It should at some point be used to model smaller splashes,
depending on the the realworld size and the particle generation
settings particles are generated during simulation (stored in _particles_X.gz
files).
- These are loaded by enabling the particle field for an arbitrary object,
which should be given a halo material. For each frame, similar to the mesh
loading, the particle system them loads the simulated particle positions.
- For rendering, I "abused" the part->rt field - I couldnt find any use
for it in the code and it seems to work fine. The fluidsim particles
store their size there.
Rendering:
- The fluidims particles use scaled sizes and alpha values to give a more varied
appearance. In convertblender.c fluidsim particle systems use the p->rt field
to scale up the size and down the alpha of "smaller particles". Setting the
influence fields in the fluidims settings to 0 gives equally sized particles
with same alpha everywhere. Higher values cause larger differences.
- Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals
computed by the solver are used. This is basically done by switching off the
normal recalculation in convertblender.c (the function calc_fluidsimnormals
handles other mesh inits instead of calc_vertexnormals).
This could also be used to e.g. modify mesh normals in a modifier...
- Another change is that fluidsim meshes load the velocities computed
during the simulation for image based motion blur. This is inited in
load_fluidsimspeedvectors for the vector pass (they're loaded during the
normal load in DerivedMesh readBobjgz). Generation and loading can be switched
off in the settings. Vector pass currently loads the fluidism meshes 3 times,
so this should still be optimized.
Examples:
- smoothed normals versus normals from subdividing once:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.pnghttp://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png
- fluidsim particles, size/alpha influence 0:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png
size influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png
size & alpha influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png
- the standard drop with motion blur and particles:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg
(here's how it looks without
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg)
- another inflow animation (moving, switched on/off) with a moving obstacle
(and strong mblur :)
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg
Things still to fix:
- rotating & scaling domains causes wrong speed vectors
- get rid of SDL code for threading, use pthreads as well?
- update wiki documentation
- cool effects for rendering would be photon maps for caustics,
and motion blur for particles :)
For some reason I thought SDL thread handling would be much simpler... but
the migration to posix pthread went very smooth and painless. Less code
even, and I even notice a slight performance increase!
All threading code is still wrapped in blenlib/intern/threads.c
Only real change was making the callback functions to return void pointer,
instead of an int.
The mutex handling is also different... there's no test anymore if a
mutex was initialized, which is a bit confusing. But it appears to run
all fine still. :)
Nathan Letwory has been signalled already to provide the Windows pthread
library and make/scons linking. For MSVC we might need help from someone
else later though.
filtersizes (below 2 pixels). This because Bokeh actually does 2 peaks...
/\ /\
/ \/ \
I've added some fixes in the filter calculus though, and made sure that
on size 1 at least the image gets copied straight away.
Also fixed error, Bokeh shifted image 1 pixel up.
Todo; make filters become real floats in size...
- Links now can be made between any socket type. The nodes recognize amount
of channels, and will convert types if needed.
Conversions from RGBA to 1 channel will use the 'RGB to BW' formula.
Also note that conversions only happen when required. So you can blur an
alpha channel, filter it, and put this in a 1-channel socket without any
conversion to happen, which saves memory & cpu time.
http://www.blender.org/bf/rt.jpg
The blur nodes don't accept Vector input yet... But filter does.
- RGB Curve Nodes now have the premultiply option resored, 2 x faster
- Fixed some confusing code in Node Group handling... much stabler now
At long last!
This new constraint is pretty simple. Following in the footsteps of such giants as Copy Loc and Copy Rot, it lets you constrain the size of an object/bone to another object/bone, with per axis restrictions.
- Texture Node
Allows to use any Blender Texture block as input for masks or color
blending. The texture node doesn't generate a real image, but adjusts to
the size as mapped with during an operation. So it won't work to use it
as Image input for Blur or Filter nodes.
Note; the Vector inputs for this node only work with manual input now!
- Translation Node
Give any image an offset in X or Y direction
For the Texture node to work, I needed to move the central 'pixel
processor' up one level... to allow differently sized images to merge
and allow 'procedural images' without size.
Temporal image of the day: http://www.blender.org/bf/rt.jpg
(NOTE: new include dependency in Render module, might need MSVC update!
It has to include the imbuf/intern/openexr/ directory in search path)
-> New Composite node: "Hue Saturation".
Works like the former 'post process' menu. There's no gamma, brightness or
multiply needed in this node, for that the Curves Node functions better.
-> Enabled Toolbox in Node editor
This now also replaces the SHIFT+A for adding nodes. The nodes are
automatically added to the menus, using the 'class' category from the
type definition.
Current classes are (compositor examples):
Inputs: RenderResult, Image
Outputs: Composite, Viewer
Color Ops: RGB Curves, Mix, Hue Saturation, AlphaOver
Vector Ops: Normal, Vector Curves, Map Value
Filters: Filter, Blur, VectorBlur
Convertors: ColorRamp, RGBtoBW, Separate RGBA, Separate HSVA, Set Alpha
Generators: RGB, Value, Time
Groups: the list of custom defined nodes
-> OpenEXR tile saving support
Created an API for for saving tile-based Images with an unlimited amount
of layers/channels. I've tested it for 'render result' now, with the idea
that this can (optionally) replace the current inserting of tiles in the
main result buffers. Especially with a lot of layers, the used memory for
these buffers can easily go into the 100s of megs.
Two other advantages:
- all 'render result' layers can be saved entirely in a single file, for
later use in compositing, also for animation output.
- on each render, per scene, a unique temp file can be stored, allowing
to re-use these temp files on starting Blender or loading files, showing
the last result of a render command.
The option is currently disabled, needs more work... but I had to commit
this because of the rest of the work I did!
-> Bug fix
The Image node didn't call an execute event when browsing another image.
they work ok in testing here and get done what I need, any checks or fixes are welcome.
* Separate RGBA: Separates an input RGBA image into its R, G, B and A channels
* Separate HSVA: Separates an input RGBA image into H, S, V and A channels
* Set Alpha: Takes an input RGBA image and an alpha value channel and combines them
into a single RGBA image channel. You can also set the alpha for the entire image
with the number field when there's no input alpha channel. TODO: Allow input alpha
channel with no input image, in order to output a solid colour, with alpha.
In Orange we've been fighting the past weeks with memory usage a lot...
at the moment incredible huge scenes are being rendered, with multiple
layers and all compositing, stressing limits of memory a lot.
I had hoped that less frequently used blocks would be swapped away
nicely, so fragmented memory could survive. Unfortunately (in OSX) the
malloc range is limited to 2 GB only (upped half of address space).
Other OS's have a limit too, but typically larger afaik.
Now here's mmap to the rescue! It has a very nice feature to map to
a virtual (non existing) file, allowing to allocate disk-mapped memory
on the fly. For as long there's real memory it works nearly as fast as
a regular malloc, and when you go to the swap boundary, it knows nicely
what to swap first.
The upcoming commit will use mmap for all large memory blocks, like
the composit stack, render layers, lamp buffers and images. Tested here
on my 1 GB system, and compositing huge images with a total of 2.5 gig
still works acceptable here. :)
http://www.blender.org/bf/memory.jpg
This is a silly composit test, using 64 MB images with a load of nodes.
Check the header print... the (2323.33M) is the mmap disk-cache in use.
BTW: note that is still limited to the virtual address space of 4 GB.
The new call is:
MEM_mapalloc()
Per definition, mmap() returns zero'ed memory, so a calloc isn't required.
For Windows there's no mmap() available, but I'm pretty sure there's an
equivalent. Windows gurus here are invited to insert that here in code! At
the moment it's nicely ifdeffed, so for Windows the mmap defaults to a
regular alloc.
using 1 line per part rendered. Might go back to 1 line again, but at this
moment I need the logs for debugging.
Same prints are active now for UI rendering. Just temporal :)
- a Group has Curve node inside
- this Group was re-used more times
- with threaded render activated
- and both groups executed on same time
Then the premultipy optimize table was created twice... causing memory
to confuse.
