causing building without OPENEXR to fail. (Hopefully this doesn't mess up
current scons stuff, shouldn't but I haven't tested it after latest
changes in scons)
(I also cleaned up the Makefile a tad so it didn't check twice for WITH_OPENEXR)
Kent
Image as loaded in Blender (from openexr.com):
http://www.blender.org/bf/exrcurve1.jpg
Image with different white point:
http://www.blender.org/bf/exrcurve2.jpg
Image with white and black point and a curve:
http://www.blender.org/bf/exrcurve3.jpg
Use SHIFT+click to set the black point, and CTRL+click for white point.
The buttons in the panel work too, of course.
The curves work after the black/white range was corrected, so you can
stick to curves with a normal 0-1 range.
There's also now a general color curve, marked with 'C' button.
Note; this currently only maps the float colors to a visible 8 bits per
channel rect. You can save it, but when the blender file loads the curve
or mapping is not executed until you click in the curves... have to look
at that still.
Speed for this is also quite unoptimized... still WIP, but fun!
- Reading exr images now goes OK. I've unified the code for reading
'half' and 'float' (was nicely possible!). And removed useless copying
of data around.
- Fixed bug in allocating new rects, like for making mipmaps. flag issues.
- filter code accidentally incremented wrong pointer (crash on mipmap too)
On duplicating an object with material ipos that has drivers, the new ipos
(if material and ipos were copied) didn't get the correct pointer to the
new driver object (if that was copied!)
- F10 scene buttons now has options "half" and "zbuf" for exr saving.
Note: when no float buffer is available, it always saves as "half",
that's sufficient anyway, since half is 16 bits per channel.
- EXR in imbuf now uses compliant ibuf->ftype flags for denoting exr
extensions such as 'half' and 'compression'.
- Removed ugly blenkernel dependency from exr module
These should make it so that other people can compile with OpenEXR support.
(I also added the OPENAL fix erwin commited to bf-blender since I
need it for my machine, and this syncs up the file)
Kent
Credits go to Gernot Ziegler, who originally coded EXR support, and to
Austin Benesh for bringing it further. Kent Mein provided a lot of code
for integrating float buffers in Blender imbuf and ImBuf API cleanup,
and provided Make and Scons and static linking.
At this moment; the EXR libraries are a *dependency*, so you cannot get
the Orange branch compiled without having OpenEXR installed. Get the
(precompiled or sources) stuff from www.openexr.com. Current default is
that the headers and lib resides in /user/local/
Several changes/additions/fixes were added:
- EXR code only supported 'half' format (16 bits per channel). I've added
float writing, but for reading it I need tomorrow. :)
- Quite some clumsy copying of data happened in EXR code.
- cleaned up the api calls already a bit, preparing for more advanced
support
- Zbuffers were saved 16 bits, now 32 bits
- automatic adding of .exr extensions went wrong
Imbuf:
- added proper imbuf->flags and imbuf->mall support for float buffers, it
was created for *each* imbuf. :)
- found bugs for float buffers in scaling and flipping. Code there will
need more checks still
- imbuf also needs to be verified to behave properly when no 32 bits
rect exists (for saving for example)
TODO:
- support internal float images for textures, backbuf, AO probes, and
display in Image window
Hope this commit won't screwup syncing with bf-blender... :/
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
a 2d window 3 (three!) times on every event! This explains why scrollwheel
seems to lag quite some when used in buttons or outliner.
The view2dzoom() and view2dmove() code is horrid. Nice project for someone
is to move all 2d (View2D struct related) code into its own C file. A lot
of that is spread around in the code.
- Moved all 'render pipeline control' options out of the Material panels
into the (now renamed) "Links and Pipeline" Panel. These are the options
that are not per material-node, but global for the entire Material tree.
It includes ZTransp, Zinvert, Strands, Halo, Wire, etc.
- To further make Node editing clear, when you enable Nodes for the first
time, the link button to the first Material node is drawn red, to note
that here needs something linked or added.
- Protected Node editing for Library data
- Fixed header buttons to work OK for Node Window
- On linking stuff from libraries, each relative path now is relative with
respect to the file that uses the library.
This way you can make libraries that use other libraries, and link them
in your project with an entire different relative path.
The commit also fixes issues when mixing up relative or non-relative paths.
Now after this I need to commit something cool, so the orangers will update
and check! :)
movie friends :)
There were two issues with it, which both have been tackled as follows:
- the correction transformations (quaternions) were calculated per face,
and then averaged over the vertices. This gave annoying inaccuracies,
especially when the geometry is irregular.
The new code first calculates two tangent vectors in a vertex, based on
the associated edges it has in a face. These tangents then are used to
define the transform. Tangents are 20% of the length of an edge now.
- When a SubSurf modifier was in the chain, the deformation caused by the
subsurf was also included in CrazySpace correction, giving even larger
errors.
New code temporally disables Subsurf, recalculates vertices, and then
does the crazy tricks. :)
All in all, quite well working!
- New Node: "Mapping". Allows input vector to be translated, rotated and
scaled. And optional be clipped to a range. Works for colors too!
- The button "Normal" now allows incremental input, so a click in the
button won't change the normal anymore
- Connecting wires now show selection state for Nodes, with nice blended
colors. Both colors were added in Themes, but default to black and white
Threadsafe patch for environment maps type "Load" missed to include a
call, so still crashed. Only for non-debug builds though, so not reported
earlier.
From my cvs log 7 months ago:
"Added threadsafe patch from Martin.
Now envmaps of type "Load" should not give errors. I assume Martin tested!"
:)
With the fix over a month ago, which added correct texture space vectors for
the bump, gave results so crispy that normals could invert after normalize.
This only when the normal "fac" slider was > 1.0.
The normals from imagetextures now get clipped to prevent it to result in
flipping normals. Will do more tests though...
Also note that the real good way would be have the tangent vectors for the
actual render normal available to perturb for bump, thats another story.
guitargeek), this commit enhances the support for temporary storage
for the structs EditVert, EditEdge, and EditFace. The field
"EditVert *vn" has been removed and replaced by a union called
"tmp" that can hold:
v, an EditVert pointer;
e, an EditEdge pointer;
f, an EditFace pointer;
fp, a float pointer;
p, a void pointer;
l, a long;
Please see the mailing list post here for more information about
this:
http://projects.blender.org/pipermail/bf-committers/2005-December/012877.html
- Found the potential crasher for sound playback & undo. Test!
- PoseMode: NKey panel didn't work when actions where assigned
- NLA: "Add action strip" now displays in menu to which active object the
actions are added.
- Previews inside groups now get updated too
- Activating nodes inside of groups updates UI and preview render correctly
- Entering/leaving groups updates UI and previewrender
- Material Node: now draws socket name next to colorpicker for inputs
Object.GetSelected now dosnt return None if there is no 3d view. - wasnt documented and likely would mess up scripts that always expected a list. - Just return an empty list instead.
getting 7200 objects did take: 1.18 sec, now 0.0012 sec
It was doing a full object list lookup for every object in the scenes base using the name to compare.
now it just gets the object directly from the base and converts it to a python object, adding it to the list.
- Cam