Unlike the existing file output node this node has an arbitrary number of
possible input slots. It has a base path string that can be set to a general
base folder. Every input socket then uses its name as an extension of the base
path for file organization. This can include further subfolders on top of the
base path. Example:
Base path: '/home/user/myproject'
Input 1: 'Compo'
Input 2: 'Diffuse/'
Input 3: 'details/Normals'
would create output files
in /home/user/myproject: Compo0001.png, Compo0002.png, ...
in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base
given)
in /home/user/myproject/details: Normals0001.png, Normals0002.png, ...
Most settings for the node can be found in the sidebar (NKEY). New input sockets
can be added with the "Add Input" button. There is a list of input sockets and
below that the details for each socket can be changed, including the sub-path
and filename. Sockets can be removed here as well. By default each socket uses
the render settings file output format, but each can use its own format if
necessary.
To my knowledge this is the first node making use of such dynamic sockets in
trunk. So this is also a design test, other nodes might use this in the future.
Adding operator buttons on top of a node is a bit unwieldy atm, because all node
operators generally work on selected and/or active node(s). The operator button
would therefore either have to make sure the node is activated before the
operator is called (block callback maybe?) OR it has to store the node name
(risky, weak reference). For now it is only used in the sidebar, where only the
active node's buttons are displayed.
Also adds a new struct_type value to bNodeSocket, in order to distinguish
different socket types with the same data type (file inputs are SOCK_RGBA color
sockets). Would be nicer to use data type only for actual data evaluation, but
used in too many places, this works ok for now.
New method of vertex shapekey propagation didn't restored coordinates in
me->mvert array which lead to unwanted deformation of basis mesh and
lead to issues like described in the report.
corrently allows to create and loop over verts/edges/faces, access selection and selection modes.
this is still WIP, access to face, edge verts is still missing, no access to UV's, no access to editing operations yet.
When the api is ready it will be documented by sphinx like mathutils, blf, aud.
In fact, error was much deeper and DND parenting in outliner used to parent all selected
objects to drop target, not just currently dragging object.
This was caused by code sharing between Parent Set operator and this DND operator which
was iterating all selected objects in scene and was setting parent to it.
Solved issue by separating actual parenting code which makes specified object be parented
to specified parent and moved iterating to Parent Set exec callback.
Now both of discovered issues (unneeded loop error and parenting all selected objects)
are solved, but more extensive testing of this changes are welcome.
Added bmesh to player libraries and changed the priority of blenlib so as to avoid duplicate definitions (looks like there are actually functions defined twice that cause conflicts if one changes the order of linking...figures).
Only tested this on mingw-windows, I hope it works elsewhere too.
Unfortunately since we are missing a way to tesselate uvs, the result will look good only on concave faces since we are essentially using a triangle fan to draw. When a tesselation of uv polygons is possible the tool should also change to use that instead. This will also influence the preview drawing code, coming next.
- Removed validate() callback for MDisps layer. It wouldn't actually work
correct from CustomData layer and all needed data might be validated from
BMesh interpolation level. Also this callback was never actually used in
BMesh, so can't see why we'll want to have it in structures.
- Removed layrInterp_mdisps callback. Interpolation now happens from
another level (bmesh_interp) and this callback isn't needed anymore.
- Removed all function from multires.c which were used by old interpolation
stuff and seems to be useless for other usages.
- multires_topology_changed is still marked as a TODO, Probably it's not
needed anymore, buy better to keep for now until it'll be 100% clear this
function isn't needed and all needed re-allocations happens in bmesh_interp.
Otherwise, it'll be needed to be ported to new system.
functions instead of own macros for vectors.
- Double precision isn't needed here at all. It only makes it impossible to use
mathutils, adds extra float<->double conversions without any benefits.
(current multires interpolation is already an approximate method and it can't
be improved using double precision)
This is needed because displacement might been interpolated from a grid
with different orientation and in this case X and Y components of displacement
are need to be flipped in needed order.
Order of flipping is determining by projecting source grids axis orientation
on target grid axis. This probably will give some unwanted artifacts when
interpolating non-planar face but currently can't think about better way
to determine how to flip displacement.
This commit makes operators like Subdivide works much more unpredictable
for sculpting data, but this stuff should be rethinked much more global
because current approach is not acceptable.
As with multires, this change calculates face normals rather than
using vertex normals when the node is flat-shaded.
Flat-shading with VBO on non-multires meshes is still wrong, but
fixing that would require larger changes to our vertex buffers.
thanks to Nicholas Bishop for finding the cause of the problem.
don't tesselate on load, this means me->mface will be NULL by default.
we may need to have this set if existing uses of this array are not resolved before release - so add a define USE_TESSFACE_DEFAULT, to change this easily.
this is a rather indirect fix - need to take care here.
