this can be brought back as a new space if someone decides to
work on it.
This also fixes remaining issues with the outliner tree open
and close buttons not working sometimes.
Got the basic envelope modifier code working, including primitive drawing of relevant helper info in the graph view. It doesn't work in a very intuitive way yet, so I will recode it soon.
Notes:
* Sequence transform strip uses G.scene global, this is commented
out now, should be fixed.
* Etch-a-ton code was most difficult to merge. The files already in
2.5 got merged, but no new files were added. Calls to these files
are commented out with "XXX etch-a-ton". editarmature.c and
transform_snap.c were complex to merge. Martin, please check?
* Game engine compiles and links again here for scons/make/cmake
(player still fails to link).
* Rewrote the Generator modifier to be more efficient and support more options
* A few UI tweaks for this, but the UI for this is still not yet functional though.
Animsys bugfix: files didn't read or write all supported animdata
structs yet (key was missing for read, crashing). Now it supports
all 10 implemented ID types:
OB CU KE MA TE NT LA CA WO SCE
When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose.
Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu).
Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
View3D has been split now in a local part (RegionView3D) and a
per-area part (old View3D). Currently local is:
- view transform
- camera zoom/offset
- gpencil (todo)
- custom clipping planes
Rest is in Area still, like active camera, draw type, layers,
localview, custom centers, around-settings, transform widget,
gridlines, and so on (mostly stuff as available in header).
To see it work; also added new feature for region split,
press SHIFT+ALT+CTRL+S for four-split.
The idea is to make a preset 4-split, configured to stick
to top/right/front views for three views.
Another cool idea to explore is to then box-clip all drawing
based on these 3 views.
Note about the code:
- currently view3d still stores some depricated settings, to
convert from older files. Not all settings are copied over
though, like custom clip planes or the 'lock view to object'.
- since some view3d ops are now on area level, the operators
for it should keep track of that.
Bugfix in transform: quat initialize in operator-invoke missed
one zero.
Als brought back GE to compile for missing Ipos and channels.
* Reorganised all animation-related file-writing code to be in the same area in the code, and clearly marked which parts of code are only used to ensure we can load old files to version-patch.
* Added file reading code for new datatypes, so it is possible to load the quit.blend file saved from the previous session. Version patching to work with the new system has yet to be done...
* Assorted whitespace fixes in places I skimmed through...
* Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so.
* Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use...
* Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code).
* File writing code should now only write the new data to files
- Weightpaint back (CTRL+TAB or menu)
Also weightpaint is sortof non-modal, allowing to use all existing
hotkeys while in paint mode. Only leftmouse is overridden.
- Made vpaint and wpaint entirely local, stored in scene (and saved!)
- Small bugfix (also in 2.48): on weightpaint mode, all armature objects
in 3d window were drawing as active poses. Now only the armature
deformer is.
Nice point for the UI agenda: are paint modes on ACTION mouse? Only then
you can combine it with SELECT mouse...
* Removed texfade, wasn't a very useful option (same result can be created with the falloff curve)
* Removed CurveMapping from sculptdata, moved instead to Brush
* Removed rake field from sculptdata, moved to Brush.flag
* Moved Anchored flag from sculpt to Brush, same for direction field
* Removed BrushData, replaced usages with the regular Brush type
* Removed hardcoded brushes and brush_type from sculptdata, replaced with a pointer to the current Brush
* Made sculpt tool type settable in Brush
* Changed symmetry and axis lock fields to flags
soc-2008-nicholasbishop branch.
Note: any old code with multires_test() or multires_level1_test() can
just be deleted, not needed by the multires modifier.
- remove Verse support. This will be brought back in The Future (probably jiri + me)
This means 5k lines less in blenkernel.
- fix two small errors for global cleanup, now compiles properly with FFMPEG enabled too.
Think global, act local!
The old favorite G.scene gone! Man... that took almost 2 days.
Also removed G.curscreen and G.edbo.
Not everything could get solved; here's some notes.
- modifiers now store current scene in ModifierData. This is not
meant for permanent, but it can probably stick there until we
cleaned the anim system and depsgraph to cope better with
timing issues.
- Game engine G.scene should become an argument for staring it.
Didn't solve this yet.
- Texture nodes should get scene cfra, but the current implementation
is too tightly wrapped to do it easily.
* Store RNA collections different in ID properties, using a generic
ID property array, using the patch provided by Joe.
* Fix bug accessing registered operator properties in the wm from the
outliner.
* In the outliner, only use the RNA icon for RNA data, and use dot
again for unknown icon.
* Also, show pointer properties data in the second column, and auto
expand two levels when opening them.
* Added small RNA_struct_defined_properties function to get only the
defined properties without builtin and undefined id properties
(for py operators).
* Added a report list to operator, to which they can report errors and
warnings. When the operator ends, it will display them with a popup. For
python these should become exceptions when calling operators.
* Added a function to make a popup menu from a report list.
* Also added a utility function to prepend a string before the reports to
indicate what they relates to. Also made the report functions used
BLI_dynstr to simplify the code.
* Made file reading and writing report errors to the user again using this
system, also replacing the left over uncommented bad level error() calls.
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
* API and usage is basically the same still.
* Panels were moved to region level. I first thought of keeping them at area
level, but having them at region level it's simpler to handle events and do
drawing, and also to integrate with view2d. They can still become area level
overlapping regions, if we make a floating (or docked) region that can
contain panels.
* Added back a few panels from the scene buttons for testing.
Issues still:
* The view2d handling and alignment refresh of panels is not correct yet in the
buttons window.
* I did not yet bring back the block handlers system. It was basically a system
that stored which panel was open and where the events for that panel would go.
Just a few functions, but not sure how it fits in 2.5.
* There was a case where dragging panels would not properly remove the window
level handler, but could not redo anymore even though I don't think I fixed
it.
* Some text in the panels goes past the end of the button, that is due to the
checkmark button drawing, not related to this commit.
Other UI code changes:
* Renamed interface.h to interface_intern.h for consistency.
* Fixed some issues with freeing of blocks when they changed due to context.
* uiDrawBlock now takes a context pointer (mostly for block drawextra).
DONE:
* moved almost all declarations from BLI_blenlib.h into their own proper header files.
* BLI_blenlib.h still includes all the declarations for convenience and to avoid changes in existing code
* split util.c into several files, where it wasn't done already
* DynamicList -> dynamiclist,
* ListBase -> listbase,
* String utility functions -> string.c
* removed a few unused macros and functions, if they're needed back, they're still in svn ;)
TODO:
* btempdir global
* further cleanup in the code of the different modules (especially util.c)
- removed context usage, should not be in this module
- remove G.main usage, now is passed along
- still some globals in use here, goal is to get rid of those too,
so that it's possible to load/save blendfiles without having to
think about some global state.
Context API
This adds the context API as described here. The main practical change
now is that C is not longer directly accessible but has to be accessed
through accessor functions. This basically adds the implementation of
the API and adaption of existing code with some minor changes. The next
task of course is to actually use this design to cleanup of bad level
calls and global access, in blenkernel, blenloader.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Context
Error, Warning and Debug Info Reporting
This adds the error reporting API as described here. It should help
clean up error() calls in non-ui code, but eventually can become used
for gathering messages for a console window, and throwing exceptions
in python scripts when an error happens executing something.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Reports
that is not supposed to be in the editor but at blenkernel level
to avoid bad level calls. Added sequencer free and strip iterator
functions there and used them to make sequencer data load/save
work again.
This commit introduces a new texture ('Voxel Data'), used to load up saved voxel
data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández
with some additional tweaks. Thanks, Raúl!
The texture works similar to the existing point density texture, currently it
only provides intensity information, which can then be mapped (for example) to
density in a volume material. This is an early version, intended to read the
voxel format saved by Raúl's command line simulators, in future revisions
there's potential for making a more full-featured 'Blender voxel file format',
and also for supporting other formats too.
Note: Due to some subtleties in Raúl's existing released simulators, in order
to load them correctly the voxel data texture, you'll need to raise the
'resolution' value by 2. So if you baked out the simulation at resolution 50,
enter 52 for the resolution in the texture panel. This can possibly be fixed in
the simulator later on.
Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1
and it can appear rotated 90 degrees incorrectly. This will be tackled, for now,
probably the easiest way to map it is with and empty, using Map Input -> Object.
Smoke test: http://www.vimeo.com/2449270
One more note, trilinear interpolation seems a bit slow at the moment, we'll
look into this.
For curiosity, while testing/debugging this, I made a script that exports a mesh
to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels,
rendered as a volume: http://www.vimeo.com/2512028
The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py
* Another smaller thing, brought back early ray termination (was disabled
previously for debugging) and made it user configurable. It now appears as a new
value in the volume material: 'Depth Cutoff'. For some background info on what
this does, check:
http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/
* Also some disabled work-in-progess code for light cache
Since we'll reshuffle a lot in UI code, making new Screens totally
incompatible, this patch saves the Screen chunk in Blender files
with a new identifier (ID_SCRN), causing it to be not read in old
Blender binaries. Pre-2.50 blender already has a facility to recover
from this (it keeps old UI), including for .B.blends (it opens
default simple screen)
For the latter reason, it might be advisable to have the .B.blend
for 2.50+ saved as another name? Then you can use both for while.
(Note: commit is just 3 lines of code, other files are comments I
added for documentation of other stuff)
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
Robin (Frrr) Allen did a decent job on this, so we can also welcome him
as a member in the svn committers team to maintain it!
I do the first commit with some minor fixes:
- get Makefiles work
- fix rounding issue with tiles on unit faces
- removed UI includes from tex node
A nice doc in wiki is here:
http://wiki.blender.org/index.php/User:Frr/TexnodeManual
On the todo for Robin is:
- When using one or more Texture-input nodes, you cannot edit them by activating
(as works now for Material nodes).
- The new "output node" option fails on the default case, when only one
output node is active. It then shows often a blank menu. Will get fixed asap.
- When using a NodeTree-Texture as input node, the menu for 'active output'
should not show. NodeTree should ignore other nodetrees to keep things sane
for now.
- On a future todo is proper usage of "Dxt" and "Dyt" texture vectors for
superior antialising of checkers/bricks.
General note; I know people are dying to get a full integrated shader system
with nodes. In theory we could merge this with Material Nodetrees... but I
rather wait for a solid and very well thought out design proposal for this,
also including design ideas for unifying with a shader language (GPU, CPU).
For the time being this is a nice extension of current textures. :)
This introduces a few new ways of modifying the intensity and colour output
generated by the Point Density texture. Previously, the texture only output
intensity information, but now you can map it to colours along a gradient
ramp, based on information coming out of a particle system.
This lets you do things like colour a particle system based on the individual
particles' age - the main reason I need it is to fade particles out over time.
The colorband influences both the colour and intensity (using the colorband's
alpha value), which makes it easy to map a single point density texture to
both intensity values in the Map To panel (such as density or emit) and colour
values (such as absorb col or emit col). This is how the below examples are
set up, an example .blend file is available here:
http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend
The different modes:
* Constant
No modifications to intensity or colour (pure white)
* Particle Age
Maps the color ramp along the particles' lifetimes:
http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov
* Particle Speed
Maps the color ramp to the particles' absolute speed per frame (in Blender
units). There's an additional scale parameter that you can use to bring this
speed into a 0.0 - 1.0 range, if your particles are travelling too faster or
slower than 0-1.
http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov
* Velocity -> RGB
Outputs the particle XYZ velocity vector as RGB colours. This may be useful
for comp work, or maybe in the future things like displacement. Again, there's
a scale parameter to control it.
http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
This is the first code for the Data API, also known as RNA system in the
2.5 Branch. It does not include a user interface, and only wraps some
Scene properties for testing. It is integrated with Scons and Makefiles,
and compiles a 'makesrna' program that generates an RNA.c file.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataAPIhttp://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNA
The changes are quite local, basically adding a makesrna module which
works similar to the makesdna module. The one external change is in
moving genfile.c from blenloader to the makesdna module, so that it can
be reused by the RNA code. This also meant changing the DNA makefiles.
It seems to be doing dependencies correct still in my tests, but if
there is an issue with the DNA not being rebuilt this commit might be
the one causing it. Also it seems for scons the makesdna and makesrna
modules are compiling without warnings. Not a new issue but this should
be fixed.
The RNA code supports all types as defined in the Data API design, so
in that sense it is fairly complete and I hope that aspect will not
have to change much. Some obviously missing parts are context related
code, notify() functions for updates and user defined / ID properties.
* subsurf code had a lot of unused variables, removed these where they are obviously not needed. commented if they could be useful later.
* some variables declorations hide existing variables (many of these left), but fixed some that could cause confusion.
* removed unused vars
* obscure python memory leak with colorband.
* make_sample_tables had a loop running wasnt used.
* if 0'd functions in arithb.c that are not used yet.
* made many functions static
Removed all the old particle rendering code and options I had in there
before, in order to make way for...
A new procedural texture: 'Point Density'
Point Density is a 3d texture that find the density of a group of 'points'
in space and returns that in the texture as an intensity value. Right now,
its at an early stage and it's only enabled for particles, but it would be
cool to extend it later for things like object vertices, or point cache
files from disk - i.e. to import point cloud data into Blender for
rendering volumetrically.
Currently there are just options for an Object and its particle system
number, this is the particle system that will get cached before rendering,
and then used for the texture's density estimation.
It works totally consistent with as any other procedural texture, so
previously where I've mapped a clouds texture to volume density to make
some of those test renders, now I just map a point density texture to
volume density.
Here's a version of the same particle smoke test file from before, updated
to use the point density texture instead:
http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend
There are a few cool things about implementing this as a texture:
- The one texture (and cache) can be instanced across many different
materials:
http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png
This means you can calculate and bake one particle system, but render it
multiple times across the scene, with different material settings, at no
extra memory cost.
Right now, the particles are cached in world space, so you have to map it
globally, and if you want it offset, you have to do it in the material (as
in the file above). I plan to add an option to bake in local space, so you
can just map the texture to local and it just works.
- It also works for solid surfaces too, it just gets the density at that
particular point on the surface, eg:
http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov
- You can map it to whatever you want, not only density but the various
emissions and colours as well. I'd like to investigate using the other
outputs in the texture too (like the RGB or normal outputs), perhaps with
options to colour by particle age, generating normals for making particle
'dents' in a surface, whatever!
Grease Pencil is now available in the image editor. It is important to note that the strokes drawn WILL NOT become part of the image visible at the time.
Unfortunately, 'fancy' stroke drawing cannot be enabled for use with the 'Stick to View' setting here, as the scaling is wrong.
- For newtonian particles a "self effect" button in particle extras makes the particles be effected by themselves if a particle effector is defined for this system, currently this is a brute force method so things start getting slow with more than ~100 particles, but this will hopefully change in the future.
- Two new effector types: charge and a Lennard-Jones potential based force (inter-molecular forces for example).
-Charge is similar to spherical field except it changes behavior (attract/repulse) based on the effected particles charge field (negative/positive) like real particles with a charge.
-The Lennard-Jones field is a very short range force with a behavior determined by the sizes of the effector and effected particle. At a distance smaller than the combined sizes the field is very repulsive and after that distance it's attractive. It tries to keep the particles at an equilibrium distance from each other. Particles need to be at a close proximity to each other to be effected by this field at all.
- Particle systems can now have two effector fields (two slots in the fields panel). This allows to create particles which for example have both a charge and a Lennard-Jones potential.
Introduction of a new Delay sensor that can be used to
generate positive and negative triggers at precise time,
expressed in number of frames.
The delay parameter defines the length of the initial
OFF period. A positive trigger is generated at the end
of this period. The duration parameter defines the
length of the ON period following the OFF period.
A negative trigger is generated at the end of the ON period.
If duration is 0, the sensor stays ON and there is no
negative trigger.
The sensor runs the OFF-ON cycle once unless the repeat
option is set: the OFF-ON cycle repeats indefinately
(or the OFF cycle if duration is 0).
The new generic SCA_ISensor::reset() Python function
can be used at any time to restart the sensor: the
current cycle is interrupted and no trigger is generated.
