Note: This work on the icons are for my own personal interest. Don't expect these in the official Blender builds.
Tweak and fullscreen enabled as per usual.
Patched with Artificer's array modifier. Details on that one here:
http://mediawiki.blender.org/index.php/ ... ayModifier
Also patched with geoffrey Bantle's enhanced merge. Details here:
Disclaimer from Ton on fullscreen feature:
Selective reading from the changelogs:I like to make a note that the removed "Fullscreen" windows option will cause OpenGL in Blender to not work properly. It was removed because the code was just too bad and quick hack.
I know the functionality is great and appreciated, but we have to wait for someone presenting us a more solid solition for it.
UV Editor Tweaks:
- Set local sticky in the uv editor as default.
- Don't do live unwrap on fully selected charts or charts with no pins
- Fixed bug with live unwrap not respecting transform cancel in some cases.
- "View Home" didn't work without an image.
- Move UV Calculation settings (cube size, cylinder radius, ..) into the scene
toolsettings, instead of global variables
- Remove the name LSCM from the UI (and python docs on seams), and replace it
with 'Unwrap', with upcoming ABF this didn't make sense anymore.
- Move the Old/New LSCM switch into the UV Calculation panel. New LSCM is the
default now. Also renamed LSCM there to "Conformal".
- Made some room in the UV Calculation panel by removing the buttons to execute
the UV calculation, only leaving the settings.
- LSCM now has an option to fill holes in the chart before unwrapping. This on
by default, and enables two things:
- Prevent internal overlaps (e.g. eyes, mouth) for LSCM unwrapping.
- Allow the internal boundaries to move freely during stretch minimize.
- The possibility to switch it off is there because it is not always possible
to define which the outer boundary is. For example with an open cylinder
where there are two identical holes.
Angle Based Flattening:
- There's an option to enabled ABF in the UV Calculation panel.
- ABF works with seams, pinning, live transform etc. UI wise it's pretty
much the same as LSCM.
- ABF favors low angular distortion over area distortion, much like LSCM.
It does however not have the tendency to "collapse" under high stretch,
which basically means that it will be able to handle complex charts
- ABF does however have on serious drawback: it is sensitive to degenerate
geometry, especially very small angles. I'm working on this, but it seems
to be quite difficult to improve the situation. There's still a bunch of
ideas left to try, but I'll just commit this now as is. If ABF fails, it
will fall back to LSCM, and there will be a warning print in the console.
- This implementation has the matrix tricks from ABF++ also. The second part
of ABF++, simplification before unwrap, is being worked on. The current
- ABF is about 3-4 times slower than LSCM, which was to be expected. For
live transform however, once the initial computation is done, it's just as
snappy as the new LSCM code.
Results are quite nice though:
You may recognize the Snurgle model by Colin Levy there.
Whole bunch of sequencer stuff by Peter Schlaile which I'm to lazy to copy and paste:P
iImage based Vector Blur
After a couple of experiments with variable blur filters, I tried
a more interesting, and who knows... original approach.
First watch results here:
These are the steps in producing such results:
- In preprocess, the speed vectors to previous and next frame are
calculated. Speed vectors are screen-aligned and in pixel size.
- while rendering, these vectors get calculated per sample, and
accumulated in the vector buffer checking for "minimum speed".
(on start the vector buffer is initialized on max speed).
- After render:
- The entire image, all pixels, then is converted to quad polygons.
- Also the z value of the pixels is assigned to the polygons
- The vertices for the quads use averaged speed vectors (of the 4
corner faces), using a 'minimum but non-zero' speed rule.
This minimal speed trick works very well to prevent 'tearing' apart
when multiple faces move in different directions in a pixel, or to
be able to separate moving pixels clearly from non-moving ones
- So, now we have a sort of 'mask' of quad polygons. The previous steps
guaranteed that this mask doesn't have antialias color info, and has
speed vectors that ensure individual parts to move nicely without
tearing effects. The Z allows multiple layers of moving masks.
- Then, in temporal buffer, faces get tagged if they move or not
- These tags then go to an anti-alias routine, which assigns alpha
values to edge faces, based on the method we used in past to antialias
bitmaps (still in our code, check the antialias.c in imbuf!)
- finally, the tag buffer is used to tag which z values of the original
image have to be included (to allow blur go behind stuff).
- OK, now we're ready for accumulating! In a loop, all faces then get
drawn (with zbuffer) with increasing influence of their speed vectors.
The resulting image then is accumulated on top of the original with a
decreasing weighting value.
It sounds all quite complex... but the speed is still encouraging. Above
images have 64 mblur steps, which takes about 1-3 seconds per frame.
- Make sure the render-layer has passes 'Vector' and 'Z' on.
- add in Compositor the VectorBlur node, and connect the image, Z and
speed to the inputs.
- The node allows to set amount of steps (10 steps = 10 forward, 10 back).
and to set a maximum speed in pixels... to prevent extreme moving things
to blur too wide.
Wanted feature for curves: a render-time resolution. This option is
located under the 'def resolu' button. If not zero, it assigns this
resolution to a curve on render.
Also copies with ctrl+c menu.
Upgraded max limit for faces in render. Up to now, quads were zbuffered
as triangles, with a tag bit to denote which triangle was which part of
the quad. That was hardcoded bit 0x800000, which allows a maximum of
about 8 million quads...
I've made this a nice #define, set to be 16 times larger. So, now the
facejunkies can go up to 128 Million faces, were it not that this will eat
up a load of memory!
I only have 1 Gig in this machine. A test with 9M vertices and 7.5M quads
eats up 912 MB of memory already. If this becomes a real issue, I know
tricks how to make the vertices 20 bytes smaller, and faces 4 bytes, which
would in the above case save about 200 MB. Not much... but probably worth
the try? A much better method is of course 'bucketing' the renderdata per
tile. It's a spec of the render recode, but not a quicky to add.
Also: bug fix in curve code. There was a short counter still, crashing on
large curves with resol set to 1024
Seam Cutting in Faceselect Mode:
- Mark Border Seam: mark edges on the border of face selection as seam.
- Clear Seam: clears seams in selected faces.
- Alt+RMB Click: mark/clear edge as seam
- Alt+Shift+RMB Click: mark/clear seams along the shortest/straightest path
from last marked seam. The cost of the path also includes some measure of
'straightness' next to the typical distance to make things work more
predicatble and edgeloop friendly. Note that this cuts a path from edge to
edge, not vertex to vertex. That gives some nice control over the direction
of the seam.
- Removed old LSCM code.
- Fix updates glitches with DerivedMesh/Subsurf drawing in FaceSelect mode.
Now there's a drawMappedFacesTex instead of drawFacesTex.
- Minimize Stretch menu entry called Limit Stitch.
- Removed the lasttface global, was being set before it was used anyway, so
might as wel return from a function.
- Moved some backbuf sampling code to drawview.c from editmesh, so it can be
used by Faceselect and VPaint.
- Use BLI_heap in parametrizer.c.
Testing commit for the studio; a bump-correction factor for when images
get sampled on larger distance. It actually just flattens bump when the
sampled area is (much) larger than pixel size, to prevent weird things
(image based on Alexander file
Tested on env's dinos too... seems to work, but we'll see.
Interesting commit for artists using huge textures;
The code that generated mipmaps took a real long time to do it... on a
5k x 5k image it took here (no optim, debug compile) 32.5 sec.
Recoded the very old filtering routine, which already brought it down to
2.8 seconds. Then tested if we even need this filtering... in many cases
the images are painted or photographs, which is filtered OK already.
Without the filter, the mipmap timing went down to 0.39 second.
Here's an example of two 'mips' generated with or without gauss filter.
Note that aliasing in an image remains there... which can be a wanted
So; added the gauss filter as option in making mipmaps. Also had to
reshuffle the buttons there in a more logical manner.
There's also disabled code in the do_versions to set 'gauss' on in older
files. Will be enabled during release time.
Log (Kent Mein):
Added ability to render Zbuffer to an image.
Just use SHIFT-F3 and save an image.
Basically all this does is copy the zbuffer to a new Image buffer
and pass that to the save image function.
Also thanks to Jesterking for helping me debug dumbness...
and the nice screenshot.
With two adjacent quads sharing three vertices, splitting to triangles
could create duplicate triangles. This broke unwrapping of Suzanne near
the nose, where there is a sort of t-joint with quads that isn't really
a t-joint. Now works fine:
Download here:Log (Ton):
Two significant improvements in vectorblur:
1) Accumulation buffer alpha handling
Accumulating colors in an accumulation is simple; a weighting factor can
make sure colors don't over- or undersaturate.
For alpha this is a bit more complex... especially because the masks for
vectorblur are anti-aliased themselves with alpha values. Up to now I just
premultiplied the mask-alpha with the actual color alpha, which worked OK
for solid masks, but not for transparent ones. I thought that would be an
acceptable situation, since 'ztra' faces only get blurred with alpha==1.
However, it gives bad results when using 'mist' in Blender, which just
gives pixels an alpha value based on camera distance. In these cases the
alpha became oversaturated, accumulating into too high values.
The solution is to store the mask-alpha separately, only premultiply this
alpha with the weighting factor to define the accumulation amount.
This is the math:
blendfactor: the accumulation factor for a vectorblur pass
passRGBA: color and alpha value of the current to be accumulated pass
accRGBA: color and alpha value of accumulation buffer (initialized
with original picture values)
maskA: the mask's alpha itself
accRGBA = (1 - maskA*blendfactor)*accRGBA + (maskA*blendfactor)*passRGBA
This formula accumulates alpha values equally to colors, only using the
mask-alpha as 'alpha-over' operation.
It all sounds very logical, I just write this extensive log because I
couldn't find any technical doc about this case.
2) Creating efficient masks with camera-shake
Vector blur can only work well when there's a clear distinction between
what moves, and what doesn't move. This you can solve for example by
rendering complex scenes in multiple layers. This isn't always easy, or
just a lot of work. Especially when the camera itself moves, the mask
created by the vectorblur code becomes the entire image.
A very simple solution is to introduce a small threshold for
moving pixels, which can efficiently separate the hardly-moving pixels
from the moving ones, and thus create nice looking masks.
You can find this new option in the VectorBlur node, as 'min speed'.
This mimimum speed is in pixel units. A value of just 3 will already
clearly separate the background from foreground.
Note; to make this work OK, all vectors in an image are scaled 3 pixels
smaller, to ensure everything keeps looking coherent.
Test renders; 'Elephants Dream' scene with lotsof moving parts; rendered
without OSA, image textures, shadow or color correction.
With vectorblur, showing the alpha-saturation for mist:
New accumulation formula:
Same image, but now with a 3 pixel minimum speed threshold:
Next frame, without minimum speed
Same frame with speed threshold:
(Only 20 steps of vectorblur were applied for clarity).
http://www.graphicall.org/builds/builds ... show&id=88
And, as always - have fun!