New diffuse shader, "Fresnel", which using existing fresnel formula.
Since it hilights edges (away from lamp), nice to fill darker parts with
the new layering system.
Weird stuff though;
http://www.blender.org/bf/0001_0040.avi
(Movie disappears in a couple of days!)
Note; for ray-shadow you need to use the Bias, to prevent 'terminator'
problems. I made that option default now.
(WIP, don't bugs for this in tracker yet please!)
- New Panel "Layers" in Material buttons, allows to add unlimited amount
of materials on top of each other.
- Every Layer is actually just another Material, which gets rendered/shaded
(including texture), and then added on top of previous layer with an
operation like Mix, Add, Mult, etc.
- Layers render fully independent, so bumpmaps are not passed on to next
layers.
- Per Layer you can set if it influences Diffuse, Specular or Alpha
- If a Material returns alpha (like from texture), the alpha value is
used for adding the layers too.
- New texture "Map To" channel allows to have a texture work on a Layer
- Each layer, including basis Material, can be turned on/off individually
Notes:
- at this moment, the full shading pass happens for each layer, including
shadow, AO and raytraced mirror or transparency...
- I had to remove old hacks from preview render, which corrected reflected
normals for preview texturing.
- still needs loadsa testing!
An image texture without picture returned a '0', causing the texture code
to generate a bump normal that warped the entire shading around.
In bugreport it was showing terminator issues with ray shadow.
Terminator problems can still occor with more extreme bumpmaps though,
something to look at further.
Replaced sqrt() with the safe version sasqrt() in anisotropic.
the formula (1 - n*n) should not give negative values for n = dotproduct
of normals, but float inaccuracy can make negative zeros, as we know!
This solves, hopefully, last annoying "blotches" in hair!
raytracing with a linedist (cylinder) check. It didn't behave OK on strands
set to be more than 1 pixel (not to mention 10 pixels), and I have no time
now to fully check and code it.
Which is not really important either... In general, all 3d papers talk about
using shadowbuffer shadows for hair, which gives much nicer results for
dense volumes of polygons.
This commit restores regular (flat polygon) raytrace shadow for strands.
Also fixes some nasty bugs as reported. :)
- raytracing code now uses cylinder-line intersect for strands. It used
to intersect with the screen-aligned strand quads, giving too many
misses for tracing.
Note; mirror for hair is still not well supported!
- added in Materials a choice for whether a material is Traceable for
raytracing or whether it is part of Shadow buffers. This way you can
exclude hair strands from raytracing, but still get shadowbuffers for it.
Very ancient bug in boxfilter for image texture popped up with new code
for correct bumpmapping. Caused texture type "Extend" not to work when
using for bump.
While investigating alternative filters (Mitchell), I found two small
errors in the Gauss code, it clipped wrong and multiplied wrong, causing
settings other than filter size 1.0 to not work properly.
Took the last-minute liberty to add more filter types in Blender too.
Also wrote an extensive log about how sampling & filtering in Blender
works.
http://www.blender3d.org/cms/Samples_and_Filtering.723.0.html
Ancient issue with Image bumpmap & orientation... this report was about
UV textures, which flipped bump direction when UV coordinates rotate.
So... time to dive deeper into it, and I found a very bad old construction
in the way image textures handled bump normals. Instead of using the
correct dx,dy vectors it was calculating the boundbox for it, and applied
it as such (loosing negative direction for the dx or dy that way).
Anyhoo! To make a long story short; the weird "correct Nor Map" option
now can be removed... but requires careful testing!
Here's renders from file I got from env, 239 means old and 240 is this cvs.
http://www.blender.org/bf/dino239.jpghttp://www.blender.org/bf/dino240.jpghttp://www.blender.org/bf/dino239a.jpghttp://www.blender.org/bf/dino240a.jpg
Note the much finer detail, and the more consistant normals direction.
No, go render testing dudes!
- Bone Ghost drawing now skips axes and names
- "Snap to cursor" now works for parent-less bones in PoseMode
- Prevented assigning in buttons of negative zero (was confusing)
on top of each other. Was 100, which gave noise like this in this image;
http://www.blender.org/bf/hairnew.jpg
Made it 200, which solves it for a million hair polygons;
http://www.blender.org/bf/hairnew1.jpg
Also note that hair renders go much faster and better if you insert a real
solid head in it, that will prevent hairs on the back to be inserted in the
buffers. ANd don't make the head Ztransp!
I've been going over the zbuf.c code, which is indeed very ancient,
with a load of old optimizing and redundant code in use.
Added more 'modern' Span support, which fills per face two arrays
with the scanline information in it. That way you can zbuffer a quad in one
run as well. It was also exactly that code that's copied all over in zbuf.c
For now, to prevent issues for the release, the 'render a quad in 1 run' is
only in use for the strand render. Tests reveil a speedup of about 33%.
Will work on this recode later... which would also result in making zbuf.c
threadsafe.
And: bugfix #3398
When using the new 'render emitter' for particles, the orco array for
particles was accidentally used by mesh too.
table stable... you keep correcting leg sizes until no table is left
anymore! :)
This commit restores the displacement direction from 2.37a code, which was
negated 5 months ago to fix a change in renderconverter.c, but somehow is
not needed anymore. The regression displacement file now renders OK again.
Unified render does not return a zbuffer, but when gauss render was used
in combination with motion-blur, a buffer was accidentally created, one
pixel to small even!
Materials; using "Stencil" option, didn't work properly for multiply, and
other related filters. This is a very old issue, but now I found the good
way to fix it! :)
When no Ipo existed yet for an Action Channel (Bone), you could not add
curves with CTRL+click or Drivers. This was due to antique action code
state... it's still messy, no time for big cleanup here yet. At least
this works now. :)
(Also: removed test prints of previous commit)
- Rendering an image with Border didn't check for sizes smaller than 1
pixel yet.
Related to this code I found 2 other fixes:
- Themecolor set for drawing in Render Window was not restored correctly,
sometimes causing into wrong Panel (transparency) drawing.
- When rendering an image with Gauss, it now renders by default 1 pixel
extra, which gets stripped. This eliminates the "ugly" darker border
in images.
(Yes, let's make Mr. PixelCounter Goralczyk happy! :)
First note that this is new functionality, unfinished, and only for
testing and feedback purposes. I'll list below what works, and what will
need work still.
This text is also in cms: http://www.blender.org/cms/Ipo_Drivers.680.0.html
An IpoDriver is like an IpoCurve, but instead of a Bezier curve, it allows
to connect a property of other Objects as input for the "channel". For
example, IpoDrivers can be used to have a Shape Key being "driven" by
the rotation of a Bone. Or the RGB colors of a Material get driven by the
XYZ location of an Object.
Editing of Drivers happens in the IpoWindow. Here you can notice that the
channels (right hand window) now have an "active" channel indicator.
To add a Driver, you have to use the "Transform Properties" Panel (Nkey).
Here you can add or remove a Driver to the active channel, and use the
buttons to fill in what kind of relationship you want to establish.
Driver Objects
Note that any Ipo Channel can become driven now, but that only Object
transformation or Pose Bone transformation can be used to become a
Driver now.
At this moment, only the local transformation is taken into account.
For Objects that means the location/rotation/scale value without Parent
transform (as shown in "Transform Properties" Panel for Objects).
For Pose Bones it means that only the Pose transform (changes of rest
position) is Driver information (also as shown in Transform Property
Panel in Pose Mode).
Mapping of Drivers
When an Ipo Channel is "driven", the mapping is by default one-to-one.
It is only restricted by already built-in limits for Channels, like
for Material the "R" value can only range from 0.0 to 1.0.
Also note that when mapping rotations, the actual rotation values
in Ipos are scaled down with a factor 10.0. (180 degrees actually has
in the Ipo system a value of 18.0). This is an ancient year zero
convention in Blender... it is a bit hidden, because the ruler
(vertical as well as horizontal) displays the virtual values correctly.
Only the Properties panel shows the actual value.
When you draw an IpoCurve in a Driven channel, this curve will define
the mapping between the Driver output (horizontal) and Driven input
(vertical, as usual).
A nice new option to use is "Insert one-to-one curve" (press I-key,
or in pulldown menu). This will also zoom the display in exactly to
fill the window, allowing easy edit. If you use this option with
degrees, it will map 180 degree rotation to a range of 1.0 unit.
Live updates
Since the Drivers are integrated in the Ipo system, they will always
be updated whenever an Ipo is evaluated. This happens at least on
frame changes.
For interactive feedback, updates while transforming objects were
added in these cases:
- Driven Object Ipos, by other Objects or Pose Bones
- Driven Shape Key Ipos, by other Objects or Pose Bones
You can also insert Drivers on Action Ipos, but these are only evaluated
on frame change now.
Todo
- Drivers can also get a text button, allowing a 1 line Python script
to be executed.
- Make UI for it a bit less hidden... maybe with visualization in 3D?
- Allowing global transform coordinates as Driver too.
Issues
- renaming Bones won't rename drivers
- (file) appending the Ipo won't append the linked driver Objects
This means the diffuse and specular shaders don't use the normal
for hair (which is actually undefined, a hair is micro cylinder) but
it uses the tangent vector (vector in direction of hair).
For Diffuse, it computes a fake normal now, representing the optimal
hair normal pointing towards the light. All current builtin shaders
work with this, including ramps.
For Specular, it uses another formula to remap dot products for all
lines that now use the tangent vector instead of the normal:
dot = vector * tangent
dot = sqrt(1.0 - dot*dot)
Gives better results than using the 'fake' normal for diffuse. Officially
(according the papers) this could be used for diffuse too, but then hair
becomes very flat. Now you can control the flatness easily with ramps or
using Oren-Nayer for example.
Example image (disappears in some weeks)
http://www.blender.org/bf/rt9.jpg
- Added new texture channel "Strand" to apply textures on hairs over the
length of hair (1 dimensional). Orco now gives 1 fixed coordinate for
the entire hair, based on where it starts.
Note; UV doesn't work yet. Nor vertexcolor.
http://www.blender.org/bf/rt10.jpg
- AO and soft shadow AreaLight tables were generated without fixed seed,
causing animations to give unwanted amounts of noise.
- Made sure these tables now are calculated before render, with fixed seed
- Then found out the BLI_rand() has very bad seeding... it showed up as
patterns. After some experimenting, found a nice method using noise.c
hash tables. For compatibility with old code, named it BLI_srandom() to
use this next to the BLI_srand(). This follows libc rand() and random()
naming convention.
- Then of course threading should work... so made a BLI_thread_rand version
of the calls. Now supports up to 16 threads, comments added in .h and .c
Result is stable animation render with AO and soft shadow. But, please
test and feedback!
Wire material doesn't work with raytrace, but the wire faces were still
trace-able, giving weird results.
Now the wire faces are excluded from the octree.
Quite harmless, but was lazy code...
When you choosed "Vertex Color Paint" material, the init_render_material()
also set the "Vertex color Light" option, because that flag was checked on
during render to detect vertex colors.
Now it has proper checks in render code.
a single object, but was still called outside of that scope. Caused crashes
for example when editing Ipo curves of action keys.
editaction.c and editnla.c still need to be tackled...
Transparent shadow could accidentally intersect first with a face being
farther away, due to the fact larger faces can fill up multiple octree
nodes. Had to use the same exception handling as for raytracing mirror or
glass.
This fixes the active object in place when orbiting the view.
Choppy 15fps demo can be seen there: http://www.elysiun.com/~theeth/bf/around_active.html
Image Memory Grabage Collection
This adds memory handling to the image code. An image is tagged each time it is used.
During a collection cycle (frequency of cycles is user defined), if an image is older
than a user defined limit, its buffer gets deallocated. This also applies to gl memory buffers.
Images that are loading in GL memory needs to go through two time outs before being fully deallocated: the first time out deallocated the gl memorry, the second the buffer in ram.
Notes:
Image buffer loaded from python gets tagged as permanent upon load. That tag is removed when python stops using the image.
I might have missed some tagging spots, especially in the rendering pipeline. Someone with more knowledge about this code should check to be careful.
Tagging is done on every access, for rendering, this will probably be a performance hit. A scheme should be developped to only tag when the rendering is completed.
Collecting is called in draw_object, most likely not the best place to do it.
Safe from undo, since using undo deallocates memory anyway (like when loading a blend file with one currently opened)
Userpref DNA changes:
I've changed a couple of flagging variables from short to int. Some because they needed more space, others to keep SDNA happy.
Info window changes:
I've grouped a couple of buttons in aligned blocks and changed the color of mutually exclusive options to make them clearer.
Matt didn't do any changes on that in tuhopuu, so hopefully I'm not stepping on anyone's feet with this.
Also changed double constants into floats with f in a couple of places (mostly space.c) to make compiler happier.
