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!
Particles added to mesh being deformed with Armature crashes.
Bug introduced with 2.33, particle collisions... leon added some fancy
updates for actions and armature displists there, which are highly
disputable. I left it in, because I didn't see it was actually new.
Note: particles added while updating mesh with armatures is not supported,
it will shoot particles from original location.
What does work, is static particles.
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.
Static-animated particles didn't recalculate on render
when used for duplicators (did work for halos). Allows material/texture ipo
for animated motion.
Some implicit cast warnings and more importantly, changed the parameter type to int for functions passing the particles random number seed around. No need to use floats there, it's an int anyway.
Effect.c is now warning free (on MSVC 6.0 at least)
Different draw mode for Vortex effector ( http://www.clubinfo.bdeb.qc.ca/~theeth/Temp/vortex.jpg )
Use row buts for effector type (only one effector at a time per object).
Forcefield circle transparency in 3D view is controlled by falloff value (for coolness factor).
Please note that those only draws in the 3D view for Empty objects. I've tested with all other object types through a global call, but lamps (and only those) give problems. Since we go in release status soon, I prefer commiting something that works all the time.
transformation (from vertex -> world space), used defines for vecadd and
vecsub, and intersects quads more efficient.
Result is about 2 times faster.
- Added draw mode for empty used as forcefield
- added defines VECADD and VECSUB
Cleaned the GUI for effectors: Widen the panel and the buttons. Made the button text more conformed.
Added vortex field for particles. Particles swirl around z-axis of the object. Little hackish, could be made better.
Edges in Mesh
- adds automatic when you use creases. For other situations; call the
void make_edges(Mesh *me) in mesh.c. Of course, once in editmode the
edges are automatically recreated.
- in F9 buttons you can add/remove edges too
- both for Mesh and DisplistMesh, so it speeds up drawing quite some in
wireframe
- render for edges can't work... edges have no material nor tface nor col..
so here still the faces are rendered in wire
Creases in Subsurf
- based on the code by Chris McFarlen
- main changes is that now edges are used, saving quite some data in file
- use SHIFT+E in editmode to set edges-sharpness. values go from 0-1
- in F9 buttons you can set draw-crease mode. It draws now blended from
wire color to edge-select color (as provided in Theme)
Known issue: setting sharpness on 1 cube (subdiv 2) gives weird results
with some values... Chris, can you check?
Further; code cleanups, changing 0 in NULL when needed, no warnings, etc etc
for Armature. Note: only works for subsurfed Mesh now!
Change in drawobject.c: Halo option on subsurf Mesh now draws points.
but using the original vertices...
- textures: added support for new mixers (div, diff etc) to work on the
other map-to channels too, like ref or spec
Also it works on lamp and world textures
- brought back uncommented line of code that was removed by leon, to have
particle motion based on textures
- recoded the glPylonOffset hack to be nice function, this for future
testing.
New is that objects can have a force field, and Meshes can even deflect
(collide) particles. This is in a new sub-menu in Object buttons F7
The full instructions where on the web, Leon mailed it me and I will put
it in CMS tomorrow. For those who like to play with it now, here are demo
files:
http://download.blender.org/demo/test/
Quite some changes where in the integration though... so previous created
particle deflectors will not work. Changes to mention now are:
- gravity is renamed to 'force field'
- force field and deflector options are in Object now, not in Mesh
- the options also have its own struct, doesnt add to Object by default
- force fields are possible for all object types, but only work on center.
So empty objects are typical for it.
Work to do:
- add draw method in 3d win to denote forcefield objects
- check on the UI (panel with different size?)
- add 'recalc' button in deflector panel
(MVert,MFace,etc) off into DNA_meshdata_types.h, to isolate areas
of source that actually edit mesh *data* vs. areas that just edit
mesh object information.
by the seed variable. Requested by S68.
Basically they move slightly when you change the seed. Might be
a good idea to split this up so there are two seed options in a
particle effect, however there are already quite a bit of them so I opted
for this.
Kent
Main target was to make the inner rendering loop using no globals anymore.
This is essential for proper usage while raytracing, it caused a lot of
hacks in the raycode as well, which even didn't work correctly for all
situations (textures especially).
Done this by creating a new local struct RenderInput, which replaces usage
of the global struct Render R. The latter now only is used to denote
image size, viewmatrix, and the like.
Making the inner render loops using no globals caused 1000s of vars to
be changed... but the result definitely is much nicer code, which enables
making 'real' shaders in a next stage.
It also enabled me to remove the hacks from ray.c
Then i went to the task of removing redundant code. Especially the calculus
of texture coords took place (identical) in three locations.
Most obvious is the change in the unified render part, which is much less
code now; it uses the same rendering routines as normal render now.
(Note; not for halos yet!)
I also removed 6 files called 'shadowbuffer' something. This was experimen-
tal stuff from NaN days. And again saved a lot of double used code.
Finally I went over the blenkernel and blender/src calls to render stuff.
Here the same local data is used now, resulting in less dependency.
I also moved render-texture to the render module, this was still in Kernel.
(new file: texture.c)
So! After this commit I will check on the autofiles, to try to fix that.
MSVC people have to do it themselves.
This commit will need quite some testing help, but I'm around!
