allowing to use it for planar mirrors. Enable it with the new "Plane"
option in the Environment Map Panel.
Current default is to render the cube side that points to the positive
Z axis direction. To make it work, it uses the same image for all
other cube sides, so it will 'wrap around'.
Also made maximum resolution for environment map to be 4096x4096 now.
- Bug fix: the upper tile in a collumn for Panorama render didn't put the
mainthread to sleep properly. Now panorama renders 25% faster if you had
set Y-Parts to 4.
- Enabling Compositing in Scene for first time now adds a "Composite" node
too, so render output gets applied.
- An attempt to render with "Do Composite" without "Composite" node will
throw an error and stops rendering. In background mode it will just not
render at all, and print errors.
- Errors that prevent rendering now give a popup menu again.
- Having MBlur or Fields option on will now normally render, but with an
error print in console (not done yet...)
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).
the ones that get changed within threads, to communicate with the main
thread.
(Part of the long quest to get threaded render safe, especially in Linux)
passes in single file. Code is currently disabled, commit is mainly to
have a nicer method of excluding OpenEXR dependency from render module.
This should compile with disabled WITH_OPENEXR too.
Reason why EXR is great to include by default in Blender is its feature
to store unlimited layers and channels, and write this tile based. I
need the feature for saving memory; while rendering tiles, all full-size
buffers for all layers and passes are kept in memory now, which can go
into 100s of MB easily.
The code I commit now doesn't allocate these buffers while rendering, but
saves the tiles to disk. In the end is it read back. Overhead for large
renders (like 300 meg buffers) is 10-15 seconds, not bad.
Two more interesting aspects:
- Blender can save such multi-layer files in the temp directory, storing
it with .blend file name and scene name. That way, on each restart of Blender,
or on switching scenes, these buffers can be read. So you always see what was
rendered last. Also great for compositing work.
- This can also become an output image type for rendering. There's plenty of
cases where you want specific layers or passes saved to disk for later use.
Anyhoo, finishing it is another days of work, and I got more urgent stuff
now!
- Button option "Single" in render-layer panel will enable to only render
the currently indicated render-layer. It will also skip compositing.
- Brought back the 'Local View' render. This will only render the visible
objects, but with lights from the original view-layers.
To make the option useful, it also temporal enables 'Single', which has
the a disadvantage that you need to set the correct render-layer.
It is a bit a tricky option though... since its quite invisble and
confusing for people who don't know the feature. This might become either
a button in 3d header, or use a popup requester to confirm, or... will
need to think over!
At least; both options display in render window a text to denote the option.
large scenes... this because it has to make 3 entire databases to find
the vertex-speed to previous and next frame. Even though most of the
prev/next database was freed, the parts I kept were spread all over
memory.
This commit copies from the prev/next database only the two screen aligned
speed vectors and stores that in temporal per-object structs. Even whilst
it takes more memory, it then can free the entire database, making space
for the next database to be built.
Tests reveiled it saves quite some... well, if you want to believe the
'virtual memory' total unix gives... :)
sampling have been activated for UI. Check the pictures here:
http://www.blender.org/bf/filters/index2.html
I also did do tests with anti-aliased shadowbuffers:
http://www.blender.org/bf/filters/index3.html
But this needs more thinking over still...
I noticed still several cases where the Imbuf library was called within a
thread... and that whilst the Imbuf itself isn't threadsafe. Also the
thread lock I added in rendering for loading images actually didn't
work, because then it was still possible both threads were accessing the
MEM_malloc function at same time.
This commit nearly fully replaces ImBuf calls in compositor (giving another
nice speedup btw, the way preview images in Nodes were calculated used
clumsy imbuf scaling code).
I've also centralized the 'mutex' locking for threading, which now only
resides in BLI_threads.h. This is used to secure the last ImBuf calls
I cannot replace, which is loading images and creating mipmaps.
Really hope we get something more stable now!
as triangles, with a tag bit to denote which triangle was which part of
the quad. That was hardcoded bit 0x800000, which allows a maximum of
about 8 million quads...
I've made this a nice #define, set to be 16 times larger. So, now the
facejunkies can go up to 128 Million faces, were it not that this will eat
up a load of memory!
I only have 1 Gig in this machine. A test with 9M vertices and 7.5M quads
eats up 912 MB of memory already. If this becomes a real issue, I know
tricks how to make the vertices 20 bytes smaller, and faces 4 bytes, which
would in the above case save about 200 MB. Not much... but probably worth
the try? A much better method is of course 'bucketing' the renderdata per
tile. It's a spec of the render recode, but not a quicky to add.
Also: bug fix in curve code. There was a short counter still, crashing on
large curves with resol set to 1024 :)
- ZTransp render now also delivers Z values and Speed vectors in passes
Note that speed vectors accumulate within a pixel to store the minimum,
so rendering ztransp on top of a non-moving plane won't give speed...
Best results you get is by rendering it in a separate layer.
The Z value stored is the closest visible transparent face in the pixel.
Fixes:
- Render to 'spare page' has been enabled again. Because of the strict
separation of Render and UI, but especially because a 'render result' now
can consist of unlimited images, I've not made this a Render feature.
Instead, the render-window itself stores the 'spare' image... I also
had to change the convention for it a bit.
Now, instead of having two "render buffers" (which was a render feature),
the RenderWindow will store each previous frame on a re-render. This
storing will only start after you've pressed 'Jkey' once, but then always
will happen for as long the rendered image is same size as previously.
For clarity, I've also renamed the window title, to 'previous frame'.
- RenderWindow shows alpha again on Akey
- Display of the Zvalues in ImageWindow has been tweaked. White now denotes
closest, and the color range goes from camera clip-sta to clip-end.
- Bugfix: on splitting/merging/duplicating windows, the 3D Previewrender was
not always freed correctly, potentially causing crashes or memory leaks.
After a couple of experiments with variable blur filters, I tried
a more interesting, and who knows... original approach. :)
First watch results here:
http://www.blender.org/bf/rt0001_0030.avihttp://www.blender.org/bf/hand0001_0060.avi
These are the steps in producing such results:
- In preprocess, the speed vectors to previous and next frame are
calculated. Speed vectors are screen-aligned and in pixel size.
- while rendering, these vectors get calculated per sample, and
accumulated in the vector buffer checking for "minimum speed".
(on start the vector buffer is initialized on max speed).
- After render:
- The entire image, all pixels, then is converted to quad polygons.
- Also the z value of the pixels is assigned to the polygons
- The vertices for the quads use averaged speed vectors (of the 4
corner faces), using a 'minimum but non-zero' speed rule.
This minimal speed trick works very well to prevent 'tearing' apart
when multiple faces move in different directions in a pixel, or to
be able to separate moving pixels clearly from non-moving ones
- So, now we have a sort of 'mask' of quad polygons. The previous steps
guaranteed that this mask doesn't have antialias color info, and has
speed vectors that ensure individual parts to move nicely without
tearing effects. The Z allows multiple layers of moving masks.
- Then, in temporal buffer, faces get tagged if they move or not
- These tags then go to an anti-alias routine, which assigns alpha
values to edge faces, based on the method we used in past to antialias
bitmaps (still in our code, check the antialias.c in imbuf!)
- finally, the tag buffer is used to tag which z values of the original
image have to be included (to allow blur go behind stuff).
- OK, now we're ready for accumulating! In a loop, all faces then get
drawn (with zbuffer) with increasing influence of their speed vectors.
The resulting image then is accumulated on top of the original with a
decreasing weighting value.
It sounds all quite complex... but the speed is still encouraging. Above
images have 64 mblur steps, which takes about 1-3 seconds per frame.
Usage notes:
- Make sure the render-layer has passes 'Vector' and 'Z' on.
- add in Compositor the VectorBlur node, and connect the image, Z and
speed to the inputs.
- The node allows to set amount of steps (10 steps = 10 forward, 10 back).
and to set a maximum speed in pixels... to prevent extreme moving things
to blur too wide.
- RenderLayers with 'view layers' set, now also take visible lights into
account. Works just like for scene layer settings.
- On ESC from render, compositing (if set) is being skipped too
- While rendering with multiple RenderLayers it will end with a display
of the current RenderLayer (as in Scene buttons)
- Enabled Groups to execute in Compositor. They were ignored still.
Note; inside of groups nothing is cached, so a change of a group input
will recalculate it fully. This is needed because groups are linked
data (instances use same internal nodes).
- Made Composit node "Viewer" display correctly input for images with
1/2/3/4 channels.
- Added pass rendering, tested now with only regular Materials. For
Material nodes this is quite more complex... since they cannot be
easily separated in passes (each Material does a full shade)
In this commit all pass render is disabled though, will continue work on
that later.
Sneak preview: http://www.blender.org/bf/rt.jpg (temporal image)
- What did remain is the 'Normal' pass output. Normal works very nice for
relighting effects. Use the "Normal Node" to define where more or less
light should be. (Use "Value Map" node to tweak influence of the
Normal node 'dot' output.)
- EVIL bug fix: I've spend almost a day finding it... when combining AO and
mirror render, the event queue was totally screwing up... two things not
related at all!
Found out error was in ray-mirror code, which was using partially
uninitialized 'ShadeInput' data to pass on to render code.
- Another fix; made sure that while thread render, the threads don't get
events, only the main program will do. Might fix issues reported by
people on linux/windows.
- Live scanline updates while rendering
Using a timer system, each second now the tiles that are being processed
are checked if they could use display.
To make this work pretty, I had to use the threaded 'tile processor' for
a single thread too, but that's now proven to be stable.
Also note that these updates draw per layer, including ztransp progress
separately from solid render.
- Recode of ztransp OSA
Until now (since blender 1.0) the ztransp part was fully rendered and
added on top of the solid part with alpha-over. This adding was done before
the solid part applied sub-pixel sample filtering, causing the ztransp
layer to be always too blurry.
Now the ztransp layer uses same sub=pixel filter, resulting in the same
AA level (and filter results) as the solid part. Quite noticable with hair
renders.
- Vector buffer support & preliminary vector-blur Node
Using the "Render Layer" panel "Vector" pass button, the motion vectors
per pixel are calculated and stored. Accessible via the Compositor.
The vector-blur node is horrible btw! It just uses the length of the
vector to apply a filter like with current (z)blur. I'm committing it anyway,
I'll experiment with it further, and who knows some surprise code shows up!
-> Rendering in RenderLayers
It's important to distinguish a 'render layer' from a 'pass'. The first is
control over the main pipeline itself, to indicate what geometry is being
is rendered. The 'pass' (not in this commit!) is related to internal
shading code, like shadow/spec/AO/normals/etc.
Options for RenderLayers now are:
- Indicate which 3d 'view layers' have to be included (so you can render
front and back separately)
- "Solid", all solid faces, includes sky at the moment too
- "ZTransp", all transparent faces
- "Halo", the halos
- "Strand", the particle strands (not coded yet...)
Currently only 2 'passes' are exported for render, which is the "Combined"
buffer and the "Z. The latter now works, and can be turned on/off.
Note that all layers are still fully kept in memory now, saving the tiles
and layers to disk (in exr) is also todo.
-> New Blur options
The existing Blur Node (compositor) now has an optional input image. This
has to be a 'value buffer', which can be a Zbuffer, or any mask you can
think of. The input values have to be in the 0-1 range, so another new
node was added too "Map Value".
The value input can also be used to tweak blur size with the (todo)
Time Node.
Temporal screenies:
http://www.blender.org/bf/rt.jpghttp://www.blender.org/bf/rt1.jpghttp://www.blender.org/bf/rt2.jpg
BTW: The compositor is very slow still, it recalulates all nodes on each
change still. Persistant memory and dependency checks is coming!
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!
- Image textures use float colors now, when present. Works for mipmap too,
and for AO skycolor (probes)
- Backbuffer option uses float buffers too. Note that rendering OSA will
resample the backbuffer, filtering it... will need to be solved with the
new composit stage
- LMB sampling in image window now shows float color too
+ bugfix in imbuf, filtering for float buffers had an error.
(WIP, don't bugs for this in tracker yet please!)
- New Panel "Layers" in Material buttons, allows to add unlimited amount
of materials on top of each other.
- Every Layer is actually just another Material, which gets rendered/shaded
(including texture), and then added on top of previous layer with an
operation like Mix, Add, Mult, etc.
- Layers render fully independent, so bumpmaps are not passed on to next
layers.
- Per Layer you can set if it influences Diffuse, Specular or Alpha
- If a Material returns alpha (like from texture), the alpha value is
used for adding the layers too.
- New texture "Map To" channel allows to have a texture work on a Layer
- Each layer, including basis Material, can be turned on/off individually
Notes:
- at this moment, the full shading pass happens for each layer, including
shadow, AO and raytraced mirror or transparency...
- I had to remove old hacks from preview render, which corrected reflected
normals for preview texturing.
- still needs loadsa testing!
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.
- The ortho render recode had a weak method to calculate the Z value of the
render coordinate (shi.co[2]). Worked OK for normal render, but not in
unified, giving big errors in Ortho Unfied render.
Solved with proper math, using face equation a*x+b*y+c*y=d. Dunno why I
didn't do it in first place. :)
- Bug fix#2493. Edge render gave much different result for Ortho. This
was due to overflows in the integer math filtering zbuffer values.
Cleaned it op properly, preventing any integer overflow now.
submitted by Alexander, changes/improvements are:
- Moved to new Panel in Scene buttons "Post Effects". Together with other
postprocessing options, such as Edge render. It is also not called DoF,
this because that's a bit pretending too much then. It's a zblur still!
- Made it render Alpha as well
- Made it use and deliver float buffers
- Huge cleanup of zblur.c code, was very messy. It was alling things in render
code without need even (win matrices, transform faces, etc)
- Fixed errors in using Z values (zbuffer is signed int)
- Removed very weird gamma corrections for front/back half
- Tweaked gaussian table, allow variable 'Sigma' to be set for gauss curve
- Didn't copy 'auto focus' yet. Use of this is very limited, and gives
false expectations, nor works for rendering anims with deamons well.
Main issue remains: it's not a very advanced feature... I still doubt
very much if this deserves to be released. Spent 2 days on trying to get
the key issues solved, with not much results.
- gauss filter code has weird side effects on large blur size
- having unsharp (blurred) in front also blurs what's around in back.
only blurred in back with sharp in front works a little bit
- severe aliasing errors... also due the code splitting in 2 halves
- doesnt work with unified yet
- won't work for halos, spot halos or transparant faces
Anyhoo... It was promised to be committed, so now artists can play with it.
Who knows it's useful after all, or some fixes can be implemented. :)
- Maximum faces/halos per pixel was 500, which wasn't correctly applied in
all cases, causing errors in AA
- Moved maximum up to 1000 now
- made halos become clipped away from filling in buffers when behind a
solid face. That saves a lot of rendertime!
Unified remains weak with halos...
- 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.
Alpha for halos was always added, even when "Add" slider was zero. Fixed.
(also; made BROW define BROW16, to distinguish from int version in
BKE_utildefines.h)
- zbuf; error caused by using unsigned int as counter (while >= 0) in radio
- backbuffer didnt load in initrender (was removed from sky render)
- unitialized variable in envmap.c
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!
Gaussian sampling/rendering now supported too!
Also corrected gamma corrected adding of colors, which gives better alpha
and blending with sky than normal render does. The latter I could check
once too...
When tracing a mirror with AO, the rendering was extremely slow due to
each mirror sample (like 8 per pixel) taking a full range of AO samples.
Now it uses for mirror samples a corrected amount, which makes sure for
a single pixel still a full AO range is used.
Makes mirror+AO render 5-6 times faster, at least.
- Ambient Occlusion is a more sophisticated ambient trick, which takes
nearby faces into account by firing a hemisphere of shadow-rays
around. AKA 'dirt shader'.
- Eeshlo made it a Lamp type, which doesn't fit well. I've moved the
settings to the World menu, and let the Material->ambient value control
the amount it contributes
- currently, the AO value is added/subtracted/mixed with the 'diffuse'
factor while shading, before it is multiplied with Material color
Buttons are in new Panel 'Amb Occ" in F8 menu. Note:
- "Dist:" by shortening the length of rays you get subtler effects and it
renders faster too
- "DistF:" the attennuation factor gives control over how the 'shadow'
spreads out.
Further it's just raytracing, so tends to be slooooow.... :)
Here same tricks as for other raytraced scenes apply, especially try to
keep the environment as small as possible (exclude faces from Octree by
giving them no Material Traceable).
I still have to think over a couple of aspects, will await feedback on it:
- AO color? Now it just adds 'white'
- other sampling patterns? I tried dithering, which was so-so
- method of controlling final 'samples' in F10? Might be useful for other
oversampling too (area light) to have it reacting to a percentage or so..
(1 lamp, shadow). The 'coherence' check gets reset now for each new
pixel rendered, which remains efficient for oversampling.
- small cleanups in code, prototype added, less globals.
already gave noise with area size of 0.1.
Limited buttons to minimum value of 0.01 for area light. For people
who want smaller they can scale it down in 3d, effectively reducing
the energy then as well.
At last irc meeting, eeshlo pointed to an error in the code. It didn't
use the IOR value correctly. This has been solved. So how it works now:
- the IOR button value influences (very subtle) the fresnel effect.
Only for realism diehards.
- the Fresnel value (slider) now denotes the power in the function
rf + (1-rf) * (1-c)^5
where rf= rf = ((ior-1)/(ior+1))^2
and c the dot-product ray/normal.
- so, set the slider at '5' and you have real fresnel. Lower values
for interesting artistic effects.
- put back the forgotten code for gaussian corrected sampling during
antialising render. Normally, each sub-pixel sample in Blender counts
equally, and together make up the pixel color.
With 'Gauss' option set (F10 menu) each sub-pixel sample creates a small
weighted mask with variable size, which (can) affect neighbouring pixels
as well. The result is smoother edges, less sensitive for gamma, and
well suited to reduce motion-aliasing (when things move extreme slow).
This is result of *long* period of research in NeoGeo days, and based on
every scientific sampling/reconstructing theory we could find. Plus a
little bit of our selves. :)
- I should write once how blender constructs Jitter tables for sub-sampling.
this is a very nice method, and superior to normal block filter or random
jittering... time!
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!
- implemented tracing of transparency for shadows. This is a material
option, in the new RayTrace panel.
it only traces color and alpha, not shading. So the results of some
transparant colored unlit faces can look odd. I will look onto that.
- changed fresnel formula (got hint from eeshlo!). this simplifies the UI,
now only one button needed. The fresnel value "should" be identical as
the refraction index, but that is booooring! So i added a special fresnel
refraction slider for both mirroring and transparency. By setting all 3
sliders equal, you get 'realism'.
- fresnel for transparancy works for Ztra rendering too. Same for transpa-
rent shadow. But then you need to set 'ray' on in F10 menu.
- uploaded new monkey_glass blend in download.blender.org/demo/test/
Next stage: killing the globals from render, and implement "translucency"
which is effectively allowing faces being lit from behind, as paper or
cloth.
Changelog:
- enable refraction with button "Ray Transp" in Material buttons.
- set "Angular Index" value for amount of refraction.
- use the "Alpha" value to define transparency.
- remember to set a higher "Depth" too... glass can bounce quite some
more than expected.
- for correct refraction, 3D models MUST have normals pointing in the
right direction (consistently pointing outside).
- refraction 'sees' the thickness of glass based on what you model. So
make for realistic glass both sides of a surface.
- I needed to do some rewriting for correct mirroring/refraction,
especially to prevent specularity being blended away.
Solved this with localizing shading results in the rendercore.c.
Now specularity correctly is added, and reduces the 'mirror' value.
- Localizing more parts of the render code is being planned. The old
render heavily relies on struct Render and struct Osa to store globals.
For scanline render no problem, but recursive raytracing dislikes that.
- done test with gamma-corrected summation of colors during tracing, is
commented out still. But this will give more balanced reflections. Now
dark reflections that are reflected in a bright surface seem incorrect.
- Introduced 'Fresnel' effect for Mirror and Transparency. This
influences the amount of mirror/transparency based at viewing angle.
Next to a new Fresnel slider, also a 'falloff' button has been added to
define the way it spreads.
- Fresnel also works for Ztransp rendering
- created new Panel for Raytrace options
I have to evaluate still where it all should be logically located.
- material preview shows fake reflection and fake refraction as well.
This is a revision of the old NeoGeo raytracer, dusted off, improved quite
a lot, and nicely integrated in the rest of rendering pipeline.
Enable it with F10-"Ray", and set either a 'ray-shadow' lamp or give the
Material a "RayMirror" value.
It has been added for 2 reasons:
- get feedback on validity... I need artists to play around with it if it's
actually useful. It still *is* raytracing, meaning complex scenes will
easily become slow.
- for educational purposes. All raytracing happens in ray.c, which can be
quite easily adjusted for other effects.
When too many disasters pop up with this, I'll make it a compile #ifdef.
But so far, it seems to do a decent job.
Demo files: http://www.blender.org/docs/ray_test.tgz
An article (tech) about how it works, and about the new octree invention
will be posted soon. :)
Note: it doesn't work with unified render yet.
do a make clean in source/blender/ to be sure!
- Included the new shaders from Cessen... well, only the shader calls
themselves. To make sure the shaders work I nicely integrated it
- MaterialButtons: layout changed a bit, but still resembles the old
layout. The 'shader' options now are located together.
- Shaders are separated in 'diffuse' and 'specular'. You can combine them
freely.
- diffuse Lambert: old shader
diffuse Oren Nayar: new shader, gives sandy/silky/skinny material well
diffuse Toon: for cartoon render
- specular Phong: new spec, traditional 70ies spec
specular CookTorr: a reduced version of cook torrance shading, does
off specular peak well
specular Blinn: new spec, same features as CookTorr, but with extra
'refraction' setting
specular Toon: new spec for cartoon render
- default blender starts with settings that render compatible!
- works in shaded view and preview-render
- works in unified render
Further little changes:
- removed paranoia compile warnings from render/loader/blenlib
- and the warnings at files I worked at were removed.
