of sequencer, except current frame. Apparently the cache limitor doesnt
work for floatbuffers yet... and while rendering, I prefer to have all
memory available for the render itself.
Schlaile; you might check on what is wrong, in case imbufs have have
a rect_float or zbuf_float, the cache doesnt work yet?
The old implementation was added quite hackish (talking about 10 yr ago).
You also had to make a small image slice, which was extended Xparts in
size. That also required to adjust the camera angle. Very clumsy.
Now; when enabling the Panorama option, it will automatically apply the
panorama effect on the vertically aligned tiles. You can just enable or
disable the "Pano" button, to get a subtle lens effect like this:
(without pano)
http://www.blender.org/bf/rt.jpg
(with pano)
http://www.blender.org/bf/rt1.jpg
For Panorama render, the minimum slice size has been hardcoded to be 8
pixels. The XParts button goes up to 512 to allow that. In practice,
rendering 64 slices will already give very good images for a wide angle
lens of 90 degrees, the curvature of straight lines then is equal to
a circle of 256 points.
Rendering a full 360 degree panorama you do by creating an extreme wide
angle camera. The theory says camera-lens 5 should do 360 degrees, but
for some reason my tests reveil it's 5.1... there's a rounding error
somewhere, maybe related to the clipping plane start? Will look at that
later. :)
Also note that for each Xpart slice, the entire database needs to be
rotated around camera to correct for panorama, on huge scenes that might
give some overhead.
Threaded render goes fine for Panorama too, but it can only render the
vertically aligned parts in parallel. For the next panorama slice it has
to wait for all threads of the current slice to be ready.
On reading old files, I convert the settings to match as closely as
possible the new situation.
Since I cannot bump up the version #, the code detects for old panorama
by checking for the image size. If image width is smaller than height, it
assumes it's an old file (only if Panoroma option was set).
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 :)
Made some fixes and changes.
* The matricies returned were wrapped. Wrapping Display Mesh matricies segfaulted sometimes. - Made a copy instead.
* Added 1 missing epydoc from the patch.
* Renamed getDupliMatrices to getDupliObjects, and changed to return a list of (object, matrix) tuples instead of just the matrix. This is much more usefull because it allows python to know what objects are used for dupliGroups and for dupliverts where there is more then 1 child. also cleaned up this function a bit.
+ SCons support for pthreads-win32. Library will be committed shortly into
lib/windows, so be sure to check commit list and update that as well
when the pthread lib is available.
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.
* Use same warning flags as with linux2, greatly reducing noise in
output during compile. Also for developers using win32/mingw now
in effect: correct *each* and *every* warning in your code. I
command you to!
* Warning flags I had dutifully copied from sirdudes yet unpublished
make rewrite turned out to be the Paranoia flags, causing the flood
of warnings. Using better flags instead (like current Makefile level 1).
All developers on Linux that use SCons for building - (new) code you write is
supposed to be *entirely* warning-free from now on (Ton said so!)
the ones that get changed within threads, to communicate with the main
thread.
(Part of the long quest to get threaded render safe, especially in Linux)
passes in single file. Code is currently disabled, commit is mainly to
have a nicer method of excluding OpenEXR dependency from render module.
This should compile with disabled WITH_OPENEXR too.
Reason why EXR is great to include by default in Blender is its feature
to store unlimited layers and channels, and write this tile based. I
need the feature for saving memory; while rendering tiles, all full-size
buffers for all layers and passes are kept in memory now, which can go
into 100s of MB easily.
The code I commit now doesn't allocate these buffers while rendering, but
saves the tiles to disk. In the end is it read back. Overhead for large
renders (like 300 meg buffers) is 10-15 seconds, not bad.
Two more interesting aspects:
- Blender can save such multi-layer files in the temp directory, storing
it with .blend file name and scene name. That way, on each restart of Blender,
or on switching scenes, these buffers can be read. So you always see what was
rendered last. Also great for compositing work.
- This can also become an output image type for rendering. There's plenty of
cases where you want specific layers or passes saved to disk for later use.
Anyhoo, finishing it is another days of work, and I got more urgent stuff
now!
out moving transparent pixels by checking for alpha>0.95, now it also
checks the solid layer (if present), and if there's no solid face in a
pixel, the speed vector gets also added and used for transparent pixels.
This solves the 'ugly' hard outlines for vectorblur of moving hair.
Before:
http://www.blender.org/bf/h1.jpg
After:
http://www.blender.org/bf/h2.jpg
+ the code in writemovie.c no longer compiles (since the renderer
refactor). I have #if 0-ed it.
+ OpenGL on Irix doesn't have GL_ARB_vertex_program
+ mmap on Irix doesn't like MAP_ANON.
+ If using the MipsPro 7.3 compiler, the variable MIPS73_ISOHEADERS
can be set to point to the directory with those weird C++ headers
that don't have .h in the name
now that the command to put the object files into an archive is
exceeding 20k characters, which is a problem for some operating systems.
To avoid this, this modification causes make to change directories before
archiving, to avoid having to specify full file paths to the files
being archived.
If this causes problems on some systems, let me know and I'll find an
alternative.
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...
to my previous commit (whoops). The second part covers the changes I
have made to the code since then (all related to merge tools code).]
# Part One: Complete Log for Commit from 2/13/06
-> Upgraded merge tools.
The new merge tools add several options to blenders Merge submenu,
accessed via the WKEY whilst in Editmode for meshes. The new options
depend on current mode:
- Vertex mode: "At First" and "At Last"
When choosing "At First" or "At last" it will merge all selected
vertices at the first or last selected vertex.
(Note: Blender now keeps track of the last and first verts selected in
editMode (G.editMesh->lastvert and G.editMesh->firstvert
pointers. This meant additions were made to the undomesh code in
editmesh.c as well).
- Edge mode: "Collapse Edges"
When choosing this option, Blender examines the current set of
selected edges and groups them according whether or not they are
topologically connected. It then goes through each group and merges
them one by one to a single point.
- Face Mode: "Collapse Faces"
Works the same as "Collapse Edges", only works on groups of
topologically connected faces.
-> Inclusive selection mode conversion.
This feature extends the ability of blenders selection mode
conversions. Currently when you change selection modes from a "lower
order" mode to a "higher order" one (vertex->edge, vertex->face or
edge->face) blender only selects elements in the new mode whose
elements were completely selected in the previous mode.
This patch does not change blenders default behavior but offers
implicit selection mode conversion as an alternative. To access it,
hold either the left or right CTRL keys and click on a selection mode
in the view 3d selection mode header buttons. This can be accessed via
the CTRL-TAB selection mode switching as well, simply hold CTRL while
clicking the mode you want or entering its number on the keypad.
In some programs, such as Wings and Mirai, it has been demonstrated
that it can also be very useful to exploit selection mode switching to
implicitly select previously unselected elements as well. For instance
switching selection mode from vertex to edges will select all edges
currently associated with the currently selected vertices. The same
behavior is applied to switching between vertex->face and
edge->face. By exploiting this sort of selection conversion complex
selection sets can be built quicker.
Furthermore I modified blenders UndoMesh code to make selection mode
switching "undo coherent". Aside from its relevance to inclusive
selection mode conversion, this really counts as a "bug" in my
mind. Previously selection mode switch could cause the selection state
of the mesh to be invalid when certain modeling operations were
undone. An example of this would be "edge subdivide-> switch to face
mode-> undo"; you end up with edges selected while still in face mode!
# Part Two: Log for this Commit
-> Code Cleanup
As per Ton's request I reformatted all my code, changed variable names
and eliminated my use of "LinkNode" structs and replaced them with
"ListBase" instead. There should be no warnings while compiling now
either.
-> Remove doubles bug
Fixed small problem in removedoublesflag() in editmesh_tools.c that
caused editface structs to get their UV's scrambled. Vertex colors
might not be safe though? Need to investigate later.
-> Small bug in in the the code for merge last/first
It could cause a crash when exiting editmode, switching meshes, then
entering editmode again. "lastvert" and "firstvert" pointers are now
set to NULL whenever exiting editmode now (see load_editmesh() in
editmesh.c). I will find a better solution to this *soon*...
-> All merge tools now UV aware (optional)
The default behavior is to leave UVs alone, but if you hold CTRL while
clicking on the menu entry, UV's are merged. This works fine in most
situations, although some investigation into how to best handle
merging of UVs at the border of UV islands needs to be done.
This last item brings up a point about the current state of the
interface: several functions accessed through the WKEY menu now use
the CTRL modifier to change how they behave (This convention has been
in place for a while, see subdivide for example). Unfortunately there
is no way to communicate the way modifier keys change the behavior of
certain functions to the user. This makes such options invisible for
all intents and purposes...
object center, it doesn't generate displaylist (or derivedmesh). This
error showed especially on loading files, and you had to advance frame,
zoom out or press Numpad-9 to see stuff.
