Removed FTYPE from render output panel - was some old format that did index colors, and wasn't even used anywhere.
Added 2 options to the render output panel that can be used for a really basic local renderfarm (even artists can use it!),
"NoOverwrite" and "Touch"
When both are enabled, rendering 1 scene between many pc's on a fast network will populate the directory with frames.
Also useful to delete frames that have errors and re-render (without manually re-rendering each frame)
----------
Added RenderData.activeLayer attribute, lets user access the active
rendering layer. Also corrected description of RenderData.freeImages
attribute.
Note: doesn't seem like there is any support in the python API for accessing
the renderlayers settings....
I was careful in selectively rolling back revisions, but if you've committed changes unrelated to BPY mixed with BPY changes, I might have reverted those too, so please double check.
----------
Document Peter's fps_base attribute for scene rendering objects; also remove
framesPerSecBase() method (preference is to add only attributes, and he did
add fps_base attribute).
This adds fractional FPS support to blender and should finally
make NTSC work correctly.
NTSC has an FPS of 30.0/1.001 which is approximately 29.97 FPS.
Therefore, it is not enough to simply make frs_sec a float, since
you can't represent this accurately enough.
I added a seperate variable frs_sec_base and FPS is now
frs_sec / frs_sec_base.
I changed all the places, where frs_sec was used to my best knowledge.
For convenience sake, I added several macros, that should make life
easier in the future:
FRA2TIME(a) : convert frame number to a double precision time in seconds
TIME2FRA(a) : the same in the opposite direction
FPS : return current FPS as a double precision number
(last resort)
This closes bug #6715
Standard framerates not supported / breaks sync -- 23.967 29.967 etc.
https://projects.blender.org/tracker/?func=detail&aid=6715&group_id=9&atid=125
Please give this heavy testing with NTSC files, quicktime in/export
and the python interface.
Errors are most probably only spotted on longer timelines, so that is
also important.
The patch was tested by Troy Sobotka and me, so it most probably should
work out of the box, but wider testing is important, since errors are
very subtle.
Enjoy!
Before this, calling scene.currentFrame(val) would not work to update object displists where Blender.Set('curframe', val) did work.
Also used less python BuildValue calls.
commited temporary fix: executable name is quoted for all platforms except Windows now,
nicely wrapped in #ifdefs. Will be doing nice wrapper function BLI_system for system calls in blenlib
after release.
Please test on all platforms!
(Empty space will get OSA options, that I add tomorrow or so)
- Removed a lot of old unused variables in renderdata. Also meant I had
to remove this from python API... please check if this gives valid
scripts?
- Cleaned up bad formatted code for FFMPG buttons (spaces instead of tabs)
Please read:
http://www.blender3d.org/cms/Imaging.834.0.html
Or in short:
- adding MultiLayer Image support
- recoded entire Image API
- better integration of movie/sequence Images
Was a whole load of work... went down for a week to do this. So, will need
a lot of testing! Will be in irc all evening.
- It saves a file with indicated type on each change, with number
appended denoting the current frame (like ANIM saving).
- Output filename button supports relative paths ("//")
- Shows optional preview image too
- For now, added a print on each file save as feedback
To make this option work nicely, changed the BKE_makepicstring() function
to have less globals inside, so it is more generic. Todo: allow amount of
digits in filenames to be set (to support files like tmp_123456.jpg)
Next to the "DispWindow" there are now two new choices:
- Display render output to Image Editor
- Display render output to Screen-sized Image Editor
Both options won't open a 2nd window anymore, which makes work quite more
smooth even, especially because 'focus' isn't lost. Further it fits in the
'single window UI' paradigm of Blender. Should have been done 10 years ago!
Lastly it might bypass issues with X11... having 2 windows with opengl
context is not always stable in Linux.
This option uses an identical trick as for the Compositor viewer, using an
Image block with a fixed name ("Render Result").
The flow, when invoking a Render, goes as follows:
- first it checks if there's an Image Editor visible displaying the "Render
Result", if so then it uses that area-window.
(Use this option for dual-monitor setups for example, a render will always
go to the same location then)
- else it checks if there's an Image Editor open in general, it then
assigns that window the "Render Result" Image.
- else: it searches for the largest Area in the screen, and turns that into
a temporal Image Editor showing render output.
After a render, an ESC will push back the former view, if the Area type has
changed.
Same rules apply for the "Full Screen" option. Here an ESC will always go
back to the regular Screen, and restore Area type if required.
While rendering, the queue for the renderwindow isn't handled yet, so you can
not zoom (nor get full redraws), as for the regular render window.
Existing conflicts:
- in FaceSelect mode, the Image editor enforces to display the face texture
after rendering again.
- when using an Image window for compositing, you'll lose the Viewer output
on a render.
Implementation note:
While rendering updates, nothing is drawn in frontbuffer anymore. That's
good news for b0rked OpenGL drivers (and faster). However, for the few
OpenGL cards that don't do a "swap copy" but a "swap exchange" you get
issues... has to be worked on. I'm afraid we have to drop frontbuffer
drawing altogether.
Other fixes:
- Hotkeys NumPad 1, 2, 4, 8 will set zoom levels (was half coded only?)
Use SHIFT to zoom out (smaller).
- Rendering Tile updates still had draw errors on edges of tiles, in OSA
only. (Caused by commit 4 days ago)
made xparts and yparts consistent in the different places it can be set now python and the buttons are max 64 (was 512 in some python locations) and xparts is max 512 (was max 64 in some python locations), also made the minimum xparts and yparts 1 again. Ed Halley suggests that we should up the max xparts to 1024 (instead of the current 512) for 'smoother panoramas'
Second pass at sceneRender.c / Scene.Render API clean-up. Most of the remaining clean-up needs to wait for the API refactor, since the "good" attribute names are already used by methods.
[ #4228 ] Blender.Image.Load(filename) loads only on the first loading
- Image.Load() will now reload the image buffer when a image of the same name is loaded again
- small textual change in render code
- save_rendered_image_cb_real has a popup window embedded in it that prevents automation through python as a result python scripts would get a popup which is ignorned by the script
- modified so python scripts overwrite the image by default
- added documentation to Render - saveRenderedImage has an option to save the zbuffer along with the image
(off by default)
- fixed a really annoying runtime error of uninitialized data being passed to a method in pipeline.c during a render
Made the frame boost from short to int (30000 -> 300000 frames) complete
by walking through the source and finally changing all frame-variables
to ints.
This should finally fix the framecounter warp around seen in some buttons.
If you step on any further problems that may arise starting from frame
32768 please just give me a hint and I'll fix it.
(Sorry about that, didn't know enough about Blender, when I did it the first
time...)
The old implementation was added quite hackish (talking about 10 yr ago).
You also had to make a small image slice, which was extended Xparts in
size. That also required to adjust the camera angle. Very clumsy.
Now; when enabling the Panorama option, it will automatically apply the
panorama effect on the vertically aligned tiles. You can just enable or
disable the "Pano" button, to get a subtle lens effect like this:
(without pano)
http://www.blender.org/bf/rt.jpg
(with pano)
http://www.blender.org/bf/rt1.jpg
For Panorama render, the minimum slice size has been hardcoded to be 8
pixels. The XParts button goes up to 512 to allow that. In practice,
rendering 64 slices will already give very good images for a wide angle
lens of 90 degrees, the curvature of straight lines then is equal to
a circle of 256 points.
Rendering a full 360 degree panorama you do by creating an extreme wide
angle camera. The theory says camera-lens 5 should do 360 degrees, but
for some reason my tests reveil it's 5.1... there's a rounding error
somewhere, maybe related to the clipping plane start? Will look at that
later. :)
Also note that for each Xpart slice, the entire database needs to be
rotated around camera to correct for panorama, on huge scenes that might
give some overhead.
Threaded render goes fine for Panorama too, but it can only render the
vertically aligned parts in parallel. For the next panorama slice it has
to wait for all threads of the current slice to be ready.
On reading old files, I convert the settings to match as closely as
possible the new situation.
Since I cannot bump up the version #, the code detects for old panorama
by checking for the image size. If image width is smaller than height, it
assumes it's an old file (only if Panoroma option was set).
A full detailed description of this will be done later... is several days
of work. Here's a summary:
Render:
- Full cleanup of render code, removing *all* globals and bad level calls
all over blender. Render module is now not called abusive anymore
- API-fied calls to rendering
- Full recode of internal render pipeline. Is now rendering tiles by
default, prepared for much smarter 'bucket' render later.
- Each thread now can render a full part
- Renders were tested with 4 threads, goes fine, apart from some lookup
tables in softshadow and AO still
- Rendering is prepared to do multiple layers and passes
- No single 32 bits trick in render code anymore, all 100% floats now.
Writing images/movies
- moved writing images to blender kernel (bye bye 'schrijfplaatje'!)
- made a new Movie handle system, also in kernel. This will enable much
easier use of movies in Blender
PreviewRender:
- Using new render API, previewrender (in buttons) now uses regular render
code to generate images.
- new datafile 'preview.blend.c' has the preview scenes in it
- previews get rendered in exact displayed size (1 pixel = 1 pixel)
3D Preview render
- new; press Pkey in 3d window, for a panel that continuously renders
(pkey is for games, i know... but we dont do that in orange now!)
- this render works nearly identical to buttons-preview render, so it stops
rendering on any event (mouse, keyboard, etc)
- on moving/scaling the panel, the render code doesn't recreate all geometry
- same for shifting/panning view
- all other operations (now) regenerate the full render database still.
- this is WIP... but big fun, especially for simple scenes!
Compositor
- Using same node system as now in use for shaders, you can composit images
- works pretty straightforward... needs much more options/tools and integration
with rendering still
- is not threaded yet, nor is so smart to only recalculate changes... will be
done soon!
- the "Render Result" node will get all layers/passes as output sockets
- The "Output" node renders to a builtin image, which you can view in the Image
window. (yes, output nodes to render-result, and to files, is on the list!)
The Bad News
- "Unified Render" is removed. It might come back in some stage, but this
system should be built from scratch. I can't really understand this code...
I expect it is not much needed, especially with advanced layer/passes
control
- Panorama render, Field render, Motion blur, is not coded yet... (I had to
recode every single feature in render, so...!)
- Lens Flare is also not back... needs total revision, might become composit
effect though (using zbuffer for visibility)
- Part render is gone! (well, thats obvious, its default now).
- The render window is only restored with limited functionality... I am going
to check first the option to render to a Image window, so Blender can become
a true single-window application. :)
For example, the 'Spare render buffer' (jkey) doesnt work.
- Render with border, now default creates a smaller image
- No zbuffers are written yet... on the todo!
- Scons files and MSVC will need work to get compiling again
OK... thats what I can quickly recall. Now go compiling!
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
This adds Radiance HDR image file support. So now at least we can save
the 'fbuf' (4x32 bits float colors) in Blender.
It doesn't change anything for internal support in imbuf for floa colors,
so when reading .hdr files it still converts it to 32 bits RGBA.
As an extra I've added that saving images with F3 now also adds the
optional extension, when the F10 "Extensions" option is set.
One important note; I don't know the proper license for the code, it was
provided without... will await feedback from Alfredo about it. For now
I've added the standard Blender GPL header.
- should allow users to render a filename.extension to the render path
Example:
import Blender
s = Blender.Scene.GetCurrent()
r = s.getRenderingContext()
r.setRenderPath('C:\\')
r.render()
r.saveRenderedImage('myRender.jpg')
Blender.Scene.Render.CloseRenderWindow()
- corrections to constants
- parameter type checking
- correct use of METH_VARARGS vs METH_NOARGS
- return objects instead of strings in Scene.getChildren() as per doc.
- correct logical operators
Thanks, Ken!
- Mostly this cleans up the #includes and header files in the python project.
- Warning fixes are mostly casting issues and misc fixes. General warning clean up.
- #include Python.h MUST come as the first include to avoid the POSIX redefine warning in the unix makefiles
- fno-strict-aliasing flag added to makefile to fix a unavoidable type punning warning in types.c
