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.
now for OSX though... that's where we can verify if the irregular crashes
will stop (ATI issue, nvidia seems to be OK)
If ATI users for other platforms want to check; just extend the two
#ifdefs I added for frontbuffer drawing. Note; the syntax then becomes
#if defined(__APPLE__) || defined(_YOUR_PLATFORM_)
only in Face-Select mode. It then uses for rotate and scaling the face
center itself as reference.
Code uses a loop-in-loop to find the face that belongs to the vertex...
means it will be slow with operations on 10k or more faces. Acceptable
for now, will make it nicer later. :)
Added a new tool to the 'W-Key' popup menu in mesh editmode, 'Path Select'.
When exactly two vertices are selected, 'Path Select' will find the shortest
path of vertices between them. There are two methods for determining
the shortest path, one that finds the path with shortest physical
distance, and one that finds the path with shortest topological distance.
Examples:
Original Selection
http://www.umsl.edu/~gcbq44/pathselect.jpg
Path Select - Edge Length
http://www.umsl.edu/~gcbq44/pathselect-shortestphysical.jpg
Path Select - Topological
http://www.umsl.edu/~gcbq44/pathselect-topological.jpg
The tool uses a straightforward implementation of Dijsktra's algorithm
and may be a bit slow on extremely large meshes. As a speedup you can
hide the parts of the mesh that you are not working on and they will
not be searched.
- 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
Spaces or to tabs.
Adds function void convert_tabs(struct SpaceText *st, int tab)
int tab is eather 0 or 1; 1 if converting to tabs
I was going to make this auto run when running a script but did not know what that would do to the GE or any thing else.
different layers, the layer flags of objects got mixed up on selection.
This caused groups to become unselectable or uneditable, also the original
group...
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
Remove doubles didn't previously deal with vertex groups/weights properly. Now it averages the weights of vertices when they are doubles and share the same group. Verts that get merged but don't belong to all the same groups are dealt with as well.
in doing this in the first place. (1 conditional vs 1 per loop duh)
Thanks for calling me on this Alexander.
(I didn't actually benchmark it to see but its pretty obvious which is less
work for the computer.)
Kent
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.
Basically the check for a type of jpeg was messed up.
I added a imb_is_a_jpeg function since I was working on that bit and
it makes it a little more similar to the other filetypes.
I also changed a switch statement that had the same loop for all
cases, just moved the loop outside of the switch statement.
Kent
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...
Added new function in editmesh_mods.c, "loop multiselect" and can be
accessed via the CTRL-E popup menu in editmode. It is used to select
multiple edge loops/rings based upon the current selection set. It does
this simply by looping through a list of currently selected edges and
calls 'edge_loop_select' or 'edge_ring_select' for each one. This can
be used to build large selection sets quickly, as can be seen in
the following example images...
step 1 - http://www.umsl.edu/~gcbq44/multiselectA.jpg
step 2 - http://www.umsl.edu/~gcbq44/multiselectB.jpg
step 3 - http://www.umsl.edu/~gcbq44/multiselectC.jpg
-> Misc
While I was in there I fixed a couple of existing issues as well...
- "Select Less" now gets a proper undo push.
- countall() wasn't being called after inclusive selection mode conversion
- some strange formatting in EM_convertsel() in editmesh_lib.c fixed.
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
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 :)
