blender-2.44-linux-glibc2.5-x86_64.tar.bz2
is now:
blender-2.44-linux-glibc2.5-x86_64-py2.5.tar.bz2
I know know the same as scons builds but its cleaner with the Makefiles
this way. I could make it like the scons versions but will be more hackish
Kent
its not hard coded if it trys to do a static build or not. It
uses the same vars that decide if your building a static blender to
determine if it should make a static package.
I also found a typo on OSX for make release and thats fixed now
Kent
Everyone else was using gzip. On the latest downloads many of them
are using bzip2, (I think everyone using scons)
So I decided to update make release so that everyone is using
gzip2. I don't mean to step on anyones toes, I know at least some of
the platform maintainers do not use make though so feel free to change
it back and or to something different for your platform.
While I was at it I also changed default path of OPENEXR to /usr on linux.
Was suggested on mailing list by Matt.
(I'm pretty sure the linux maintainer is using scons)
Kent
- the .so files are copied to the installation dir plugin/ directory now
(other platforms copy it to the .blender dir, which doesn't exist there
for OSX)
- plugin C files got #defines for return values, was old patch I applied,
but was never committed
Somebody with good knowledge of the current state of icons should
probably check blenderbuttons for correctness. Also, splash.blend
was corrupt, so I restored the old version, but it says 2.40...
It seemed trivial enough, so I updated all systems (makefiles, xcode, scons, scons win installer), please complain if something went wrong. Mostly it was just removing release/bpydata references, since the release/scripts dir is already worked on recursevely, handling dirs inside it.
For the scons nsi file writer script I had to write code for each new dir, but it can be recoded recursively, too (in fact joining all release stuff in a single dir tree with nothing else would be a good idea, making installation code simpler). Since it's just python and I have a little more time now, I can help scons managers if they still need.
Thanks Campbell Barton for reporting.
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!
instead. Also moved the creation of $(CONFDIR) up so that it
gets created before dumping files into it. There is still one
extra reference to .blender for osX but I wasn't sure what was going on
so I left it. It really should be "fixed" though.
Kent
* the compiled plugins get moved to .blender/plugins in the
release tarball (the include and C files remain where they
were). Please test.
* if they exist, the directories release/scripts and release/bpydata
get copied to .blender/scripts and .blender/bpydata respectively.
The third is for actually loading the plugins in blender.
For some reason its not identifying the plugins correctly,
but it compiles and runs so I'm including it hoping someone else
might see where I've messed things up...
I have a simple example at http://www.cs.umn.edu/~mein/test.tgz that
works, if anyone is interested in playing with it.
Kent
you can also do a make release inside of blender/source
Should this be moved to the rootdir or do we want it sort of hidden?
Also I only tested it on linux so feel free to give it a shot it probably will
need some tweaks for other platforms but hey :)
I set VERSION to 2.26a wasn't sure what we want it to be.
Kent
junkies will be happy to find the datatoc.c program in the
datafiles directory).
Some quick notes:
* 'datafiles' has the version 2.21 splash.jpg and blenderbuttons (e.g., so
no NLA icon). Someone should at least get the 2.25 blenderbuttons from
somewhere and commit them.
* 'text' has obsolete content/license
* I did not include the python scripts as they have copyright
Jan Walter and no license specified.
* I changed to unix line terminators everywhere with the exeption of the
'windows' directory.
Chris
