February 27, 2006, 20:05 (GMT) |
commented out a debugging message... was getting errors about cast to int losses percision on 64bit linux with gcc4.X Kent |
Revision 23f9960 by Ton Roosendaal February 27, 2006, 19:36 (GMT) |
Restored the free_imbuf_seq_except() in sequencer, to free all memory 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? |
Revision 833e0be by Campbell Barton February 27, 2006, 16:30 (GMT) |
Added a few more button align's |
Revision f68b0dd by Ton Roosendaal February 27, 2006, 12:39 (GMT) |
Recoded Panorama rendering. 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). |
Revision 534ee9e by Campbell Barton February 27, 2006, 12:34 (GMT) |
Made vertex clear work for selected faces from the menu, to be the same as Shift+K. Also makde Shift+K work in weightpaint mode. |
Revision e48af6f by Nils Thuerey February 27, 2006, 11:56 (GMT) |
- elbeem.h header file was missing |
Revision 0b7b016 by Nils Thuerey February 27, 2006, 11:48 (GMT) |
- typo in SConscript |
Revision 9a36e9b by Nils Thuerey February 27, 2006, 11:45 (GMT) |
Sorry for the big commit, but I've been fixing many of these 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.png http://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 :) |
Revision b7ff45f by Campbell Barton February 27, 2006, 06:00 (GMT) |
new emptys now have default settings for new emptys. |
Revision 9e0d283 by Campbell Barton February 27, 2006, 04:05 (GMT) |
Applied JMS's Patch. for better Python Dupli Access. 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. |
Revision 9a21866 by Chris Want February 27, 2006, 00:03 (GMT) |
pthreads for Makefiles/cygwin (don't forget to update lib/windows). |
Revision 3f5fd39 by Campbell Barton February 25, 2006, 15:05 (GMT) |
removed typos causing MTL loading to fail. |
Revision d9f9e76 by Nathan Letwory February 25, 2006, 14:53 (GMT) |
==SCons== + 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. |
February 25, 2006, 13:43 (GMT) |
converted sqrtf to SimdSqrt Solaris has no sqrtf. Kent |
Revision 66e1c90 by Ton Roosendaal February 25, 2006, 12:49 (GMT) |
Bugfix: CTRL+select on a Bone, while in editmode Curve, crashed. |
Revision 02a931a by Ton Roosendaal February 25, 2006, 11:56 (GMT) |
Replacing SDL threads with pthread. 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. |
Revision e377a5f by Nathan Letwory February 25, 2006, 10:40 (GMT) |
==SCons== * 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! |
Revision 8dd1905 by Nathan Letwory February 25, 2006, 01:06 (GMT) |
==SCons== * 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!) |
Revision 9202ec2 by Nathan Letwory February 24, 2006, 18:55 (GMT) |
==SCons== * compile game-engine libs only when actually enabled |
Revision 5e31630 by Chris Want February 24, 2006, 14:37 (GMT) |
I had to disable mmap altogether for Irix. |
|
|
|


Master Commits
MiikaHweb | 2003-2021