parameters the material preset menu won't be as useful. Both glass presets will look the same
because there is no 'filter' parameter in the old yafray for instance.
So using the new Blender version with an old yafray version should work a bit better,
though the other way around, using the new yafray with an old blender version, will generally
not work as well.
I added a few extra things. In 'yafray' panel re-arranged some buttons, and added a new
button 'Clamp RGB'. This button will be enabled by default and helps to improve AA on
high contrast edges in the image. When using bokeh however, it is best to switch this off,
otherwise lens shaped highlights will be quite a bit less visible.
Changed the 'extinction' parameter name to the probably more correct term 'absorption',
though mathematically it works out the same. Also changed the behaviour of this color,
it no longer specifies a color that will be removed as I wrote in the previous commit,
but instead the actual color at one (blender) unit of distance. The 'Ds' (distance scale)
button below the color sliders controls the scaling of this unit distance.
What this means is that if you take the standard blender cube, which covers two units of
distance by default, setting the distance scale button to 2.0 will make sure that the color
you specified is exactly that color at that distance (provided the base color itself is white
of course, or 'filter' is 0, otherwise it will be filtered by the base color too).
Beyond this distance the color will get darker.
The glow option for point/soft/sphere lights has a new parameter 'GloOfs', or glow offset.
Setting this to a higher value then 0 will soften the central peak of the glow.
Another unreported bug fix: For xml export, when yafray failed to render the xml file
for some unknown reason, or because of other problems, the export code would still load
the previously rendered image, this causes problems however if the image resolution is
not the same as the current Blender buffer, and so could cause memory corruption or crashes.
This is now taken into account.
World image backgrounds now use the blender mapping settings as well, but only the
'AngMap', 'Sphere' and 'Tube' settings. But in yafray those last two, unlike Blender, cover
the whole view, not just the upper half, so is not really fully compatible with yafray.
So now you have to set one of these buttons too when loading a hdr lightprobe image.
btw, something I forgot to mention in previous commits is that the exposure control using
the texture brightness slider is no longer restricted to integer values. It is now a
floating point value, so you're not restricted to the 0 1 and 2 slider positions anymore,
anything in between will work too.
And finally, display updating is now more like Blender, using the mouse cursor as frame
counter for animation, etc.
of course...)
Not quite complete, but due to lack of time as good as it will get for now.
From the previous commit, forgot to report that basic fog is supported as well. Though because I had not much time to complete the code, it is sort of unfinished, and you will have
to tweak parameters specifically for yafray again. It uses only the world horizon color, and
only uses the Blender mist distance setting.
Textures now support checker clip mode.
Fixed possibly all 'duplilist non-empty' errors, though it could hide the real cause of the
error.
AA is no longer enabled automatically for certain GI quality settings, I thought it best to
leave it to the user to decide.
SkyDome GI mode now supports cache as well. There is a new option in the GI quality menu 'Use
Blender AO settings', which will as it says use the most important AO settings for the
skydome parameters. The only AO parameters used are 'Samples', 'Dist' and the random sampling
switch, which unlike in Blender you might want to use more often, since the QMC sampling used
in yafray can result in visible patterns or a dithering type look. 'Random' is not completely
random in yafray however, it is actually jittered (stratified) sampling.
Using an occlusion cache, doesn't necessarily mean that you will always get much shorter
render times. As with 'full' GI and cache, one problem is bumpmaps, when using bump (or
normal) maps, the sampling will be much more dense, using lots more rendertime.
As a temporary fix there is a button 'NoBump', but this also has the side effect that in
areas of total indirect light (or when used with SkyDome cache) no bumpmapping will be
visible. It is therefor best used with some direct light as well.
For SkyDome with cache, and strong bumpmapping it might actually not make much difference,
since for low distance values you can usually get away with low sample values as well.
The entire material panel is now replaced by another panel to show only the parameters
important to yafray and add some new ones as well.
Since lots of users (especially yafray beginners) have had problems getting certain material
aspects right, there is now a material preset menu available to hopefully solve some of the
most common "How do I do this? It doesn't work!" questions seen in various forums.
Choosing an option from this menu will set the required parameters to default
values for yafray, and you can work your way from there to tweak it something you want.
Most buttons are copies of the same Blender parameters, with some variations. Just like
Blender 'Ray Mirror' enables reflection, 'Ray Transp' enables refraction. You can use
'ZTransp' for materials that have texture maps with alpha channels.
Again, same as Blender 'rayMir' sets the amount of reflection. Next button 'frsOfs' however
controls fresnel offset, meaning that when this is set to 1, you will get no fresnel effect
and when set to 5, reflection is totally determined by fresnel, which is important for
realistic glass/metals/etc.
IOR is self-explanatory (...), same as Blender.
When you have 'Ray Transp' enabled, the blender 'filter' button will appear next to the IOR
button. This has the same effect as in Blender.
Below that there are some new parameters, 'Ext.Color' sets the extinction color for
transparent materials. Usually, in real transparent materials, light loses some of it's
energy the further it has to travel through the object. This effect can be simulated with
this parameter. Thing to look out for is that it specifies the color which will be
REMOVED after traveling through the object. What this means is that say you have a clear
white glass sphere, and set the extinction color to a strong blue, the result will be a
very yellow object when rendered.
Next to the color sliders, there is another set of three parameters, with which you can
enable color dispersion for transparent objects. 'Pwr' sets the amount of dispersion,
the higher, the more dispersion (the more colorful the result).
(For real world materials, this number can be found or derived from data in various glass catalogues)
The 'Samples' button below that sets the number of samples used, minimum values are around
7-10, and for very strong dispersion you might need a lot more.
As usual, this also means an increase in render time of course, but to simulate
realistic materials, you shouldn't really need more than 25 samples.
In addition to that, when using low sample numbers, but to still get a good spread of colors,
you can enable the jitter button, but this will also add noise.
Point/soft(point with shadowbuffer) or sphere lights (light with radius), have a new option
to add a simple glow effect, so that lights can be made visible.
NOTE: just like spotlight halo's, glow is not visible against the background, there must be
another object behind it. Simplest solution is to use a large black shadeless plane behind
your scene.
The glow intensity can be set with the 'GlowInt' parameter (use very low values around 0.01
even lower), and you can choose from two different types with the 'GlowType' button (which
don't look much different, but type 1 is probably better, type 0 faster).
And that's it, with apologies for the still missing features and
full support in general, but this will have to do for now.
This combo didnt render OK:
1 Armature has Empties parented to Bones
2 Curve has these Empties as Hooks
3 Mesh is deformed with this Curve
Could be solved with calling makeDispList() earlier on, and it seems like
the depgraph already does a great job here. :)
Fixed an as of yet unreported bug, linked data objects which have materials
linked to object instead of data have to be exported as normal, they cannot
be instanciated, otherwise they will all share the same material.
parented linked data lamps made the export crash.
fix for two bugs reported by Diego Pino, an endian issue with vertex colors,
and the plugin code didn't export multiple colorbands correctly.
Updated the ortho camera export code for the new Blender ortho camera model.
- Made Blender.event var (previously only used by script links) hold ascii value -- where it applies -- of current event during events callback registered with Draw.Register(gui, events, button_events). Useful for gui scripts like Campbell's Python console. No problem using this var to hold the value, since in gui scripts it was not used (always None).
- Updated Window and Window.Theme with new theme vars and the Time space.
- Script links:
-- Added "Render" event for script links (runs twice, second time as "PostEvent", for clean-up actions). Now FrameChanged links don't run when a single pic is rendered.
-- Added "Enable Script Links" button in the script buttons tab. Now this bit gets saved in .blends along with the rest of G.f, so users can define per .blend if they are on or off by default. "blender -y" also disables all slinks as happened before with OnLoad ones only.
-- Other small changes in the script buttons tab:
When a link is added (button "new"), it becomes the active one for the window, no need to press a button to reach it.
Also, a pupmenu showing all available texts is shown when "new" is pressed, so users can choose a text w/o having to type. Cancel the popup to leave the string button empty (link exists, but has no script assigned). A pulldown would be better UI-wise, but it's kinda weird to show both scripts and normal texts (Blender doesn't differentiate them) in a script links pulldown. With a popup we can show only texts ending in ".py" (not done in this commit, need opinions) and if the script has no or another extension, case of many in old and current .blend's, there's still the string box for writing its name.
-- Implemented Ton's space handler script links:
Right now only for the 3d View, but it's trivial to add for others. There are two types: EVENT, to receive 3d View events from a chosen window and DRAW, to draw on the window. Ton's idea was to give scripts a controlled way to integrate better within Blender.
Here's how it works:
- scripts must have a proper header, like:
# SPACEHANDLER.VIEW3D.EVENT
and then they are shown in 3d View's View menu, "Space Handler Scripts" submenu. Check (mark, click on it) a script to make it active.
EVENT handlers should consult the Blender.event var to get the current event, which can be compared with values from the Draw module:
import Blender
from Blender import Draw
evt = Blender.event
if evt == Draw.AKEY:
print "a"
elif evt == Draw.LEFTMOUSE:
print "left mouse button"
else:
return # ignore, pass event back to Blender
Blender.event = None # tell Blender not to process itself the event
DRAW handlers are free to draw to their owner 3D View. OpenGL attributes and modelview and projection matrices are pushed before running the handler and poped when it finishes.
To communicate between EVENT and DRAW handler scripts we have the Blender.Registry module, as always.
Still need to code some nice example, which should also serve to test properly space handlers. Simple tests went fine.
- doc updates about the additions.
=======
Note: the UI part of the space handlers and script links is of course open for changes, I just tried to make it understandable. Probably we won't use the scriptlinks icon for "None Available" (check 3d View -> View -> Space Handler Scripts), though it hints at what space handlers are. The tooltips may not be accepted either, since other menus don't use them. Opinions welcomed.
Works as follows;
- press the 'show bake settings' button (no space left... :)
- define start/end frame for bake, and an interval step.
The baked result interpolates nicely (Bspline, 4 keys) so in general a
step size of 2 or 3 still gives OK results.
- Press "BAKE". This will do a full animation + playback. Press ESC if it
you don't want it.
Once Baked, the BAKE button becomes a FREE BAKE. As reminder the softbody
buttons get blocked with error() menu.
This saves OK in a file. Renders any frame, including fields and moblur.
You can also set a "Timeoffs" for the softbody. And yes, this should be
in the NLA once... :)
NOTE! With this commit, files saved with the old (first commit) version by
Jens Ole won't read the settings back... he stored all sofbody variables in
Object, which was moved to a new struct when I did my first commit on SB
(over a month ago)
Also note that I moved particle deflecting & softbody to a new include.
(Looks like big commit, but is mostly just change of API call!)
Particle emittors now can be parented to an armature Bone, and give the
correct path for each particle. Note that this doesn't work for deform!
And, for each particle the entire armature is evaluated, all actions and
NLA strips.
It used to work a little while BTW, but the code just called ALL armatures
and made ALL deforms again. Was quite slow... thats why the API call
change: do_all_actions() now accepts Object * to only do that one. With
a NULL it now does all still. Will disapppear in recode of course...
before it would follow subsurf code path by creating fake displistmesh,
etc... kinda fun for testing but just annoying now.
- change to creasing behavior, to make sure that with full creasing effect
is just simple subdivision.
- removed DL_MESH displist type!!!! Now store a DerivedMesh directly.
- May still be some issues left having to do with releasing this
at the right time (old code just splashed free_displist all
over the place).
- cancelled previous commit to add RE_findTFAce, instead just added
a MemArena to render struct... free'd at end of render, can be used
to store other data as well
- switch rendering to using DerivedMesh API... this is slightly more
inefficient now because it is doing some unnecessary copying. Can
be fixed by defining a DerivedMesh function to convert the object
into a render object (on todo list)
Mesh object with hooks, which was used as duplivertor, didn't render the
duplicated objects on correct locations.
It did show OK in 3d window though, was due to not synced drawing and
render convertor code.
The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/
faces/halos were freed in a way that requires the last element of array to
be NULL.
This wasn't coded however, causing memory errors in exceptional cases;
like when amount of faces/vertices is exact between 261888 and 262144. :)
Found (old) issue in render... the "VlakRen" (render face) has an Object
pointer which can point to a duplicated one (dupliframes/dupliverts option),
which is freed before actual render starts... this nicely crashes in Windows.
I now store the original Object pointer, which can lead to texture
orientation errors in some situations (like normal-bump stuff).
Real solution is recode of duplicator system!
Much wanted feature, to have paths with children having fixed distance
offsets from each other, for example to animate a train with wagons.
Solved it with Path option (Editing buttons curve) "PathDist Offs" which
interprets time-offsets of children as blender-unit offsets. The entire
animation system still works, but offsets are calculated based on distance,
even with a CurvePath without motion (speed curve horizontal).
http://download.blender.org/demo/test/pathdist.blend
Thanks to Bassam for kicking my ass!
#2187: Append to active layer now uses the real active layer
#2191: Stars didnt show up correctly in envmap render
#2194: Startfame > Endframe in anim render crashed (now it gives error)
It used to be a simple hack, scaling lens with 100, and moving the camera
to the back with an equivalent amount.
Because of the hack, making it 100% compatible with older files I could not
achieve (yet?). To help reminding users, I've added a print when reading
old files with Ortho cameras.
Full description of how it works can be found here;
http://www.blender3d.com/cms/Render_changes.515.0.html
- removed ugly pointerhack from OSA render (negative indices denoted
pointers). this should solve memory errors when using >1.5 gig mem
- cleaned up usage of zbuffer values. These are signed in Blender, and
treated as unsigned all over, giving confusing code
- fixed incorrect gamma-adding for halos (caused in after xmas commit)
And bugfix #2101; wire render didn't give correct rendering for mist.
This caused by fact wires are 2D pixel lines, and not correctly filled
in faces. Retrieving the 3d coordinate while render cannot use a face-
equation then. Solved by retrieving 3D coordinate based on zbuffer value.
Still todo here: calculating correct texture coordinates for wire-edges
that are no faces.
Render:
- New; support for dual CPU render (SDL thread)
Currently only works with alternating scanlines, but gives excellent
performance. For both normal render as unified implemented.
Note the "mutex" locks on z-transp buffer render and imbuf loads.
- This has been made possible by major cleanups in render code, especially
getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct
OSA or using Materials or Texture data to write to.
- Made normal render fully 4x32 floats too, and removed all old optimizes
with chars or shorts.
- Made normal render and unified render use same code for sky and halo
render, giving equal (and better) results for halo render. Old render
now also uses PostProcess options (brightness, mul, gamma)
- Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer
after render. Using PostProcess menu you will note an immediate re-
display of image too (32 bits RGBA)
- Added "Hue" and "Saturation" sliders to PostProcess options
- Render module is still not having a "nice" API, but amount of dependencies
went down a lot. Next todo: remove abusive "previewrender" code.
The last main global in Render (struct Render) now can be re-used for fully
controlling a render, to allow multiple "instances" of render to open.
- Renderwindow now displays a smal bar on top with the stats, and keeps the
stats after render too. Including "spare" page support.
Not only easier visible that way, but also to remove the awkward code that
was drawing stats in the Info header (extreme slow on some ATIs too)
- Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping
defines.
- I might have forgotten stuff... and will write a nice doc on the architecture!
Slightly altered rules for calculating vertexnormals. By only averaging
face normals from faces actually set 'smooth', the result looks much more
nice (for example on a cylinder with caps solid). Vertex normals not being
used by smooth faces are set to the face normal direction.
Shows both in editor as rendering.
Five fixes in this commit...
- the normals for nurbs surfaces still were calculated pointing wrong in some occasions
- recoded ray-transp rendering to accept normals pointing any direction; it just counts how many times it passes a "glass" layer, and flips normals appropriate then. This means rendering will go fine on models without manually setting the normals. You can also move a camera inside a 'glass' object.
- rendering of the inside part of glass now uses correct normal too... specularity happen on a solid glass inside now.
- And an inside reflected mirror ray will keep bouncing inside glass
Related to rendering localview: old convention to render localview, but with the lamps in the normal layers, has been restored.
Please note; render happens based on active window. You *only* get a localview or 'unlocked layer' render when that 3d window is active = mouse in window.
channels to link texture to.
The amount of code changes seems large, but is mostly getting rind of
hardcoded values (6 and 8) for channels, replacing it with MAX_MTEX.
Further did some fixes;
- Ipo for Lamp showed too many mapping channels
- Texture MapTo buttons for lamp missed the slider to blend texture color
- Lamp texture mapping "View" only worked for Spot, now it uses lamp-
view vector for all types. (Nice for projections!)
thanks for that!
- static particles that are being deformed (curve/lattice/armature) now
display correct in 3d window. Only updates when particle system updates
normally though
- static particles without "animate" set didn't deform even
- static particles used as duplicators had errors with extreme low "life"
value for particles. Also, still cases could happen with unrotated duplis
at the end of a static particle line (with Vect option)
- Added tooltip for "Step" option in particles
In unified render, halos can give black/colored overflows. Found it this
happens with halos that are behind the camera clipping range. Halo clip
just had some weird code for panorama corrections...
In the provided .blend of report found 3 more glitches;
- after render particle system with Material Ipo, values for material were
not restored correctly
- Meshes with particles didn't draw axis (draw extra) on correct location
- Same as above, axis didn't draw in selected color.
- Bug #1890. While render subsurf in editmode, orco coordinates were
incorrect (subsurf vertices in editmode have different ordering)
Bug was oldie.
- IRC reported by Stefano; oops (not outliner) didnt show lamp textures
nor material ipos correctly.
Found error in oops curved lines too (the ones starting at right side)
View3d windows have 'unlock' option and 'localview', which was also
supported on render (F12 with mouse in window) to render only what is
visible there.
This didn't work very nice, with even code in render module to read from
interface variable. Removed that from render, and coded the exception
where it belongs, in renderwin.c
Static-animated particles didn't recalculate on render
when used for duplicators (did work for halos). Allows material/texture ipo
for animated motion.
- Deformed mesh didnt give correct 'orco' anymore on render
- Mesh editmode, "Separate loose parts", crash on empty mesh (no verts)
- Global undo; buttons sending redraw events gave extra undo push called
"Make single user or local". That latter was wrong event handling for
REDRAW event, harmless, until now :)
First one is a real showstopper... bah!
- Nurbs objects didnt render ray-transp. Was caused by 1) wrong normal calc
and 2) quads with vertices on same locations. Solved it with nice code that
checks illegal quads and turns them into triangles
- Made 'physics engine' variable SUMO default
- Typo in toolbox fix; cyclic isn't F but C
hopefully prevents weird results in grabber... error was that the
editNurb was not used for triangulating.
Also; added drawing the wire as extra in solid display editing curves...
that for unfilled curves as well.
When rendering from localview, the lamp layers were not evaluated properly
for "Layer" option in Lamps. This because localview uses layers 24-31. :)
Fix is simple; just not use localview layers for lamp while render.
Blender hemilight shadow flag now ignored (reported by varuag).
Texture axes were not exported for procedural textures.
Duplicate armatures were not handled correctly (reported by richie).
Triangle uv-coord splitting (reported by anael, richie & Alvaro).
Additions:
Material 'TexFace' mode now works too, as in Blender it functions as an extra
first texture channel, replacing the base color.
The new noise functions for procedural textures are now supported in yafray,
but is not quite completed yet, still undergoing changes.
(needs yafray from cvs).
The 'power' button has been renamed to 'EmitPwr', since it controls background,
arealight (including lamp with radius) & material emit power.
This button can now be used with the 'SkyDome' method as well to control
background lighting.
To control indirect lighting power, a button called 'GI pwr' has been added,
only use this when really necessary, first try modifying 'EmitPwr' instead.
Removed:
The 'gradient' button. This includes the python code to set
this parameter as well.
that a displist has to be recalculated, you only have to free it.
In the init_render_mesh() not all situations were checked OK.
Thanks Basse for finding it!
