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.
More bump issues... Env made very nice examples, but all of it quite nasty
to solve.
Three improvements I found nevertheless:
- bug in mipmap code for bump gave errors in one derivate, causing aliasing
- when Image texture option "Clip" was used, the imagetexture function
returned wrong value, causing the caller to create own normal based on
color (zero!).
- Mipmapped bump now also interpolates the samples (never did this...)
Uninitialized 'alpha' flag in Image texture could cause render errors.
Didn't show in OSX though... (stupid system here inits stack to zero).
But, Ken Hughes found this, so all credits are for him!
Another ancient bug in unified render... the lamphalo wasn't filled in
correctly over sky, especially when the background had halos (or stars).
Only shows when using filters other than box though.
wire frame became very limited... the information of faces (vertex colors
and UV reside there) got lost.
Solved it nicely with creating a large index table, and use bsearch() to
get quickly the matching information.
Then I noticed the render code needed fixes too for wire, no proper UV's
were calculated over the wire edge.
Unified render didn't treat the alpha for raytraced transparent correct...
unified is based on layering with alpha, so it cannot support alpha in
raytraced transparent correctly.
I'm going to kill unified one day... its giving me headaches. :)
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.
