under linux / x11 / KDE.
The new behaviour in 2.34, not recreating the render window on re-render,
revealed that raising windows did not work under some window managers. Now the
"net wm extensions" are used if available, otherwise it will work the same way
as before (e.g. Gtk+ does this as well).
More info:
http://www.freedesktop.org/Standards/wm-spec
Read today's meeting minutes for a description.
Bjornmose: We'll need some example and screenshots for the dev pages of blender3d.org. If you can do some, neat, if not, I'll do them.
Matt, Emilie and Chris: Please review UI addition. Pixel alignement and all that fun stuff has not be overly looked for (though I did some cleaning by adding alignment blocks).
- file-to-memory save
- incremental difference steps (compression)
everthing has been tightly coded to use minimum of memcpy or allocs. In
fact this system works with a single full buffer (=file) in memory, and undosteps as differences from it.
Speed gain is factor 4-8 faster. I've added it in CTRL+ALT+T timer menu for
a test. Please note the gain is especially in the undo-storing, not in
retrieving undo.
Also new: file read option to skip UI read (file menu). This now also is
default for the undo system.
Removed a block of a bunch of unused vars...
Added a return NULL to the end of a funtion that is suppose to
return something and could fall through.
editconstraint.c
Added a newline to the end of the file to get rid of a stupid warning.
Kent
They were not needed were for functions that were in the same .c file
higher up and I think its sort of a non standard way of doing things.
(using prototypes would probably be more inline with the other code but
as I mentioned they are not needed and were causing warnings in gcc)
Kent
LEVEL_2_CPP_WARNINGS += -Wstrict-prototypes
LEVEL_2_CPP_WARNINGS += -Wmissing-prototypes
Every version of g++ i've used has stated these two were not for g++
but for c or objectivec.
Kent
- transform (grab, rot, scale, etc)
- all button commands, including menus
I sacrificed for now the UKEY in the 3d window for it. Shift+U does a redo.
(Only in 3d window)
What this system does is saving files in the temp directory (user pref).
The filenames are cycled around (32 in total now).
This commit will follow shortly with a userpref for it, not to frustrate
people who want to work in normal fashion with blender.
I cleaned up the code a little did a couple of these:
if (blah > stuff - wah) blah = stuff - wah;
changed to....
tmp = stuff - wah;
if (blah > tmp) blah = tmp;
and combined multiple if statements
Kent
separate it...
1) Curve/Surface editmode undo
Uses same syntax as mesh undo, so simple to integrate. Edit-curve data is
also quite simpler, so no need for any hack at all.
It re-uses the undo system from next point, which is nice short & clean
local code
2) Framework for global undo
The undo calls themselves are commented out. In a next commit I want to
enable it for a couple of main features, for further feedback.
The speed goes surprisingly well, especially with this new version that
'pushes' undo after a command, ensuring interactivity isnt frustrated
3) framework for texture based icons in Blender
Not activated code, but tested here. Part of 2.3 UI project.
btw: Johnny Matthews will assist in (and complete) the undo project
I added ifdef's around a var declaration since the code using
it had them... Also initalized two vars that were questionable if they
could reach a state where they weren't assigned.
Kent
raytracer. Instead of only tracing the current subpixel it did all
(or most) of them.
Solves reports on slow AO in 2.34, but also will affect ray_mir and transp
Caught from the following warning:
In file included from IK_QChain.h:47,
from IK_QChain.cpp:44:
TNT/cmat.h: In function `void TNT::matmultdiag(TNT::Matrix<T>&, const TNT::Matri
x<T>&, const TNT::Vector<T>&)':
TNT/cmat.h:593: warning: left-hand operand of comma has no effect
Kent
Next to the "BevOb" button you now have a "TaperOb" button to give a name
of a curve object which defines the width of extrusion of the 'BevObj'
along the curve. The TaperOb curve typically is horizontal, where the
height denotes the width.
Important rules;
- Only the firste curve in TaperObj is evaluated
- the first width is left, last width is right
- it scales the width of normal extrusions based on evaluating the taper
curve; which means sharp corners in taper curve won't be easily visible
(That latter feature could be improved by extrusing based on the points
in the taper curve; this is a *lot* more work)
Triangulation of these quads could lead to degenerate triangles, resulting
in UV's in random places. Now quads are automatically triangulated in the
best direction.
This bug was reported by Tim Fisher (thanks!).
