It moves targa, bmp, iris and png loading so that were not opening
2 file handles for each file, and made them like the jpeg stuff.
Also cleaned up some minor other stuff.
Kent
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.
Appending objects with constraints expands links to objects (according
code) but doesn't give such objects a link to Scene.
Apprently, somewhere in NaN days, someone commented a call, which
already invoked comments... here's the full code + comments now:
/* give a base to loose objects */
give_base_to_objects(G.scene, &(G.main->object));
/* has been removed... erm, why? (ton) */
/* 20040907: looks like they are give base already in append_named_part(); -Nathan L */
/* 20041208: put back. It only linked direct, not indirect objects (ton) */
:-)
oops code, having pointers to ID structs that are invalid.
This solves at least it crashing... oops needs to be refreshed once :)
(occurred on testing complex files, with conversion from nurbs=>mesh)
Using ctrl+up/down in buttons window, didn't use a proper rescale of view
as already works for dragging window edges. Now the 'Full window' action
keeps size nicely.
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
- New channel for "Map to" added, "Warp"
- Use the slider next to the option to set amount of influence the texture
will have on the coordinates of the next texture.
- Warp uses for this the same values as for Normal or Displacement mapping
- Warp remains active for all channels, until replaced (or zeroed).
While going over the code, I found out the "nabla", the size of offset
vectors for calculating derivatives of a texture, is a built in constant.
Even worse, the value was different for new noise types (musgrave etc).
So I've added a new slider for it in the procedural texture panels, which
by default is set to 0.025, the value of the old constant. Also made sure
it works with equal effect in all procedurals.
NOTE: a small Nabla will give sharper, detailed bump, but the effect also
becomes smaller, correct that in the Mapping Panel of materials.
For better & compliant control over the bumpmapping, I've also included
the Colorband output in derivatives calculus, so the bump output then
matches the color created. It's also a nice tool to finetune output of
textures for bumpmapping in general.
Bug fix; clicking on the rightmose 'item' in ColorBand didn't activate it.
Found out the ColorBand was slightly drawn off (2 pixels).
Objects being vertex-parented to a mesh, which in turn was being deformed
by a curve or lattice, were never update correctly.
Whilst this is a typical issue for our beloved new Dependency Graph, I
consider it worth at least solving for now. An issue since Blender 1.0
you know. :)
Solution is only working for this specific case; vertex-parent to deformed
object.
causing weird results on camera moves or object rotations.
Added: support for "normal maps". See for example:
http://members.shaw.ca/jimht03/normal.html
The Image panel in Texture buttons has new option "Normal Map" for it.
When this is used, normals are read straight from RGB values, and blended
with the current normal.
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!)
Another tweak in the convex formula, replaced a ">" with ">=" for detecting
optimal projection of face in 2d. Solves issue reveiled in Bevel tool,
where it could happen that a face wasn't created.
When rotating camera itself in camera view, and choose local axis rotate,
the camera flipped around. Was due to using viewmat[][] while it changes...
Solved in the simplest elegant way; hope Martin will cope with this in new
transform!
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
Editmode Mesh, edge selectmode, not zbuffer on. Selecting edges didnt give
a small disadvantage to the already selected one, making it hard to select
edges that are extreme close or on top of each other.
Unified render added sky with alpha=1. Found the way how to fix it, didnt
dare that yesterday. :)
Now sky is rendered with alpha=0, like normal render.
Thanks to the recent reports, a lot of old issues with unified render have
been solved. This is going to be pretty OK!
When using a backbuffer with alpha, but alpha is not premulled, you can
get weird rendering results with halos or lens flare. This was caused by
optimize rule in alpha routine that assumed alpha==0 means color is zero.
Removed for the the halo case.
With material slider "Ray Mir" set non zero, but with toggle "Ray Mirror"
off, Blender accidentally entered a part of raytracing code, screwing up
the alpha value of the result.
#define B_UNLINKIMA 1358
Since it was undefined and causing things not to compile. Whoever added it
might want to move it but hey its working again for now. ;)
Kent
In renderwindow, press AKEY to see the alpha in B&W. Another AKEY shows
normal RGB again. This uses glColorMask, an opengl 1.0 function.
Really needed it for debugging alpha in rendering. :)
