archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
1525ed42c9b4d81deb686f3bdd5a5bdae70b5af2
blender-archive/source/blender/render/intern/source/texture.c

3064 lines
84 KiB
C
Raw Normal View History

Giant commit! 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!
2006-01-23 22:05:47 +00:00
/*
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
* $Id$
*
Giant commit! 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!
2006-01-23 22:05:47 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
Giant commit! 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!
2006-01-23 22:05:47 +00:00
* of the License, or (at your option) any later version.
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
Giant commit! 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!
2006-01-23 22:05:47 +00:00
* Contributor(s): 2004-2006, Blender Foundation, full recode
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
*
Giant commit! 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!
2006-01-23 22:05:47 +00:00
* ***** END GPL LICENSE BLOCK *****
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
#include "BLI_blenlib.h"
#include "BLI_arithb.h"
#include "BLI_rand.h"
#include "DNA_texture_types.h"
#include "DNA_object_types.h"
#include "DNA_lamp_types.h"
#include "DNA_mesh_types.h"
Quite a large one this time... but now we have: 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
2004-07-08 20:38:27 +00:00
#include "DNA_meshdata_types.h"
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
#include "DNA_material_types.h"
#include "DNA_image_types.h"
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
#include "DNA_node_types.h"
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
#include "IMB_imbuf_types.h"
#include "IMB_imbuf.h"
Colour Management - 1st stage: Linear Workflow This implements automatic linear workflow in Blender's renderer. With the new Colour Management option on in the Render buttons, all inputs to the renderer and compositor are converted to linear colour space before rendering, and gamma corrected afterwards. In essence, this makes all manual gamma correction with nodes, etc unnecessary, since it's done automatically through the pipeline. It's all explained much better in the notes/doc here, so please have a look: http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management And an example of the sort of difference it makes: http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg This also enables Colour Management in the default B.blend, and changes the default lamp falloff to inverse square, which is more correct, and much easier to use now it's all gamma corrected properly. Next step is to look into profiles/soft proofing for the compositor. Thanks to brecht for reviewing and fixing some oversights!
2009-07-17 02:43:15 +00:00
#include "BKE_colortools.h"
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
#include "BKE_image.h"
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
#include "BKE_node.h"
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
#include "BKE_plugin_types.h"
#include "BKE_utildefines.h"
#include "BKE_global.h"
#include "BKE_main.h"
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
#include "BKE_material.h"
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
#include "BKE_library.h"
#include "BKE_image.h"
#include "BKE_texture.h"
#include "BKE_key.h"
#include "BKE_ipo.h"
Next stage of RenderPipe refactor: now everything within the pixel was tackled. Resulting features: - render passes - new pass: Object Index, for masking - sub-sample alpha masks Docs: http://mediawiki.blender.org/index.php/BlenderDev/RenderPipeline http://www.blender3d.org/cms/Render_Passes.829.0.html http://www.blender3d.org/cms/New_Render_features.774.0.html Note that these changes might mean things to not render fully identical... For the next days a lot of testing is needed!
2006-12-05 16:43:01 +00:00
#include "envmap.h"
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
#include "pointdensity.h"
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
#include "voxeldata.h"
Giant commit! 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!
2006-01-23 22:05:47 +00:00
#include "renderpipeline.h"
#include "render_types.h"
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
#include "rendercore.h"
Next stage of RenderPipe refactor: now everything within the pixel was tackled. Resulting features: - render passes - new pass: Object Index, for masking - sub-sample alpha masks Docs: http://mediawiki.blender.org/index.php/BlenderDev/RenderPipeline http://www.blender3d.org/cms/Render_Passes.829.0.html http://www.blender3d.org/cms/New_Render_features.774.0.html Note that these changes might mean things to not render fully identical... For the next days a lot of testing is needed!
2006-12-05 16:43:01 +00:00
#include "shading.h"
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
#include "texture.h"
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
#include "renderdatabase.h" /* needed for UV */
Giant commit! 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!
2006-01-23 22:05:47 +00:00
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
/* defined in pipeline.c, is hardcopy of active dynamic allocated Render */
/* only to be used here in this file, it's for speed */
extern struct Render R;
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
void init_render_texture(Render *re, Tex *tex)
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
{
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
int cfra= re->scene->r.cfra;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
if(re) cfra= re->r.cfra;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* imap test */
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
if(tex->ima && ELEM(tex->ima->source, IMA_SRC_MOVIE, IMA_SRC_SEQUENCE)) {
BKE_image_user_calc_imanr(&tex->iuser, cfra, re?re->flag & R_SEC_FIELD:0);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(tex->type==TEX_PLUGIN) {
if(tex->plugin && tex->plugin->doit) {
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
if(tex->plugin->cfra) {
2.5: Blender "Animato" - New Animation System Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future. Highlights of the new system: * Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action. - F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves. - The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc. * F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated. * Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place) * F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place) * NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still) There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details: http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html So, what currently works: * I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code. * Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock. * Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc. Notes: * Drivers haven't been hooked up yet * Only objects and data directly linked to objects can be animated. * Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change). * Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor) * I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review. In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
2009-01-17 03:12:50 +00:00
*(tex->plugin->cfra)= (float)cfra; //frame_to_float(re->scene, cfra); // XXX old animsys - timing stuff to be fixed
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
else if(tex->type==TEX_ENVMAP) {
/* just in case */
Error in previous commit: the texture filter size should not be scaled at all if you use new 'minimal' option. The new option works much nicer if it only sets the minimum. (use texture with 'refl' map) Added option to env map too!
2007-12-28 19:38:47 +00:00
tex->imaflag |= TEX_INTERPOL | TEX_MIPMAP;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
tex->extend= TEX_CLIP;
if(tex->env) {
More environment map stuff: - added a zoom factor for Planar Environment Map, allowing to zoom in or out on the reflected object. The zoom is corrected when rendering, so it just gives control over the resolution. - Planar maps don't cycle anymore, but only render the front plane, using standard image texture extend mode. - threaded rendering is back in envmap render
2006-03-19 17:50:53 +00:00
if(tex->env->type==ENV_PLANE)
tex->extend= TEX_EXTEND;
/* only free envmap when rendermode was set to render envmaps, for previewrender */
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
if(G.rendering && re) {
Added option to only render a single side of an Environment map cube, 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.
2006-03-19 14:26:56 +00:00
if (re->r.mode & R_ENVMAP)
if(tex->env->stype==ENV_ANIM)
BKE_free_envmapdata(tex->env);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
if(tex->nodetree && tex->use_nodes) {
ntreeBeginExecTree(tex->nodetree); /* has internal flag to detect it only does it once */
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* ------------------------------------------------------------------------- */
Added option to only render a single side of an Environment map cube, 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.
2006-03-19 14:26:56 +00:00
void init_render_textures(Render *re)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Tex *tex;
tex= G.main->tex.first;
while(tex) {
Added option to only render a single side of an Environment map cube, 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.
2006-03-19 14:26:56 +00:00
if(tex->id.us) init_render_texture(re, tex);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
tex= tex->id.next;
}
}
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
void end_render_texture(Tex *tex)
{
if(tex && tex->use_nodes && tex->nodetree)
ntreeEndExecTree(tex->nodetree);
}
void end_render_textures(void)
{
Tex *tex;
for(tex= G.main->tex.first; tex; tex= tex->id.next)
if(tex->id.us)
end_render_texture(tex);
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* ------------------------------------------------------------------------- */
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
/* this allows colorbanded textures to control normals as well */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static void tex_normal_derivate(Tex *tex, TexResult *texres)
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
{
if (tex->flag & TEX_COLORBAND) {
float col[4];
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (do_colorband(tex->coba, texres->tin, col)) {
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
float fac0, fac1, fac2, fac3;
fac0= (col[0]+col[1]+col[2]);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
do_colorband(tex->coba, texres->nor[0], col);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
fac1= (col[0]+col[1]+col[2]);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
do_colorband(tex->coba, texres->nor[1], col);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
fac2= (col[0]+col[1]+col[2]);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
do_colorband(tex->coba, texres->nor[2], col);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
fac3= (col[0]+col[1]+col[2]);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0]= 0.3333*(fac0 - fac1);
texres->nor[1]= 0.3333*(fac0 - fac2);
texres->nor[2]= 0.3333*(fac0 - fac3);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
return;
}
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0]= texres->tin - texres->nor[0];
texres->nor[1]= texres->tin - texres->nor[1];
texres->nor[2]= texres->tin - texres->nor[2];
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int blend(Tex *tex, float *texvec, TexResult *texres)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
float x, y, t;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(tex->flag & TEX_FLIPBLEND) {
x= texvec[1];
y= texvec[0];
}
else {
x= texvec[0];
y= texvec[1];
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Added 'Radial' blend texture type for created colored radial gradients like that you might find on a CD. Special thanks to use Phlip in #blenderchat for help on the math. Thanks Philp!
2005-09-19 13:00:44 +00:00
if(tex->stype==TEX_LIN) { /* lin */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= (1.0+x)/2.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Added 'Radial' blend texture type for created colored radial gradients like that you might find on a CD. Special thanks to use Phlip in #blenderchat for help on the math. Thanks Philp!
2005-09-19 13:00:44 +00:00
else if(tex->stype==TEX_QUAD) { /* quad */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= (1.0+x)/2.0;
if(texres->tin<0.0) texres->tin= 0.0;
else texres->tin*= texres->tin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Added 'Radial' blend texture type for created colored radial gradients like that you might find on a CD. Special thanks to use Phlip in #blenderchat for help on the math. Thanks Philp!
2005-09-19 13:00:44 +00:00
else if(tex->stype==TEX_EASE) { /* ease */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= (1.0+x)/2.0;
if(texres->tin<=.0) texres->tin= 0.0;
else if(texres->tin>=1.0) texres->tin= 1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
t= texres->tin*texres->tin;
texres->tin= (3.0*t-2.0*t*texres->tin);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
Added 'Radial' blend texture type for created colored radial gradients like that you might find on a CD. Special thanks to use Phlip in #blenderchat for help on the math. Thanks Philp!
2005-09-19 13:00:44 +00:00
else if(tex->stype==TEX_DIAG) { /* diag */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= (2.0+x+y)/4.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Added 'Radial' blend texture type for created colored radial gradients like that you might find on a CD. Special thanks to use Phlip in #blenderchat for help on the math. Thanks Philp!
2005-09-19 13:00:44 +00:00
else if(tex->stype==TEX_RAD) { /* radial */
texres->tin= (atan2(y,x) / (2*M_PI) + 0.5);
}
else { /* sphere TEX_SPHERE */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= 1.0-sqrt(x*x+ y*y+texvec[2]*texvec[2]);
if(texres->tin<0.0) texres->tin= 0.0;
Use texture constants in the interface and added some missing texture constants.
2007-07-19 22:02:22 +00:00
if(tex->stype==TEX_HALO) texres->tin*= texres->tin; /* halo */
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
return TEX_INT;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* ------------------------------------------------------------------------- */
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
/* ************************************************************************* */
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* newnoise: all noisebased types now have different noisebases to choose from */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int clouds(Tex *tex, float *texvec, TexResult *texres)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv = TEX_INT;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = BLI_gTurbulence(tex->noisesize, texvec[0], texvec[1], texvec[2], tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
// calculate bumpnormal
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = BLI_gTurbulence(tex->noisesize, texvec[0] + tex->nabla, texvec[1], texvec[2], tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
texres->nor[1] = BLI_gTurbulence(tex->noisesize, texvec[0], texvec[1] + tex->nabla, texvec[2], tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
texres->nor[2] = BLI_gTurbulence(tex->noisesize, texvec[0], texvec[1], texvec[2] + tex->nabla, tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Use texture constants in the interface and added some missing texture constants.
2007-07-19 22:02:22 +00:00
if (tex->stype==TEX_COLOR) {
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
// in this case, int. value should really be computed from color,
// and bumpnormal from that, would be too slow, looks ok as is
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr = texres->tin;
texres->tg = BLI_gTurbulence(tex->noisesize, texvec[1], texvec[0], texvec[2], tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
texres->tb = BLI_gTurbulence(tex->noisesize, texvec[1], texvec[2], texvec[0], tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
BRICONTRGB;
texres->ta = 1.0;
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
return (rv | TEX_RGB);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
return rv;
}
Patch provided by Chris Burt; Wood/marble now have three waveforms to choose from: Sine, Saw and Triangle. The Saw wave allows for much more realistic wood, especially in combination with a ColorBand. A blender3d.org release page is being constructed about it. Added: commit in editmesh_add.c to remove circle warning in face-select mode.
2005-03-07 11:01:43 +00:00
/* creates a sine wave */
static float tex_sin(float a)
{
a = 0.5 + 0.5*sin(a);
return a;
}
/* creates a saw wave */
static float tex_saw(float a)
{
const float b = 2*M_PI;
int n = (int)(a / b);
a -= n*b;
if (a < 0) a += b;
return a / b;
}
/* creates a triangle wave */
static float tex_tri(float a)
{
const float b = 2*M_PI;
const float rmax = 1.0;
a = rmax - 2.0*fabs(floor((a*(1.0/b))+0.5) - (a*(1.0/b)));
return a;
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
/* computes basic wood intensity value at x,y,z */
static float wood_int(Tex *tex, float x, float y, float z)
{
Patch provided by Chris Burt; Wood/marble now have three waveforms to choose from: Sine, Saw and Triangle. The Saw wave allows for much more realistic wood, especially in combination with a ColorBand. A blender3d.org release page is being constructed about it. Added: commit in editmesh_add.c to remove circle warning in face-select mode.
2005-03-07 11:01:43 +00:00
float wi=0;
short wf = tex->noisebasis2; /* wave form: TEX_SIN=0, TEX_SAW=1, TEX_TRI=2 */
short wt = tex->stype; /* wood type: TEX_BAND=0, TEX_RING=1, TEX_BANDNOISE=2, TEX_RINGNOISE=3 */
float (*waveform[3])(float); /* create array of pointers to waveform functions */
waveform[0] = tex_sin; /* assign address of tex_sin() function to pointer array */
waveform[1] = tex_saw;
waveform[2] = tex_tri;
if ((wf>TEX_TRI) || (wf<TEX_SIN)) wf=0; /* check to be sure noisebasis2 is initialized ahead of time */
if (wt==TEX_BAND) {
wi = waveform[wf]((x + y + z)*10.0);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Patch provided by Chris Burt; Wood/marble now have three waveforms to choose from: Sine, Saw and Triangle. The Saw wave allows for much more realistic wood, especially in combination with a ColorBand. A blender3d.org release page is being constructed about it. Added: commit in editmesh_add.c to remove circle warning in face-select mode.
2005-03-07 11:01:43 +00:00
else if (wt==TEX_RING) {
wi = waveform[wf](sqrt(x*x + y*y + z*z)*20.0);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Patch provided by Chris Burt; Wood/marble now have three waveforms to choose from: Sine, Saw and Triangle. The Saw wave allows for much more realistic wood, especially in combination with a ColorBand. A blender3d.org release page is being constructed about it. Added: commit in editmesh_add.c to remove circle warning in face-select mode.
2005-03-07 11:01:43 +00:00
else if (wt==TEX_BANDNOISE) {
wi = tex->turbul*BLI_gNoise(tex->noisesize, x, y, z, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
wi = waveform[wf]((x + y + z)*10.0 + wi);
}
else if (wt==TEX_RINGNOISE) {
wi = tex->turbul*BLI_gNoise(tex->noisesize, x, y, z, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
wi = waveform[wf](sqrt(x*x + y*y + z*z)*20.0 + wi);
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
return wi;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int wood(Tex *tex, float *texvec, TexResult *texres)
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv=TEX_INT;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = wood_int(tex, texvec[0], texvec[1], texvec[2]);
if (texres->nor!=NULL) {
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
/* calculate bumpnormal */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = wood_int(tex, texvec[0] + tex->nabla, texvec[1], texvec[2]);
texres->nor[1] = wood_int(tex, texvec[0], texvec[1] + tex->nabla, texvec[2]);
texres->nor[2] = wood_int(tex, texvec[0], texvec[1], texvec[2] + tex->nabla);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
return rv;
}
/* computes basic marble intensity at x,y,z */
static float marble_int(Tex *tex, float x, float y, float z)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
float n, mi;
Patch provided by Chris Burt; Wood/marble now have three waveforms to choose from: Sine, Saw and Triangle. The Saw wave allows for much more realistic wood, especially in combination with a ColorBand. A blender3d.org release page is being constructed about it. Added: commit in editmesh_add.c to remove circle warning in face-select mode.
2005-03-07 11:01:43 +00:00
short wf = tex->noisebasis2; /* wave form: TEX_SIN=0, TEX_SAW=1, TEX_TRI=2 */
short mt = tex->stype; /* marble type: TEX_SOFT=0, TEX_SHARP=1,TEX_SHAPER=2 */
float (*waveform[3])(float); /* create array of pointers to waveform functions */
waveform[0] = tex_sin; /* assign address of tex_sin() function to pointer array */
waveform[1] = tex_saw;
waveform[2] = tex_tri;
if ((wf>TEX_TRI) || (wf<TEX_SIN)) wf=0; /* check to be sure noisebasis2 isn't initialized ahead of time */
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
n = 5.0 * (x + y + z);
Patch provided by Chris Burt; Wood/marble now have three waveforms to choose from: Sine, Saw and Triangle. The Saw wave allows for much more realistic wood, especially in combination with a ColorBand. A blender3d.org release page is being constructed about it. Added: commit in editmesh_add.c to remove circle warning in face-select mode.
2005-03-07 11:01:43 +00:00
mi = n + tex->turbul * BLI_gTurbulence(tex->noisesize, x, y, z, tex->noisedepth, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
if (mt>=TEX_SOFT) { /* TEX_SOFT always true */
mi = waveform[wf](mi);
if (mt==TEX_SHARP) {
mi = sqrt(mi);
}
else if (mt==TEX_SHARPER) {
mi = sqrt(sqrt(mi));
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
return mi;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int marble(Tex *tex, float *texvec, TexResult *texres)
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv=TEX_INT;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = marble_int(tex, texvec[0], texvec[1], texvec[2]);
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
/* calculate bumpnormal */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = marble_int(tex, texvec[0] + tex->nabla, texvec[1], texvec[2]);
texres->nor[1] = marble_int(tex, texvec[0], texvec[1] + tex->nabla, texvec[2]);
texres->nor[2] = marble_int(tex, texvec[0], texvec[1], texvec[2] + tex->nabla);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
return rv;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* ------------------------------------------------------------------------- */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int magic(Tex *tex, float *texvec, TexResult *texres)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
float x, y, z, turb=1.0;
int n;
n= tex->noisedepth;
turb= tex->turbul/5.0;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
x= sin( ( texvec[0]+texvec[1]+texvec[2])*5.0 );
y= cos( (-texvec[0]+texvec[1]-texvec[2])*5.0 );
z= -cos( (-texvec[0]-texvec[1]+texvec[2])*5.0 );
if(n>0) {
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
x*= turb;
y*= turb;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
z*= turb;
y= -cos(x-y+z);
y*= turb;
if(n>1) {
x= cos(x-y-z);
x*= turb;
if(n>2) {
z= sin(-x-y-z);
z*= turb;
if(n>3) {
x= -cos(-x+y-z);
x*= turb;
if(n>4) {
y= -sin(-x+y+z);
y*= turb;
if(n>5) {
y= -cos(-x+y+z);
y*= turb;
if(n>6) {
x= cos(x+y+z);
x*= turb;
if(n>7) {
z= sin(x+y-z);
z*= turb;
if(n>8) {
x= -cos(-x-y+z);
x*= turb;
if(n>9) {
y= -sin(x-y+z);
y*= turb;
}
}
}
}
}
}
}
}
}
}
if(turb!=0.0) {
turb*= 2.0;
x/= turb;
y/= turb;
z/= turb;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr= 0.5-x;
texres->tg= 0.5-y;
texres->tb= 0.5-z;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= 0.3333*(texres->tr+texres->tg+texres->tb);
As addition to the use of Colorband for normals; - Stucci now accepts it too (for normals and color) Note; stucci doesn't return a single value, like marble or wood, that's still so, to disable it coloring the "Col" Map input by default. - Magic texture now accepts Colorband
2004-12-10 18:29:16 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONTRGB;
texres->ta= 1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
return TEX_RGB;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* ------------------------------------------------------------------------- */
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* newnoise: stucci also modified to use different noisebasis */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int stucci(Tex *tex, float *texvec, TexResult *texres)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
float nor[3], b2, ofs;
int retval= TEX_INT;
Preview Texture for Stucci works again. NOTE: stucci didn't return 'intensity' since blender 1.0, something that alsways caused headaches all over (all other textures do per definition). But, allowing stucci to return 'intensity' would break old files. To make it work for preview, I had to solve this once. Done with a version patch, so old files (including current 2.41!) won't read with color channel active for Stucci textures. (Preview.blend I saved as a 2.42 file btw!)
2006-06-16 15:31:32 +00:00
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
b2= BLI_gNoise(tex->noisesize, texvec[0], texvec[1], texvec[2], (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
Preview Texture for Stucci works again. NOTE: stucci didn't return 'intensity' since blender 1.0, something that alsways caused headaches all over (all other textures do per definition). But, allowing stucci to return 'intensity' would break old files. To make it work for preview, I had to solve this once. Done with a version patch, so old files (including current 2.41!) won't read with color channel active for Stucci textures. (Preview.blend I saved as a 2.42 file btw!)
2006-06-16 15:31:32 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
ofs= tex->turbul/200.0;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(tex->stype) ofs*=(b2*b2);
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
nor[0] = BLI_gNoise(tex->noisesize, texvec[0]+ofs, texvec[1], texvec[2], (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
nor[1] = BLI_gNoise(tex->noisesize, texvec[0], texvec[1]+ofs, texvec[2], (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
nor[2] = BLI_gNoise(tex->noisesize, texvec[0], texvec[1], texvec[2]+ofs, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
As addition to the use of Colorband for normals; - Stucci now accepts it too (for normals and color) Note; stucci doesn't return a single value, like marble or wood, that's still so, to disable it coloring the "Col" Map input by default. - Magic texture now accepts Colorband
2004-12-10 18:29:16 +00:00
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
texres->tin= nor[2];
As addition to the use of Colorband for normals; - Stucci now accepts it too (for normals and color) Note; stucci doesn't return a single value, like marble or wood, that's still so, to disable it coloring the "Col" Map input by default. - Magic texture now accepts Colorband
2004-12-10 18:29:16 +00:00
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
if(texres->nor) {
VECCOPY(texres->nor, nor);
tex_normal_derivate(tex, texres);
Use texture constants in the interface and added some missing texture constants.
2007-07-19 22:02:22 +00:00
if(tex->stype==TEX_WALLOUT) {
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
texres->nor[0]= -texres->nor[0];
texres->nor[1]= -texres->nor[1];
texres->nor[2]= -texres->nor[2];
}
retval |= TEX_NOR;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
Use texture constants in the interface and added some missing texture constants.
2007-07-19 22:02:22 +00:00
if(tex->stype==TEX_WALLOUT)
Fix #4406 The Stucci texture now returns an 'intensity' value too, this wasn't too interesting though... not reflecting all options for the texture itself. Now it shows better in preview renders.
2006-06-22 09:27:33 +00:00
texres->tin= 1.0f-texres->tin;
if(texres->tin<0.0f)
texres->tin= 0.0f;
return retval;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* ------------------------------------------------------------------------- */
/* newnoise: musgrave terrain noise types */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static float mg_mFractalOrfBmTex(Tex *tex, float *texvec, TexResult *texres)
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv = TEX_INT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
float (*mgravefunc)(float, float, float, float, float, float, int);
if (tex->stype==TEX_MFRACTAL)
mgravefunc = mg_MultiFractal;
else
mgravefunc = mg_fBm;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = tex->ns_outscale*mgravefunc(texvec[0], texvec[1], texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->noisebasis);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
float offs= tex->nabla/tex->noisesize; // also scaling of texvec
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* calculate bumpnormal */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = tex->ns_outscale*mgravefunc(texvec[0] + offs, texvec[1], texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->noisebasis);
texres->nor[1] = tex->ns_outscale*mgravefunc(texvec[0], texvec[1] + offs, texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->noisebasis);
texres->nor[2] = tex->ns_outscale*mgravefunc(texvec[0], texvec[1], texvec[2] + offs, tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->noisebasis);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
return rv;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static float mg_ridgedOrHybridMFTex(Tex *tex, float *texvec, TexResult *texres)
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv = TEX_INT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
float (*mgravefunc)(float, float, float, float, float, float, float, float, int);
if (tex->stype==TEX_RIDGEDMF)
mgravefunc = mg_RidgedMultiFractal;
else
mgravefunc = mg_HybridMultiFractal;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = tex->ns_outscale*mgravefunc(texvec[0], texvec[1], texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->mg_gain, tex->noisebasis);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
float offs= tex->nabla/tex->noisesize; // also scaling of texvec
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* calculate bumpnormal */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = tex->ns_outscale*mgravefunc(texvec[0] + offs, texvec[1], texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->mg_gain, tex->noisebasis);
texres->nor[1] = tex->ns_outscale*mgravefunc(texvec[0], texvec[1] + offs, texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->mg_gain, tex->noisebasis);
texres->nor[2] = tex->ns_outscale*mgravefunc(texvec[0], texvec[1], texvec[2] + offs, tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->mg_gain, tex->noisebasis);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
return rv;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static float mg_HTerrainTex(Tex *tex, float *texvec, TexResult *texres)
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv = TEX_INT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = tex->ns_outscale*mg_HeteroTerrain(texvec[0], texvec[1], texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->noisebasis);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
float offs= tex->nabla/tex->noisesize; // also scaling of texvec
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* calculate bumpnormal */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = tex->ns_outscale*mg_HeteroTerrain(texvec[0] + offs, texvec[1], texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->noisebasis);
texres->nor[1] = tex->ns_outscale*mg_HeteroTerrain(texvec[0], texvec[1] + offs, texvec[2], tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->noisebasis);
texres->nor[2] = tex->ns_outscale*mg_HeteroTerrain(texvec[0], texvec[1], texvec[2] + offs, tex->mg_H, tex->mg_lacunarity, tex->mg_octaves, tex->mg_offset, tex->noisebasis);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
return rv;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static float mg_distNoiseTex(Tex *tex, float *texvec, TexResult *texres)
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv = TEX_INT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = mg_VLNoise(texvec[0], texvec[1], texvec[2], tex->dist_amount, tex->noisebasis, tex->noisebasis2);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
float offs= tex->nabla/tex->noisesize; // also scaling of texvec
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* calculate bumpnormal */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = mg_VLNoise(texvec[0] + offs, texvec[1], texvec[2], tex->dist_amount, tex->noisebasis, tex->noisebasis2);
texres->nor[1] = mg_VLNoise(texvec[0], texvec[1] + offs, texvec[2], tex->dist_amount, tex->noisebasis, tex->noisebasis2);
texres->nor[2] = mg_VLNoise(texvec[0], texvec[1], texvec[2] + offs, tex->dist_amount, tex->noisebasis, tex->noisebasis2);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
return rv;
}
/* ------------------------------------------------------------------------- */
/* newnoise: Voronoi texture type, probably the slowest, especially with minkovsky, bumpmapping, could be done another way */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static float voronoiTex(Tex *tex, float *texvec, TexResult *texres)
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
{
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
int rv = TEX_INT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
float da[4], pa[12]; /* distance and point coordinate arrays of 4 nearest neighbours */
float aw1 = fabs(tex->vn_w1);
float aw2 = fabs(tex->vn_w2);
float aw3 = fabs(tex->vn_w3);
float aw4 = fabs(tex->vn_w4);
float sc = (aw1 + aw2 + aw3 + aw4);
if (sc!=0.f) sc = tex->ns_outscale/sc;
voronoi(texvec[0], texvec[1], texvec[2], da, pa, tex->vn_mexp, tex->vn_distm);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin = sc * fabs(tex->vn_w1*da[0] + tex->vn_w2*da[1] + tex->vn_w3*da[2] + tex->vn_w4*da[3]);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
if (tex->vn_coltype) {
float ca[3]; /* cell color */
cellNoiseV(pa[0], pa[1], pa[2], ca);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr = aw1*ca[0];
texres->tg = aw1*ca[1];
texres->tb = aw1*ca[2];
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
cellNoiseV(pa[3], pa[4], pa[5], ca);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr += aw2*ca[0];
texres->tg += aw2*ca[1];
texres->tb += aw2*ca[2];
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
cellNoiseV(pa[6], pa[7], pa[8], ca);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr += aw3*ca[0];
texres->tg += aw3*ca[1];
texres->tb += aw3*ca[2];
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
cellNoiseV(pa[9], pa[10], pa[11], ca);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr += aw4*ca[0];
texres->tg += aw4*ca[1];
texres->tb += aw4*ca[2];
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
if (tex->vn_coltype>=2) {
float t1 = (da[1]-da[0])*10;
if (t1>1) t1=1;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (tex->vn_coltype==3) t1*=texres->tin; else t1*=sc;
texres->tr *= t1;
texres->tg *= t1;
texres->tb *= t1;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tr *= sc;
texres->tg *= sc;
texres->tb *= sc;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (texres->nor!=NULL) {
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
float offs= tex->nabla/tex->noisesize; // also scaling of texvec
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* calculate bumpnormal */
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
voronoi(texvec[0] + offs, texvec[1], texvec[2], da, pa, tex->vn_mexp, tex->vn_distm);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[0] = sc * fabs(tex->vn_w1*da[0] + tex->vn_w2*da[1] + tex->vn_w3*da[2] + tex->vn_w4*da[3]);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
voronoi(texvec[0], texvec[1] + offs, texvec[2], da, pa, tex->vn_mexp, tex->vn_distm);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[1] = sc * fabs(tex->vn_w1*da[0] + tex->vn_w2*da[1] + tex->vn_w3*da[2] + tex->vn_w4*da[3]);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
voronoi(texvec[0], texvec[1], texvec[2] + offs, da, pa, tex->vn_mexp, tex->vn_distm);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->nor[2] = sc * fabs(tex->vn_w1*da[0] + tex->vn_w2*da[1] + tex->vn_w3*da[2] + tex->vn_w4*da[3]);
More tweaks related to bump mapping quality; 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).
2004-12-07 14:46:48 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tex_normal_derivate(tex, texres);
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
rv |= TEX_NOR;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
if (tex->vn_coltype) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONTRGB;
texres->ta = 1.0;
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
return (rv | TEX_RGB);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
return rv;
}
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
/* ------------------------------------------------------------------------- */
Slight refactor of texture nodes. Delegates now receive a TexParams* instead of float *coords. This gives texture nodes access to dxt, dyt, cfra as well as coords. This fixes the time node and allows nice sampling to be implemented.
2009-08-17 20:30:11 +00:00
static int evalnodes(Tex *tex, float *texvec, float *dxt, float *dyt, TexResult *texres, short thread, short which_output)
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
{
short rv = TEX_INT;
bNodeTree *nodes = tex->nodetree;
Sorry, three commits in one, became difficult to untangle.. Editors Modules * render/ module added in editors, moved the preview render code there and also shading related operators. * physics/ module made more consistent with other modules. renaming files, making a single physics_ops.c for operators and keymaps. Also move all particle related operators here now. * space_buttons/ now should have only operators relevant to the buttons specificially. Updates & Notifiers * Material/Texture/World/Lamp can now be passed to DAG_id_flush_update, which will go back to a callback in editors. Eventually these should be in the depsgraph itself, but for now this gives a unified call for doing updates. * GLSL materials are now refreshed on changes. There's still various cases missing, * Preview icons now hook into this system, solving various update cases that were missed before. * Also fixes issue in my last commit, where some preview would not render, problem is avoided in the new system. Icon Rendering * On systems with support for non-power of two textures, an OpenGL texture is now used instead of glDrawPixels. This avoids problems with icons get clipped on region borders. On my Linux desktop, this gives an 1.1x speedup, and on my Mac laptop a 2.3x speedup overall in redrawing the full window, with the default setup. The glDrawPixels implementation on Mac seems to have a lot of overhread. * Preview icons are now drawn using proper premul alpha, and never faded so you can see them clearly. * Also tried to fix issue with texture node preview rendering, globals can't be used with threads reliably.
2009-09-29 19:12:12 +00:00
ntreeTexExecTree(nodes, texres, texvec, dxt, dyt, thread, tex, which_output, R.r.cfra, (R.r.scemode & R_NODE_PREVIEW));
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
if(texres->nor) rv |= TEX_NOR;
rv |= TEX_RGB;
return rv;
}
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* ------------------------------------------------------------------------- */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int texnoise(Tex *tex, TexResult *texres)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
float div=3.0;
int val, ran, loop;
ran= BLI_rand();
val= (ran & 3);
loop= tex->noisedepth;
while(loop--) {
ran= (ran>>2);
val*= (ran & 3);
div*= 3.0;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= ((float)val)/div;;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Code cleanup: using defines in texture.c for whether a function returns intensity, color and/or normal. Patch provided by Guillermo, thanks!
2005-11-19 18:24:32 +00:00
return TEX_INT;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* ------------------------------------------------------------------------- */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
static int plugintex(Tex *tex, float *texvec, float *dxt, float *dyt, int osatex, TexResult *texres)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
PluginTex *pit;
int rgbnor=0;
This is an expanded patch of this: [#8067] external texture plugin thread-safe modifications Submitted By: David Anderson (davywavy) It makes it so the "result" array is passed in, instead of a global var. I expanded the patch so it will play nice with older plugins that are not thread safe as well. I also updated the existing plugins in the release, so they are thread safe. --------------- What do people think of this.... ------------------ This should maybe be talked about in the functionality board or something, but what do people think of adding in default texture/sequence plugins. or making a seperate tree like lib for plugins. The reason I ask is we have had a couple of upgrades to the plugin system. (supporting float buffers for sequencer, and this one for textures) http://www.cs.umn.edu/~mein/blender/plugins does not store revisions of plugins I just make sure they work with the latest version. This is getting messy. I haven't upgraded a lot of them to use floats (I know, I'm lazy, and now this will also make modifications to the plugins) It would be nice to have some of the standard ones under revision control. We also seem to be having an explosion of platforms supported. It would be nice to have platform maintainers compiling plugins as well for releases. (Its getting to be more work for me to keep up with things...) I'll go back to my corner now and be quite. ;) Kent
2008-04-18 19:10:03 +00:00
float result[ 8 ];
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->tin= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
pit= tex->plugin;
if(pit && pit->doit) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres->nor) {
This is an expanded patch of this: [#8067] external texture plugin thread-safe modifications Submitted By: David Anderson (davywavy) It makes it so the "result" array is passed in, instead of a global var. I expanded the patch so it will play nice with older plugins that are not thread safe as well. I also updated the existing plugins in the release, so they are thread safe. --------------- What do people think of this.... ------------------ This should maybe be talked about in the functionality board or something, but what do people think of adding in default texture/sequence plugins. or making a seperate tree like lib for plugins. The reason I ask is we have had a couple of upgrades to the plugin system. (supporting float buffers for sequencer, and this one for textures) http://www.cs.umn.edu/~mein/blender/plugins does not store revisions of plugins I just make sure they work with the latest version. This is getting messy. I haven't upgraded a lot of them to use floats (I know, I'm lazy, and now this will also make modifications to the plugins) It would be nice to have some of the standard ones under revision control. We also seem to be having an explosion of platforms supported. It would be nice to have platform maintainers compiling plugins as well for releases. (Its getting to be more work for me to keep up with things...) I'll go back to my corner now and be quite. ;) Kent
2008-04-18 19:10:03 +00:00
if (pit->version < 6) {
VECCOPY(pit->result+5, texres->nor);
} else {
VECCOPY(result+5, texres->nor);
}
}
if (pit->version < 6) {
if(osatex) rgbnor= ((TexDoitold)pit->doit)(tex->stype,
pit->data, texvec, dxt, dyt);
else rgbnor= ((TexDoitold)pit->doit)(tex->stype,
pit->data, texvec, 0, 0);
} else {
if(osatex) rgbnor= ((TexDoit)pit->doit)(tex->stype,
pit->data, texvec, dxt, dyt, result);
else rgbnor= ((TexDoit)pit->doit)(tex->stype,
pit->data, texvec, 0, 0, result);
- fixed crashing texture plugin, caused by not checking the tex->nor pointer. Now variables are localized, this is not always set anymore.
2003-12-29 20:05:15 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
This is an expanded patch of this: [#8067] external texture plugin thread-safe modifications Submitted By: David Anderson (davywavy) It makes it so the "result" array is passed in, instead of a global var. I expanded the patch so it will play nice with older plugins that are not thread safe as well. I also updated the existing plugins in the release, so they are thread safe. --------------- What do people think of this.... ------------------ This should maybe be talked about in the functionality board or something, but what do people think of adding in default texture/sequence plugins. or making a seperate tree like lib for plugins. The reason I ask is we have had a couple of upgrades to the plugin system. (supporting float buffers for sequencer, and this one for textures) http://www.cs.umn.edu/~mein/blender/plugins does not store revisions of plugins I just make sure they work with the latest version. This is getting messy. I haven't upgraded a lot of them to use floats (I know, I'm lazy, and now this will also make modifications to the plugins) It would be nice to have some of the standard ones under revision control. We also seem to be having an explosion of platforms supported. It would be nice to have platform maintainers compiling plugins as well for releases. (Its getting to be more work for me to keep up with things...) I'll go back to my corner now and be quite. ;) Kent
2008-04-18 19:10:03 +00:00
if (pit->version < 6) {
texres->tin = pit->result[0];
} else {
texres->tin = result[0];
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(rgbnor & TEX_NOR) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres->nor) {
This is an expanded patch of this: [#8067] external texture plugin thread-safe modifications Submitted By: David Anderson (davywavy) It makes it so the "result" array is passed in, instead of a global var. I expanded the patch so it will play nice with older plugins that are not thread safe as well. I also updated the existing plugins in the release, so they are thread safe. --------------- What do people think of this.... ------------------ This should maybe be talked about in the functionality board or something, but what do people think of adding in default texture/sequence plugins. or making a seperate tree like lib for plugins. The reason I ask is we have had a couple of upgrades to the plugin system. (supporting float buffers for sequencer, and this one for textures) http://www.cs.umn.edu/~mein/blender/plugins does not store revisions of plugins I just make sure they work with the latest version. This is getting messy. I haven't upgraded a lot of them to use floats (I know, I'm lazy, and now this will also make modifications to the plugins) It would be nice to have some of the standard ones under revision control. We also seem to be having an explosion of platforms supported. It would be nice to have platform maintainers compiling plugins as well for releases. (Its getting to be more work for me to keep up with things...) I'll go back to my corner now and be quite. ;) Kent
2008-04-18 19:10:03 +00:00
if (pit->version < 6) {
VECCOPY(texres->nor, pit->result+5);
} else {
VECCOPY(texres->nor, result+5);
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
if(rgbnor & TEX_RGB) {
This is an expanded patch of this: [#8067] external texture plugin thread-safe modifications Submitted By: David Anderson (davywavy) It makes it so the "result" array is passed in, instead of a global var. I expanded the patch so it will play nice with older plugins that are not thread safe as well. I also updated the existing plugins in the release, so they are thread safe. --------------- What do people think of this.... ------------------ This should maybe be talked about in the functionality board or something, but what do people think of adding in default texture/sequence plugins. or making a seperate tree like lib for plugins. The reason I ask is we have had a couple of upgrades to the plugin system. (supporting float buffers for sequencer, and this one for textures) http://www.cs.umn.edu/~mein/blender/plugins does not store revisions of plugins I just make sure they work with the latest version. This is getting messy. I haven't upgraded a lot of them to use floats (I know, I'm lazy, and now this will also make modifications to the plugins) It would be nice to have some of the standard ones under revision control. We also seem to be having an explosion of platforms supported. It would be nice to have platform maintainers compiling plugins as well for releases. (Its getting to be more work for me to keep up with things...) I'll go back to my corner now and be quite. ;) Kent
2008-04-18 19:10:03 +00:00
if (pit->version < 6) {
texres->tr = pit->result[1];
texres->tg = pit->result[2];
texres->tb = pit->result[3];
texres->ta = pit->result[4];
} else {
texres->tr = result[1];
texres->tg = result[2];
texres->tb = result[3];
texres->ta = result[4];
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONTRGB;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
BRICONT;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
return rgbnor;
}
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
static int cubemap_glob(float *n, float x, float y, float z, float *adr1, float *adr2)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
float x1, y1, z1, nor[3];
int ret;
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
if(n==NULL) {
- fix for cubemap, rendered without render face available. currently only for preview render and displaylist. It then uses the provided texture coordinate itself... Solution is not perfect... disadvantage of not having globals! then you have to fix all mess! :)
2004-01-11 22:15:24 +00:00
nor[0]= x; nor[1]= y; nor[2]= z; // use local render coord
- previewrender with mapping type "Cube" didnt show correctly. added fake 'face normal' for this case
2004-01-05 21:18:47 +00:00
}
else {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
VECCOPY(nor, n);
- previewrender with mapping type "Cube" didnt show correctly. added fake 'face normal' for this case
2004-01-05 21:18:47 +00:00
}
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4Mul3Vecfl(R.viewinv, nor);
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
x1= fabs(nor[0]);
y1= fabs(nor[1]);
z1= fabs(nor[2]);
if(z1>=x1 && z1>=y1) {
*adr1 = (x + 1.0) / 2.0;
*adr2 = (y + 1.0) / 2.0;
ret= 0;
}
else if(y1>=x1 && y1>=z1) {
*adr1 = (x + 1.0) / 2.0;
*adr2 = (z + 1.0) / 2.0;
ret= 1;
}
else {
*adr1 = (y + 1.0) / 2.0;
*adr2 = (z + 1.0) / 2.0;
ret= 2;
}
return ret;
}
/* ------------------------------------------------------------------------- */
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
/* mtex argument only for projection switches */
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
static int cubemap(MTex *mtex, VlakRen *vlr, float *n, float x, float y, float z, float *adr1, float *adr2)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
int proj[4]={0, ME_PROJXY, ME_PROJXZ, ME_PROJYZ}, ret= 0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
if(vlr) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
int index;
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
/* Mesh vertices have such flags, for others we calculate it once based on orco */
if((vlr->puno & (ME_PROJXY|ME_PROJXZ|ME_PROJYZ))==0) {
More render pipeline finishing up; - Shaded drawmode is back (shift+z). Note it still only uses orco texture; but lighting/shading is using the internal render module entirely. - "Make Sticky" option back. (Also fix in sticky texture render, was wrong scaled)
2006-05-28 11:49:22 +00:00
/* test for v1, vlr can be faked for baking */
if(vlr->v1 && vlr->v1->orco) {
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
float nor[3];
CalcNormFloat(vlr->v1->orco, vlr->v2->orco, vlr->v3->orco, nor);
if( fabs(nor[0])<fabs(nor[2]) && fabs(nor[1])<fabs(nor[2]) ) vlr->puno |= ME_PROJXY;
else if( fabs(nor[0])<fabs(nor[1]) && fabs(nor[2])<fabs(nor[1]) ) vlr->puno |= ME_PROJXZ;
else vlr->puno |= ME_PROJYZ;
}
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
else return cubemap_glob(n, x, y, z, adr1, adr2);
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
}
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
if(mtex) {
/* the mtex->proj{xyz} have type char. maybe this should be wider? */
/* casting to int ensures that the index type is right. */
index = (int) mtex->projx;
proj[index]= ME_PROJXY;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
index = (int) mtex->projy;
proj[index]= ME_PROJXZ;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
index = (int) mtex->projz;
proj[index]= ME_PROJYZ;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
if(vlr->puno & proj[1]) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
*adr1 = (x + 1.0) / 2.0;
*adr2 = (y + 1.0) / 2.0;
}
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
else if(vlr->puno & proj[2]) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
*adr1 = (x + 1.0) / 2.0;
*adr2 = (z + 1.0) / 2.0;
ret= 1;
}
else {
*adr1 = (y + 1.0) / 2.0;
*adr2 = (z + 1.0) / 2.0;
ret= 2;
}
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
}
else {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
return cubemap_glob(n, x, y, z, adr1, adr2);
Fix for cube map error subsurf. - cubemap relied on pointer to MFace, which is only available for Mesh when directly converted to renderfaces. It then checked the 'puno' flag where also bits were set to indicate the optimal projection for a face (XY, XZ or YZ). - I found out the renderface also has a puno flag, so the mface pointer in a renderface is redundant. Is removed now - added code in texture cubemap call, which checks on a projection flag in 'puno'. If not set, it uses the orco's to calculate one. - this means, that cubemap now also works for other objects than meshes, provided they have an orco block while render. - if no orco block available, it uses the 'global' projection to find which of the cube sides map. I couldnt find other errors with subsurf & orco though...
2004-01-07 20:29:21 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
return ret;
}
/* ------------------------------------------------------------------------- */
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
static int cubemap_ob(Object *ob, float *n, float x, float y, float z, float *adr1, float *adr2)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
float x1, y1, z1, nor[3];
int ret;
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
if(n==NULL) return 0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
VECCOPY(nor, n);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
if(ob) Mat4Mul3Vecfl(ob->imat, nor);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
x1= fabs(nor[0]);
y1= fabs(nor[1]);
z1= fabs(nor[2]);
if(z1>=x1 && z1>=y1) {
*adr1 = (x + 1.0) / 2.0;
*adr2 = (y + 1.0) / 2.0;
ret= 0;
}
else if(y1>=x1 && y1>=z1) {
*adr1 = (x + 1.0) / 2.0;
*adr2 = (z + 1.0) / 2.0;
ret= 1;
}
else {
*adr1 = (y + 1.0) / 2.0;
*adr2 = (z + 1.0) / 2.0;
ret= 2;
}
return ret;
}
/* ------------------------------------------------------------------------- */
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
static void do_2d_mapping(MTex *mtex, float *t, VlakRen *vlr, float *n, float *dxt, float *dyt)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Tex *tex;
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
Object *ob= NULL;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
float fx, fy, fac1, area[8];
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
int ok, proj, areaflag= 0, wrap, texco;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
/* mtex variables localized, only cubemap doesn't cooperate yet... */
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
wrap= mtex->mapping;
tex= mtex->tex;
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
ob= mtex->object;
texco= mtex->texco;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(R.osa==0) {
if(wrap==MTEX_FLAT) {
fx = (t[0] + 1.0) / 2.0;
fy = (t[1] + 1.0) / 2.0;
}
else if(wrap==MTEX_TUBE) tubemap(t[0], t[1], t[2], &fx, &fy);
else if(wrap==MTEX_SPHERE) spheremap(t[0], t[1], t[2], &fx, &fy);
else {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
if(texco==TEXCO_OBJECT) cubemap_ob(ob, n, t[0], t[1], t[2], &fx, &fy);
else if(texco==TEXCO_GLOB) cubemap_glob(n, t[0], t[1], t[2], &fx, &fy);
else cubemap(mtex, vlr, n, t[0], t[1], t[2], &fx, &fy);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* repeat */
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
if(tex->extend==TEX_REPEAT) {
if(tex->xrepeat>1) {
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
float origf= fx *= tex->xrepeat;
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
if(fx>1.0) fx -= (int)(fx);
else if(fx<0.0) fx+= 1-(int)(fx);
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
if(tex->flag & TEX_REPEAT_XMIR) {
int orig= (int)floor(origf);
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
if(orig & 1)
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
fx= 1.0-fx;
}
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
}
if(tex->yrepeat>1) {
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
float origf= fy *= tex->yrepeat;
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
if(fy>1.0) fy -= (int)(fy);
else if(fy<0.0) fy+= 1-(int)(fy);
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
if(tex->flag & TEX_REPEAT_YMIR) {
int orig= (int)floor(origf);
if(orig & 1)
fy= 1.0-fy;
}
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* crop */
if(tex->cropxmin!=0.0 || tex->cropxmax!=1.0) {
fac1= tex->cropxmax - tex->cropxmin;
fx= tex->cropxmin+ fx*fac1;
}
if(tex->cropymin!=0.0 || tex->cropymax!=1.0) {
fac1= tex->cropymax - tex->cropymin;
fy= tex->cropymin+ fy*fac1;
}
t[0]= fx;
t[1]= fy;
}
else {
if(wrap==MTEX_FLAT) {
fx= (t[0] + 1.0) / 2.0;
fy= (t[1] + 1.0) / 2.0;
dxt[0]/= 2.0;
dxt[1]/= 2.0;
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
dxt[2]/= 2.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
dyt[0]/= 2.0;
dyt[1]/= 2.0;
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
dyt[2]/= 2.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if ELEM(wrap, MTEX_TUBE, MTEX_SPHERE) {
/* exception: the seam behind (y<0.0) */
ok= 1;
if(t[1]<=0.0) {
fx= t[0]+dxt[0];
fy= t[0]+dyt[0];
if(fx>=0.0 && fy>=0.0 && t[0]>=0.0);
else if(fx<=0.0 && fy<=0.0 && t[0]<=0.0);
else ok= 0;
}
if(ok) {
if(wrap==MTEX_TUBE) {
tubemap(t[0], t[1], t[2], area, area+1);
tubemap(t[0]+dxt[0], t[1]+dxt[1], t[2]+dxt[2], area+2, area+3);
tubemap(t[0]+dyt[0], t[1]+dyt[1], t[2]+dyt[2], area+4, area+5);
}
else {
spheremap(t[0], t[1], t[2],area,area+1);
spheremap(t[0]+dxt[0], t[1]+dxt[1], t[2]+dxt[2], area+2, area+3);
spheremap(t[0]+dyt[0], t[1]+dyt[1], t[2]+dyt[2], area+4, area+5);
}
areaflag= 1;
}
else {
if(wrap==MTEX_TUBE) tubemap(t[0], t[1], t[2], &fx, &fy);
else spheremap(t[0], t[1], t[2], &fx, &fy);
dxt[0]/= 2.0;
dxt[1]/= 2.0;
dyt[0]/= 2.0;
dyt[1]/= 2.0;
}
}
else {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
if(texco==TEXCO_OBJECT) proj = cubemap_ob(ob, n, t[0], t[1], t[2], &fx, &fy);
else if (texco==TEXCO_GLOB) proj = cubemap_glob(n, t[0], t[1], t[2], &fx, &fy);
else proj = cubemap(mtex, vlr, n, t[0], t[1], t[2], &fx, &fy);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(proj==1) {
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
SWAP(float, dxt[1], dxt[2]);
SWAP(float, dyt[1], dyt[2]);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(proj==2) {
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
float f1= dxt[0], f2= dyt[0];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
dxt[0]= dxt[1];
dyt[0]= dyt[1];
dxt[1]= dxt[2];
dyt[1]= dyt[2];
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
dxt[2]= f1;
dyt[2]= f2;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
dxt[0] *= 0.5f;
dxt[1] *= 0.5f;
dxt[2] *= 0.5f;
dyt[0] *= 0.5f;
dyt[1] *= 0.5f;
dyt[2] *= 0.5f;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* if area, then reacalculate dxt[] and dyt[] */
if(areaflag) {
fx= area[0];
fy= area[1];
dxt[0]= area[2]-fx;
dxt[1]= area[3]-fy;
dyt[0]= area[4]-fx;
dyt[1]= area[5]-fy;
}
/* repeat */
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
if(tex->extend==TEX_REPEAT) {
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
float max= 1.0f;
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
if(tex->xrepeat>1) {
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
float origf= fx *= tex->xrepeat;
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
// TXF: omit mirror here, see comments in do_material_tex() after do_2d_mapping() call
2.5 * Make EWA new default, rename Default to Box. * Fix windows compile issue in texture filter code.
2009-07-22 17:20:04 +00:00
if (tex->texfilter == TXF_BOX) {
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
if(fx>1.0f) fx -= (int)(fx);
else if(fx<0.0f) fx+= 1-(int)(fx);
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
if(tex->flag & TEX_REPEAT_XMIR) {
int orig= (int)floor(origf);
if(orig & 1)
fx= 1.0f-fx;
}
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
}
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
max= tex->xrepeat;
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
dxt[0]*= tex->xrepeat;
dyt[0]*= tex->xrepeat;
}
if(tex->yrepeat>1) {
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
float origf= fy *= tex->yrepeat;
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
// TXF: omit mirror here, see comments in do_material_tex() after do_2d_mapping() call
2.5 * Make EWA new default, rename Default to Box. * Fix windows compile issue in texture filter code.
2009-07-22 17:20:04 +00:00
if (tex->texfilter == TXF_BOX) {
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
if(fy>1.0f) fy -= (int)(fy);
else if(fy<0.0f) fy+= 1-(int)(fy);
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
if(tex->flag & TEX_REPEAT_YMIR) {
int orig= (int)floor(origf);
if(orig & 1)
fy= 1.0f-fy;
}
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
}
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
if(max<tex->yrepeat)
max= tex->yrepeat;
Important bugfix: Image mapping "repeat" didn't support mirrored tiling yet: http://www.blender.org/bf/rep1.jpg Psst psst... to solve this bug I had to add the buttons for the option too!
2007-01-14 11:51:52 +00:00
Sneaked in new feature (request samo): The Image texture repeat options, now allow a "Checker" repeat. With odd and even tiles set separately, and a size button to set a 'Mortar' inbetween tiles. http://www.blender3d.org/cms/Render_engine_features.215.0.html Also fixed bug: using 'CalcAlpha' option for image textures didn't give antialised edges for image.
2004-04-28 18:08:34 +00:00
dxt[1]*= tex->yrepeat;
dyt[1]*= tex->yrepeat;
}
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
if(max!=1.0f) {
Bugfix #4687 Repeat Image texture was broken... the repeat value for Y was accidentally multiplied twice, typo... had to change a 1 into 2 :) Error introduced in 2.41 btw, 2.40 and older were OK.
2006-07-13 15:41:36 +00:00
dxt[2]*= max;
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
dyt[2]*= max;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* crop */
if(tex->cropxmin!=0.0 || tex->cropxmax!=1.0) {
fac1= tex->cropxmax - tex->cropxmin;
fx= tex->cropxmin+ fx*fac1;
dxt[0]*= fac1;
dyt[0]*= fac1;
}
if(tex->cropymin!=0.0 || tex->cropymax!=1.0) {
fac1= tex->cropymax - tex->cropymin;
fy= tex->cropymin+ fy*fac1;
dxt[1]*= fac1;
dyt[1]*= fac1;
}
t[0]= fx;
t[1]= fy;
}
}
/* ************************************** */
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
static int multitex(Tex *tex, float *texvec, float *dxt, float *dyt, int osatex, TexResult *texres, short thread, short which_output)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
float tmpvec[3];
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
int retval=0; /* return value, int:0, col:1, nor:2, everything:3 */
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres->talpha= 0; /* is set when image texture returns alpha (considered premul) */
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
if(tex->use_nodes && tex->nodetree) {
Slight refactor of texture nodes. Delegates now receive a TexParams* instead of float *coords. This gives texture nodes access to dxt, dyt, cfra as well as coords. This fixes the time node and allows nice sampling to be implemented.
2009-08-17 20:30:11 +00:00
retval = evalnodes(tex, texvec, dxt, dyt, texres, thread, which_output);
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
}
else
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
switch(tex->type) {
case 0:
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
texres->tin= 0.0f;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
return 0;
case TEX_CLOUDS:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= clouds(tex, texvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_WOOD:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= wood(tex, texvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_MARBLE:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= marble(tex, texvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_MAGIC:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= magic(tex, texvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_BLEND:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= blend(tex, texvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_STUCCI:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= stucci(tex, texvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_NOISE:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= texnoise(tex, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_IMAGE:
2.5: Texture Filtering Patch by Alfredo de Greef with high quality image texture filters. This adds 3 new filters: * SAT: Summed Area Tables. This is like mipmaps, but using somewhat more memory avoids some artifacts. * EWA: Ellipitical Weighted Average, anisotropic filter. * FELINE: Fast elliptical lines for anisotropic texture mapping. The one change I made to this was to try to fix an alpha/premul problem, hopefully I didn't break anything, it looks compatible with the existing filter now for me.
2009-07-21 13:20:35 +00:00
if(osatex) retval= imagewraposa(tex, tex->ima, NULL, texvec, dxt, dyt, texres);
The Big Image refactor! 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.
2006-12-20 17:57:56 +00:00
else retval= imagewrap(tex, tex->ima, NULL, texvec, texres);
3D view orbit option: Around Active This fixes the active object in place when orbiting the view. Choppy 15fps demo can be seen there: http://www.elysiun.com/~theeth/bf/around_active.html Image Memory Grabage Collection This adds memory handling to the image code. An image is tagged each time it is used. During a collection cycle (frequency of cycles is user defined), if an image is older than a user defined limit, its buffer gets deallocated. This also applies to gl memory buffers. Images that are loading in GL memory needs to go through two time outs before being fully deallocated: the first time out deallocated the gl memorry, the second the buffer in ram. Notes: Image buffer loaded from python gets tagged as permanent upon load. That tag is removed when python stops using the image. I might have missed some tagging spots, especially in the rendering pipeline. Someone with more knowledge about this code should check to be careful. Tagging is done on every access, for rendering, this will probably be a performance hit. A scheme should be developped to only tag when the rendering is completed. Collecting is called in draw_object, most likely not the best place to do it. Safe from undo, since using undo deallocates memory anyway (like when loading a blend file with one currently opened) Userpref DNA changes: I've changed a couple of flagging variables from short to int. Some because they needed more space, others to keep SDNA happy. Info window changes: I've grouped a couple of buttons in aligned blocks and changed the color of mutually exclusive options to make them clearer. Matt didn't do any changes on that in tuhopuu, so hopefully I'm not stepping on anyone's feet with this. Also changed double constants into floats with f in a couple of places (mostly space.c) to make compiler happier.
2005-07-06 00:33:41 +00:00
tag_image_time(tex->ima); /* tag image as having being used */
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_PLUGIN:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= plugintex(tex, texvec, dxt, dyt, osatex, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
case TEX_ENVMAP:
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
retval= envmaptex(tex, texvec, dxt, dyt, osatex, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
case TEX_MUSGRAVE:
/* newnoise: musgrave types */
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* ton: added this, for Blender convention reason.
* artificer: added the use of tmpvec to avoid scaling texvec
*/
VECCOPY(tmpvec, texvec);
VecMulf(tmpvec, 1.0/tex->noisesize);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
switch(tex->stype) {
case TEX_MFRACTAL:
case TEX_FBM:
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
retval= mg_mFractalOrfBmTex(tex, tmpvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
case TEX_RIDGEDMF:
case TEX_HYBRIDMF:
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
retval= mg_ridgedOrHybridMFTex(tex, tmpvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
case TEX_HTERRAIN:
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
retval= mg_HTerrainTex(tex, tmpvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
break;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
/* newnoise: voronoi type */
case TEX_VORONOI:
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* ton: added this, for Blender convention reason.
* artificer: added the use of tmpvec to avoid scaling texvec
*/
VECCOPY(tmpvec, texvec);
VecMulf(tmpvec, 1.0/tex->noisesize);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
retval= voronoiTex(tex, tmpvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
case TEX_DISTNOISE:
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* ton: added this, for Blender convention reason.
* artificer: added the use of tmpvec to avoid scaling texvec
*/
VECCOPY(tmpvec, texvec);
VecMulf(tmpvec, 1.0/tex->noisesize);
Eesho's patch for new noise textures! Basically this provides three new things: 1. Choice of a list of noise-base functions, which can be used by the current Clouds, Marble, Wood textures as well. 2. Three new texture types: Musgrave, Voronoi and DistortedNoise 3. Python access to noise functions (not for render!) All of this together makes Blender's builtin procedural textures a LOT more powerful. Here again, a full webpage should be made to show off all possibilities, and explain some of the more scientific names for settings. A good read on Musgrave textures can be found here: http://www.ypoart.com/Downloads/Musgrave.htm About Voronoi: http://www.ypoart.com/Downloads/Worley.htm I can't find official DistortedNoise docs easily... maybe its something Eeshlo created himself. I've spent some time to change the patch Eeshlo provided. Worth noting: - created main texture "Musgrave" with 5 sub choices (instead of 5 new main textures) - added for all new textures the option to scale (zoom in out) - added patch in do_versions to initialize variables I hope the Python team will check on the Noise.c API. And include in docs!
2004-04-03 13:59:27 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
retval= mg_distNoiseTex(tex, tmpvec, texres);
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
break;
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
case TEX_POINTDENSITY:
retval= pointdensitytex(tex, texvec, texres);
break;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
case TEX_VOXELDATA:
retval= voxeldatatex(tex, texvec, texres);
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
if (tex->flag & TEX_COLORBAND) {
float col[4];
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if (do_colorband(tex->coba, texres->tin, col)) {
texres->talpha= 1;
texres->tr= col[0];
texres->tg= col[1];
texres->tb= col[2];
texres->ta= col[3];
* fix for small bug in volume texture stack
2009-06-21 22:17:06 +00:00
retval |= TEX_RGB;
NEW: Ramp shades for diffuse and specular http://www.blender3d.org/cms/Ramp_Shaders.348.0.html Material color and specular now can be defined by a Colorband. The actual color then is defined during shading based on: - shade value (like dotproduct) - energy value (dot product plus light) - normal - result of all shading (useful for adding stuff in the end) Special request from [A]ndy! :)
2004-06-30 18:54:09 +00:00
}
}
return retval;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
texture forcefields had a bug where uninitialized values could be used. do_texture_effector assumed multitex_ext would assign r/g/b colors which isnt true for grey textures. Fallback to PFIELD_TEX_GRAD with grey textures, node this in tooltip also.
2008-02-17 23:53:48 +00:00
/* Warning, if the texres's values are not declared zero, check the return value to be sure
* the color values are set before using the r/g/b values, otherwise you may use uninitialized values - Campbell */
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
int multitex_ext(Tex *tex, float *texvec, float *dxt, float *dyt, int osatex, TexResult *texres)
{
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
return multitex_thread(tex, texvec, dxt, dyt, osatex, texres, 0, 0);
}
int multitex_thread(Tex *tex, float *texvec, float *dxt, float *dyt, int osatex, TexResult *texres, short thread, short which_output)
{
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
if(tex==NULL) {
memset(texres, 0, sizeof(TexResult));
return 0;
}
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
/* Image requires 2d mapping conversion */
if(tex->type==TEX_IMAGE) {
MTex mtex;
float texvec_l[3], dxt_l[3], dyt_l[3];
mtex.mapping= MTEX_FLAT;
mtex.tex= tex;
mtex.object= NULL;
mtex.texco= TEXCO_ORCO;
VECCOPY(texvec_l, texvec);
Bugfix #4341 The code added to ensure Image textures in nodes use the correct mapping settings (UV, repeat, etc) crashed when editing non-osa cases.
2006-06-16 12:33:35 +00:00
if(dxt && dyt) {
VECCOPY(dxt_l, dxt);
VECCOPY(dyt_l, dyt);
}
else {
dxt_l[0]= dxt_l[1]= dxt_l[2]= 0.0f;
dyt_l[0]= dyt_l[1]= dyt_l[2]= 0.0f;
}
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
do_2d_mapping(&mtex, texvec_l, NULL, NULL, dxt_l, dyt_l);
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
return multitex(tex, texvec_l, dxt_l, dyt_l, osatex, texres, thread, which_output);
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
}
else
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
return multitex(tex, texvec, dxt, dyt, osatex, texres, thread, which_output);
Bugfix #4212 Material Nodes: The Texture node didn't do the standard "2d mapping" yet in case an Image Texture is used. Caused wrong mapping for example for UV coordinate inputs.
2006-05-23 14:15:07 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* ------------------------------------------------------------------------- */
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
/* in = destination, tex = texture, out = previous color */
/* fact = texture strength, facg = button strength value */
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 22:09:57 +00:00
void texture_rgb_blend(float *in, float *tex, float *out, float fact, float facg, int blendtype)
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
{
Added new operators for "MapTo" panel as suggested & partially coded by Kent Mein. So next to the mix, mult, add, sub we have now: - Div: divides by texture color - Screen: is like Mult, but works opposite (makes lighter) - Diff: the difference between texture color and material - Light: if texture is lighter it shows (per component) - Dark: if texture is darker it shows (per component) Next step: add this for specular and mirror, and the other channels... I commit it now because it also fixes error in previous commit.
2004-07-02 22:29:06 +00:00
float facm, col;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
switch(blendtype) {
case MTEX_BLEND:
Rewound changes done in alpha calculus for texturemapping. This worked OK for alpha coming from antialising (rendered) but failed to do in other situations (alpha as blending, painted in gimp)
2004-07-14 18:18:21 +00:00
fact*= facg;
facm= 1.0-fact;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
in[0]= (fact*tex[0] + facm*out[0]);
in[1]= (fact*tex[1] + facm*out[1]);
in[2]= (fact*tex[2] + facm*out[2]);
break;
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
case MTEX_MUL:
fact*= facg;
facm= 1.0-facg;
in[0]= (facm+fact*tex[0])*out[0];
in[1]= (facm+fact*tex[1])*out[1];
in[2]= (facm+fact*tex[2])*out[2];
break;
Added new operators for "MapTo" panel as suggested & partially coded by Kent Mein. So next to the mix, mult, add, sub we have now: - Div: divides by texture color - Screen: is like Mult, but works opposite (makes lighter) - Diff: the difference between texture color and material - Light: if texture is lighter it shows (per component) - Dark: if texture is darker it shows (per component) Next step: add this for specular and mirror, and the other channels... I commit it now because it also fixes error in previous commit.
2004-07-02 22:29:06 +00:00
case MTEX_SCREEN:
fact*= facg;
facm= 1.0-facg;
Orange branch feature; Material Layering (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!
2005-12-04 14:32:21 +00:00
in[0]= 1.0 - (facm+fact*(1.0-tex[0])) * (1.0-out[0]);
in[1]= 1.0 - (facm+fact*(1.0-tex[1])) * (1.0-out[1]);
in[2]= 1.0 - (facm+fact*(1.0-tex[2])) * (1.0-out[2]);
Added new operators for "MapTo" panel as suggested & partially coded by Kent Mein. So next to the mix, mult, add, sub we have now: - Div: divides by texture color - Screen: is like Mult, but works opposite (makes lighter) - Diff: the difference between texture color and material - Light: if texture is lighter it shows (per component) - Dark: if texture is darker it shows (per component) Next step: add this for specular and mirror, and the other channels... I commit it now because it also fixes error in previous commit.
2004-07-02 22:29:06 +00:00
break;
Blending mode "Overlay" was not coded yet for material blending.
2007-12-03 16:06:34 +00:00
case MTEX_OVERLAY:
fact*= facg;
facm= 1.0-facg;
if(out[0] < 0.5f)
in[0] = out[0] * (facm + 2.0f*fact*tex[0]);
else
in[0] = 1.0f - (facm + 2.0f*fact*(1.0 - tex[0])) * (1.0 - out[0]);
if(out[1] < 0.5f)
in[1] = out[1] * (facm + 2.0f*fact*tex[1]);
else
in[1] = 1.0f - (facm + 2.0f*fact*(1.0 - tex[1])) * (1.0 - out[1]);
if(out[2] < 0.5f)
in[2] = out[2] * (facm + 2.0f*fact*tex[2]);
else
in[2] = 1.0f - (facm + 2.0f*fact*(1.0 - tex[2])) * (1.0 - out[2]);
break;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
case MTEX_SUB:
fact= -fact;
case MTEX_ADD:
fact*= facg;
in[0]= (fact*tex[0] + out[0]);
in[1]= (fact*tex[1] + out[1]);
in[2]= (fact*tex[2] + out[2]);
Added new operators for "MapTo" panel as suggested & partially coded by Kent Mein. So next to the mix, mult, add, sub we have now: - Div: divides by texture color - Screen: is like Mult, but works opposite (makes lighter) - Diff: the difference between texture color and material - Light: if texture is lighter it shows (per component) - Dark: if texture is darker it shows (per component) Next step: add this for specular and mirror, and the other channels... I commit it now because it also fixes error in previous commit.
2004-07-02 22:29:06 +00:00
break;
case MTEX_DIV:
fact*= facg;
facm= 1.0-fact;
if(tex[0]!=0.0)
in[0]= facm*out[0] + fact*out[0]/tex[0];
if(tex[1]!=0.0)
in[1]= facm*out[1] + fact*out[1]/tex[1];
if(tex[2]!=0.0)
in[2]= facm*out[2] + fact*out[2]/tex[2];
break;
case MTEX_DIFF:
fact*= facg;
facm= 1.0-fact;
in[0]= facm*out[0] + fact*fabs(tex[0]-out[0]);
in[1]= facm*out[1] + fact*fabs(tex[1]-out[1]);
in[2]= facm*out[2] + fact*fabs(tex[2]-out[2]);
break;
case MTEX_DARK:
fact*= facg;
facm= 1.0-fact;
col= fact*tex[0];
if(col < out[0]) in[0]= col; else in[0]= out[0];
col= fact*tex[1];
if(col < out[1]) in[1]= col; else in[1]= out[1];
col= fact*tex[2];
if(col < out[2]) in[2]= col; else in[2]= out[2];
break;
case MTEX_LIGHT:
fact*= facg;
facm= 1.0-fact;
col= fact*tex[0];
if(col > out[0]) in[0]= col; else in[0]= out[0];
col= fact*tex[1];
if(col > out[1]) in[1]= col; else in[1]= out[1];
col= fact*tex[2];
if(col > out[2]) in[2]= col; else in[2]= out[2];
break;
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
case MTEX_BLEND_HUE:
fact*= facg;
VECCOPY(in, out);
ramp_blend(MA_RAMP_HUE, in, in+1, in+2, fact, tex);
break;
case MTEX_BLEND_SAT:
fact*= facg;
VECCOPY(in, out);
ramp_blend(MA_RAMP_SAT, in, in+1, in+2, fact, tex);
break;
case MTEX_BLEND_VAL:
fact*= facg;
VECCOPY(in, out);
ramp_blend(MA_RAMP_VAL, in, in+1, in+2, fact, tex);
break;
case MTEX_BLEND_COLOR:
fact*= facg;
VECCOPY(in, out);
ramp_blend(MA_RAMP_COLOR, in, in+1, in+2, fact, tex);
break;
committing patch #19252-Soft/Linear Light blend modes+Darken mode bug fix
2009-09-10 03:00:50 +00:00
case MTEX_SOFT_LIGHT:
fact*= facg;
VECCOPY(in, out);
ramp_blend(MA_RAMP_SOFT, in, in+1, in+2, fact, tex);
break;
case MTEX_LIN_LIGHT:
fact*= facg;
VECCOPY(in, out);
ramp_blend(MA_RAMP_LINEAR, in, in+1, in+2, fact, tex);
break;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
}
}
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 22:09:57 +00:00
float texture_value_blend(float tex, float out, float fact, float facg, int blendtype, int flip)
Three in one: - 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.
2004-07-03 14:18:21 +00:00
{
committing patch #19252-Soft/Linear Light blend modes+Darken mode bug fix
2009-09-10 03:00:50 +00:00
float in=0.0, facm, col, scf;
Three in one: - 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.
2004-07-03 14:18:21 +00:00
fact*= facg;
facm= 1.0-fact;
if(flip) SWAP(float, fact, facm);
switch(blendtype) {
case MTEX_BLEND:
in= fact*tex + facm*out;
break;
case MTEX_MUL:
facm= 1.0-facg;
in= (facm+fact*tex)*out;
break;
case MTEX_SCREEN:
facm= 1.0-facg;
in= 1.0-(facm+fact*(1.0-tex))*(1.0-out);
break;
case MTEX_SUB:
fact= -fact;
case MTEX_ADD:
in= fact*tex + out;
break;
case MTEX_DIV:
if(tex!=0.0)
in= facm*out + fact*out/tex;
break;
case MTEX_DIFF:
in= facm*out + fact*fabs(tex-out);
break;
case MTEX_DARK:
col= fact*tex;
if(col < out) in= col; else in= out;
break;
case MTEX_LIGHT:
col= fact*tex;
if(col > out) in= col; else in= out;
break;
committing patch #19252-Soft/Linear Light blend modes+Darken mode bug fix
2009-09-10 03:00:50 +00:00
case MTEX_SOFT_LIGHT:
col= fact*tex;
scf=1.0 - (1.0 - tex) * (1.0 - out);
in= facm*out + fact * ((1.0 - out) * tex * out) + (out * scf);
break;
case MTEX_LIN_LIGHT:
if (tex > 0.5)
in = out + fact*(2*(tex - 0.5));
else
in = out + fact*(2*tex - 1);
break;
Three in one: - 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.
2004-07-03 14:18:21 +00:00
}
return in;
}
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
static void texco_mapping(ShadeInput* shi, Tex* tex, MTex* mtex, float* co, float* dx, float* dy, float* texvec, float* dxt, float* dyt)
{
// new: first swap coords, then map, then trans/scale
if (tex->type == TEX_IMAGE) {
// placement
texvec[0] = mtex->projx ? co[mtex->projx - 1] : 0.f;
texvec[1] = mtex->projy ? co[mtex->projy - 1] : 0.f;
texvec[2] = mtex->projz ? co[mtex->projz - 1] : 0.f;
if (shi->osatex) {
if (mtex->projx) {
dxt[0] = dx[mtex->projx - 1];
dyt[0] = dy[mtex->projx - 1];
}
else dxt[0] = dyt[0] = 0.f;
if (mtex->projy) {
dxt[1] = dx[mtex->projy - 1];
dyt[1] = dy[mtex->projy - 1];
}
else dxt[1] = dyt[1] = 0.f;
if (mtex->projz) {
dxt[2] = dx[mtex->projz - 1];
dyt[2] = dy[mtex->projz - 1];
}
else dxt[2] = dyt[2] = 0.f;
}
do_2d_mapping(mtex, texvec, shi->vlr, shi->facenor, dxt, dyt);
// translate and scale
texvec[0] = mtex->size[0]*(texvec[0] - 0.5f) + mtex->ofs[0] + 0.5f;
texvec[1] = mtex->size[1]*(texvec[1] - 0.5f) + mtex->ofs[1] + 0.5f;
if (shi->osatex) {
dxt[0] = mtex->size[0]*dxt[0];
dxt[1] = mtex->size[1]*dxt[1];
dyt[0] = mtex->size[0]*dyt[0];
dyt[1] = mtex->size[1]*dyt[1];
}
/* problem: repeat-mirror is not a 'repeat' but 'extend' in imagetexture.c */
// TXF: bug was here, only modify texvec when repeat mode set, old code affected other modes too.
// New texfilters solve mirroring differently so that it also works correctly when
// textures are scaled (sizeXYZ) as well as repeated. See also modification in do_2d_mapping().
// (since currently only done in osa mode, results will look incorrect without osa TODO)
if (tex->extend == TEX_REPEAT && (tex->flag & TEX_REPEAT_XMIR)) {
2.5 * Make EWA new default, rename Default to Box. * Fix windows compile issue in texture filter code.
2009-07-22 17:20:04 +00:00
if (tex->texfilter == TXF_BOX)
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
texvec[0] -= floorf(texvec[0]); // this line equivalent to old code, same below
else if (texvec[0] < 0.f || texvec[0] > 1.f) {
const float tx = 0.5f*texvec[0];
texvec[0] = 2.f*(tx - floorf(tx));
if (texvec[0] > 1.f) texvec[0] = 2.f - texvec[0];
}
}
if (tex->extend == TEX_REPEAT && (tex->flag & TEX_REPEAT_YMIR)) {
2.5 * Make EWA new default, rename Default to Box. * Fix windows compile issue in texture filter code.
2009-07-22 17:20:04 +00:00
if (tex->texfilter == TXF_BOX)
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
texvec[1] -= floorf(texvec[1]);
else if (texvec[1] < 0.f || texvec[1] > 1.f) {
const float ty = 0.5f*texvec[1];
texvec[1] = 2.f*(ty - floorf(ty));
if (texvec[1] > 1.f) texvec[1] = 2.f - texvec[1];
}
}
}
else { // procedural
// placement
texvec[0] = mtex->size[0]*(mtex->projx ? (co[mtex->projx - 1] + mtex->ofs[0]) : mtex->ofs[0]);
texvec[1] = mtex->size[1]*(mtex->projy ? (co[mtex->projy - 1] + mtex->ofs[1]) : mtex->ofs[1]);
texvec[2] = mtex->size[2]*(mtex->projz ? (co[mtex->projz - 1] + mtex->ofs[2]) : mtex->ofs[2]);
if (shi->osatex) {
if (mtex->projx) {
dxt[0] = mtex->size[0]*dx[mtex->projx - 1];
dyt[0] = mtex->size[0]*dy[mtex->projx - 1];
}
else dxt[0] = 0.f;
if (mtex->projy) {
dxt[1] = mtex->size[1]*dx[mtex->projy - 1];
dyt[1] = mtex->size[1]*dy[mtex->projy - 1];
}
else dxt[1] = 0.f;
if (mtex->projz) {
dxt[2] = mtex->size[2]*dx[mtex->projz - 1];
dyt[2] = mtex->size[2]*dy[mtex->projz - 1];
}
else dxt[2]= 0.f;
}
}
}
Three in one: - 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.
2004-07-03 14:18:21 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
void do_material_tex(ShadeInput *shi)
{
MTex *mtex;
Tex *tex;
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
TexResult texres= {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0, NULL};
Added new operators for "MapTo" panel as suggested & partially coded by Kent Mein. So next to the mix, mult, add, sub we have now: - Div: divides by texture color - Screen: is like Mult, but works opposite (makes lighter) - Diff: the difference between texture color and material - Light: if texture is lighter it shows (per component) - Dark: if texture is darker it shows (per component) Next step: add this for specular and mirror, and the other channels... I commit it now because it also fixes error in previous commit.
2004-07-02 22:29:06 +00:00
float *co = NULL, *dx = NULL, *dy = NULL;
Three in one: - 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.
2004-07-03 14:18:21 +00:00
float fact, facm, factt, facmm, stencilTin=1.0;
Patch/Bugfix #7334 by 'gsr b3d: Some more compiler warning fixes. Some of these seem to be specific to GCC 4.1
2007-09-17 06:11:06 +00:00
float texvec[3], dxt[3], dyt[3], tempvec[3], norvec[3], warpvec[3]={0.0f, 0.0f, 0.0f}, Tnor=1.0;
Sneak in little feature for texture editing pleasure; - 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).
2004-12-07 17:46:14 +00:00
int tex_nr, rgbnor= 0, warpdone=0;
imagewrap was using uninitialized vars from do_material_tex found while looking into a different bug.
2009-09-24 12:27:20 +00:00
float nu[3] = {0,0,0}, nv[3] = {0,0,0}, nn[3] = {0,0,0}, dudnu = 1.f, dudnv = 0.f, dvdnu = 0.f, dvdnv = 1.f; // bump mapping
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
int nunvdone= 0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Small plumiferos wishlist item. Adds a button next to the threads button to disable texture processing in a render. If anyone doesn't like the button feel free to revert this one, its pretty simple. Kent
2006-12-07 16:48:15 +00:00
if (R.r.scemode & R_NO_TEX) return;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* here: test flag if there's a tex (todo) */
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
Special bf-committers request; Lamp/World/Material now each have 10 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!)
2004-12-04 21:49:02 +00:00
for(tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* separate tex switching */
if(shi->mat->septex & (1<<tex_nr)) continue;
if(shi->mat->mtex[tex_nr]) {
mtex= shi->mat->mtex[tex_nr];
tex= mtex->tex;
if(tex==0) continue;
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 22:09:57 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* which coords */
if(mtex->texco==TEXCO_ORCO) {
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 14:40:25 +00:00
if(mtex->texflag & MTEX_DUPLI_MAPTO) {
co= shi->duplilo; dx= dxt; dy= dyt;
dxt[0]= dxt[1]= dxt[2]= 0.0f;
dyt[0]= dyt[1]= dyt[2]= 0.0f;
}
else {
co= shi->lo; dx= shi->dxlo; dy= shi->dylo;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->texco==TEXCO_STICKY) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
co= shi->sticky; dx= shi->dxsticky; dy= shi->dysticky;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->texco==TEXCO_OBJECT) {
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
Object *ob= mtex->object;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(ob) {
co= tempvec;
dx= dxt;
dy= dyt;
VECCOPY(tempvec, shi->co);
Fix for bug #8463: object texture mapping for duplis was changed to act as if the object was in its original position, instead of being different for all instances. However, this is desired behavior in some cases and so breaks compatibility. Now it only does the new behavior when enabling the "From Original" option.
2008-04-12 18:44:03 +00:00
if(mtex->texflag & MTEX_OB_DUPLI_ORIG)
if(shi->obi && shi->obi->duplitexmat)
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(shi->obi->duplitexmat, tempvec);
Mat4MulVecfl(ob->imat, tempvec);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(shi->osatex) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
VECCOPY(dxt, shi->dxco);
VECCOPY(dyt, shi->dyco);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4Mul3Vecfl(ob->imat, dxt);
Mat4Mul3Vecfl(ob->imat, dyt);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
else {
/* if object doesn't exist, do not use orcos (not initialized) */
co= shi->co;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
dx= shi->dxco; dy= shi->dyco;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
else if(mtex->texco==TEXCO_REFL) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
co= shi->ref; dx= shi->dxref; dy= shi->dyref;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->texco==TEXCO_NORM) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
co= shi->orn; dx= shi->dxno; dy= shi->dyno;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Orange; WIP commit for inclusion of "Tangent" vector in rendering. This first implementation only supports it for Meshes with UV maps, and only tangents in V direction. Tangent diffuse: http://www.blender.org/bf/0001_0080.avi Tangent spec, diffuse, and bump: http://www.blender.org/bf/20001_0080.avi NOTE: since UV coordinates are still very badly subsurfed, this won't work well for subsurf meshes... on the todo. On the todo; - generate tangents for meshes without UV (with some options) - use tangents from Curve/Surface - add the Ashkimin shader from tracker ----- Important bugfix; curves didn't render anymore since yesterday. :)
2005-12-09 15:14:32 +00:00
else if(mtex->texco==TEXCO_TANGENT) {
co= shi->tang; dx= shi->dxno; dy= shi->dyno;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
else if(mtex->texco==TEXCO_GLOB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
co= shi->gl; dx= shi->dxco; dy= shi->dyco;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->texco==TEXCO_UV) {
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 14:40:25 +00:00
if(mtex->texflag & MTEX_DUPLI_MAPTO) {
co= shi->dupliuv; dx= dxt; dy= dyt;
dxt[0]= dxt[1]= dxt[2]= 0.0f;
dyt[0]= dyt[1]= dyt[2]= 0.0f;
}
else {
ShadeInputUV *suv= &shi->uv[shi->actuv];
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
int i = shi->actuv;
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 14:40:25 +00:00
if(mtex->uvname[0] != 0) {
for(i = 0; i < shi->totuv; i++) {
if(strcmp(shi->uv[i].name, mtex->uvname)==0) {
suv= &shi->uv[i];
break;
}
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
}
}
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 14:40:25 +00:00
co= suv->uv;
dx= suv->dxuv;
dy= suv->dyuv;
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
// uvmapping only, calculation of normal tangent u/v partial derivatives
// (should not be here, dudnu, dudnv, dvdnu & dvdnv should probably be part of ShadeInputUV struct,
// nu/nv in ShadeInput and this calculation should then move to shadeinput.c, shade_input_set_shade_texco() func.)
// NOTE: test for shi->obr->ob here, since vlr/obr/obi can be 'fake' when called from fastshade(), another reason to move it..
if ((mtex->texflag & MTEX_NEW_BUMP) && shi->obr && shi->obr->ob) {
if(mtex->mapto & (MAP_NORM|MAP_DISPLACE|MAP_WARP)) {
MTFace* tf = RE_vlakren_get_tface(shi->obr, shi->vlr, i, NULL, 0);
int j1 = shi->i1, j2 = shi->i2, j3 = shi->i3;
vlr_set_uv_indices(shi->vlr, &j1, &j2, &j3);
if (tf) {
float *uv1 = tf->uv[j1], *uv2 = tf->uv[j2], *uv3 = tf->uv[j3];
const float an[3] = {fabsf(nn[0]), fabsf(nn[1]), fabsf(nn[2])};
const int a1 = (an[0] > an[1] && an[0] > an[2]) ? 1 : 0;
const int a2 = (an[2] > an[0] && an[2] > an[1]) ? 1 : 2;
const float dp1_a1 = shi->v1->co[a1] - shi->v3->co[a1];
const float dp1_a2 = shi->v1->co[a2] - shi->v3->co[a2];
const float dp2_a1 = shi->v2->co[a1] - shi->v3->co[a1];
const float dp2_a2 = shi->v2->co[a2] - shi->v3->co[a2];
const float du1 = uv1[0] - uv3[0], du2 = uv2[0] - uv3[0];
const float dv1 = uv1[1] - uv3[1], dv2 = uv2[1] - uv3[1];
const float dpdu_a1 = dv2*dp1_a1 - dv1*dp2_a1;
const float dpdu_a2 = dv2*dp1_a2 - dv1*dp2_a2;
const float dpdv_a1 = du1*dp2_a1 - du2*dp1_a1;
const float dpdv_a2 = du1*dp2_a2 - du2*dp1_a2;
float d = dpdu_a1*dpdv_a2 - dpdv_a1*dpdu_a2;
float uvd = du1*dv2 - dv1*du2;
if (uvd == 0.f) uvd = 1e-5f;
if (d == 0.f) d = 1e-5f;
d = uvd / d;
dudnu = (dpdv_a2*nu[a1] - dpdv_a1*nu[a2])*d;
dvdnu = (dpdu_a1*nu[a2] - dpdu_a2*nu[a1])*d;
dudnv = (dpdv_a2*nv[a1] - dpdv_a1*nv[a2])*d;
dvdnv = (dpdu_a1*nv[a2] - dpdu_a2*nv[a1])*d;
}
}
}
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 14:40:25 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->texco==TEXCO_WINDOW) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
co= shi->winco; dx= shi->dxwin; dy= shi->dywin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
- Added "anisotropic" rendering for static particle hair strands. This means the diffuse and specular shaders don't use the normal for hair (which is actually undefined, a hair is micro cylinder) but it uses the tangent vector (vector in direction of hair). For Diffuse, it computes a fake normal now, representing the optimal hair normal pointing towards the light. All current builtin shaders work with this, including ramps. For Specular, it uses another formula to remap dot products for all lines that now use the tangent vector instead of the normal: dot = vector * tangent dot = sqrt(1.0 - dot*dot) Gives better results than using the 'fake' normal for diffuse. Officially (according the papers) this could be used for diffuse too, but then hair becomes very flat. Now you can control the flatness easily with ramps or using Oren-Nayer for example. Example image (disappears in some weeks) http://www.blender.org/bf/rt9.jpg - Added new texture channel "Strand" to apply textures on hairs over the length of hair (1 dimensional). Orco now gives 1 fixed coordinate for the entire hair, based on where it starts. Note; UV doesn't work yet. Nor vertexcolor. http://www.blender.org/bf/rt10.jpg
2005-09-29 13:19:07 +00:00
else if(mtex->texco==TEXCO_STRAND) {
co= tempvec; dx= dxt; dy= dyt;
Approximate Ambient Occlusion ============================= A new approximate ambient occlusion method has been added, next to the existing one based on raytracing. This method is specifically targetted at use in animations, since it is inherently noise free, and so will not flicker across frames. http://www.blender.org/development/current-projects/changes-since-244/approximate-ambient-occlusion/ http://peach.blender.org/index.php/approximate-ambient-occlusion/ Further improvements are still needed, but it can be tested already. There are still a number of known issues: - Bias errors on backfaces. - For performance, instanced object do not occlude currently. - Sky textures don't work well, the derivatives for texture evaluation are not correct. - Multiple passes do not work entirely correct (they are not accurate to begin with, but could be better).
2008-01-17 19:27:16 +00:00
co[0]= shi->strandco;
- Added "anisotropic" rendering for static particle hair strands. This means the diffuse and specular shaders don't use the normal for hair (which is actually undefined, a hair is micro cylinder) but it uses the tangent vector (vector in direction of hair). For Diffuse, it computes a fake normal now, representing the optimal hair normal pointing towards the light. All current builtin shaders work with this, including ramps. For Specular, it uses another formula to remap dot products for all lines that now use the tangent vector instead of the normal: dot = vector * tangent dot = sqrt(1.0 - dot*dot) Gives better results than using the 'fake' normal for diffuse. Officially (according the papers) this could be used for diffuse too, but then hair becomes very flat. Now you can control the flatness easily with ramps or using Oren-Nayer for example. Example image (disappears in some weeks) http://www.blender.org/bf/rt9.jpg - Added new texture channel "Strand" to apply textures on hairs over the length of hair (1 dimensional). Orco now gives 1 fixed coordinate for the entire hair, based on where it starts. Note; UV doesn't work yet. Nor vertexcolor. http://www.blender.org/bf/rt10.jpg
2005-09-29 13:19:07 +00:00
co[1]= co[2]= 0.0f;
dx[0]= shi->dxstrand;
dx[1]= dx[2]= 0.0f;
dy[0]= shi->dystrand;
dy[1]= dy[2]= 0.0f;
}
New feature: "Stress" texture input channel (As usual movies disappears after while) Face example showing stress values on a blend. White is stretch, black is squeeze http://www.blender.org/bf/0001_0014.avi Quick test with softbody stretch http://www.blender.org/bf/0001_0100.avi Based on the difference of the "Orco" (original undeformed coordinate) and the actual render coordinate, a stress value is computed to make textures react to stretching or wrinking skin. The texture coordinate is neutral (0) on relaxed state. -1 is squeezed to zero, +1 is stretched to infinity. Note that scaling (object itself or parent) also will result in stress values. The reason for the huge commit is a cleanup in allocating memory for the vertices. These were growing too large with new options, so now it allocates the optional coordinates dynamically. Saves about 20 MB memory per 1M vertices already. But best of all is that I now can add much more fun... so tangents, here we come!
2005-12-08 22:05:42 +00:00
else if(mtex->texco==TEXCO_STRESS) {
co= tempvec; dx= dxt; dy= dyt;
co[0]= shi->stress;
co[1]= co[2]= 0.0f;
dx[0]= 0.0f;
dx[1]= dx[2]= 0.0f;
dy[0]= 0.0f;
dy[1]= dy[2]= 0.0f;
}
Tweaked support for normalmaps to be OK. http://www.blender3d.org/cms/Normal_Mapping.491.0.html main changes: - The "Map Input" in Blender for normals was negated - Range for Z in normal map is Z (0-1) to Blue (0-255)
2004-12-06 18:05:42 +00:00
else continue; // can happen when texco defines disappear and it renders old files
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 22:09:57 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
/* the pointer defines if bumping happens */
Sneak in little feature for texture editing pleasure; - 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).
2004-12-07 17:46:14 +00:00
if(mtex->mapto & (MAP_NORM|MAP_DISPLACE|MAP_WARP)) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.nor= norvec;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
norvec[0]= norvec[1]= norvec[2]= 0.0;
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.nor= NULL;
Sneak in little feature for texture editing pleasure; - 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).
2004-12-07 17:46:14 +00:00
if(warpdone) {
VECADD(tempvec, co, warpvec);
co= tempvec;
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
if(mtex->texflag & MTEX_NEW_BUMP) {
// compute ortho basis around normal
if(!nunvdone) {
// render normal is negated
nn[0] = -shi->vn[0];
nn[1] = -shi->vn[1];
nn[2] = -shi->vn[2];
VecOrthoBasisf(nn, nu, nv);
nunvdone= 1;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
if(texres.nor) {
TexResult ttexr = {0, 0, 0, 0, 0, texres.talpha, NULL}; // temp TexResult
float tco[3], texv[3], cd, ud, vd, du, dv, idu, idv;
const int fromrgb = ((tex->type == TEX_IMAGE) || ((tex->flag & TEX_COLORBAND)!=0));
const float bf = 0.04f*Tnor*((mtex->maptoneg & MAP_NORM) ? -mtex->norfac : mtex->norfac);
// disable internal bump eval
float* nvec = texres.nor;
texres.nor = NULL;
// du & dv estimates, constant value defaults
du = dv = 0.01f;
// two methods, either constant based on main image resolution,
// (which also works without osa, though of course not always good (or even very bad) results),
// or based on tex derivative max values (osa only). Not sure which is best...
if (!shi->osatex && (tex->type == TEX_IMAGE) && tex->ima) {
// in case we have no proper derivatives, fall back to
// computing du/dv it based on image size
ImBuf* ibuf = BKE_image_get_ibuf(tex->ima, &tex->iuser);
if (ibuf) {
du = 1.f/(float)ibuf->x;
dv = 1.f/(float)ibuf->y;
}
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
}
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
else if (shi->osatex) {
// we have derivatives, can compute proper du/dv
if (tex->type == TEX_IMAGE) { // 2d image, use u & v max. of dx/dy 2d vecs
const float adx[2] = {fabsf(dx[0]), fabsf(dx[1])};
const float ady[2] = {fabsf(dy[0]), fabsf(dy[1])};
du = MAX2(adx[0], ady[0]);
dv = MAX2(adx[1], ady[1]);
}
else { // 3d procedural, estimate from all dx/dy elems
const float adx[3] = {fabsf(dx[0]), fabsf(dx[1]), fabsf(dx[2])};
const float ady[3] = {fabsf(dy[0]), fabsf(dy[1]), fabsf(dy[2])};
du = MAX3(adx[0], adx[1], adx[2]);
dv = MAX3(ady[1], ady[1], ady[2]);
}
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
// center, main return value
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
rgbnor = multitex(tex, texvec, dxt, dyt, shi->osatex, &texres, shi->thread, mtex->which_output);
cd = fromrgb ? (texres.tr + texres.tg + texres.tb)*0.33333333f : texres.tin;
if (mtex->texco == TEXCO_UV) {
// for the uv case, use the same value for both du/dv,
// since individually scaling the normal derivatives makes them useless...
du = MIN2(du, dv);
idu = (du < 1e-6f) ? bf : (bf/du);
// +u val
tco[0] = co[0] + dudnu*du;
tco[1] = co[1] + dvdnu*du;
tco[2] = 0.f;
texco_mapping(shi, tex, mtex, tco, dx, dy, texv, dxt, dyt);
multitex(tex, texv, dxt, dyt, shi->osatex, &ttexr, shi->thread, mtex->which_output);
ud = idu*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb)*0.33333333f : ttexr.tin));
// +v val
tco[0] = co[0] + dudnv*du;
tco[1] = co[1] + dvdnv*du;
tco[2] = 0.f;
texco_mapping(shi, tex, mtex, tco, dx, dy, texv, dxt, dyt);
multitex(tex, texv, dxt, dyt, shi->osatex, &ttexr, shi->thread, mtex->which_output);
vd = idu*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb)*0.33333333f : ttexr.tin));
}
else {
float tu[3] = {nu[0], nu[1], nu[2]}, tv[3] = {nv[0], nv[1], nv[2]};
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
idu = (du < 1e-6f) ? bf : (bf/du);
idv = (dv < 1e-6f) ? bf : (bf/dv);
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
if ((mtex->texco == TEXCO_ORCO) && shi->obr && shi->obr->ob) {
Mat4Mul3Vecfl(shi->obr->ob->imat, tu);
Mat4Mul3Vecfl(shi->obr->ob->imat, tv);
Normalize(tu);
Normalize(tv);
}
else if (mtex->texco == TEXCO_GLOB) {
Mat4Mul3Vecfl(R.viewinv, tu);
Mat4Mul3Vecfl(R.viewinv, tv);
}
else if (mtex->texco == TEXCO_OBJECT && mtex->object) {
Mat4Mul3Vecfl(mtex->object->imat, tu);
Mat4Mul3Vecfl(mtex->object->imat, tv);
Normalize(tu);
Normalize(tv);
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
// +u val
tco[0] = co[0] + tu[0]*du;
tco[1] = co[1] + tu[1]*du;
tco[2] = co[2] + tu[2]*du;
texco_mapping(shi, tex, mtex, tco, dx, dy, texv, dxt, dyt);
multitex(tex, texv, dxt, dyt, shi->osatex, &ttexr, shi->thread, mtex->which_output);
ud = idu*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb)*0.33333333f : ttexr.tin));
// +v val
tco[0] = co[0] + tv[0]*dv;
tco[1] = co[1] + tv[1]*dv;
tco[2] = co[2] + tv[2]*dv;
texco_mapping(shi, tex, mtex, tco, dx, dy, texv, dxt, dyt);
multitex(tex, texv, dxt, dyt, shi->osatex, &ttexr, shi->thread, mtex->which_output);
vd = idv*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb)*0.33333333f : ttexr.tin));
Bug #3681 The never ending bump mapping saga! With the fix over a month ago, which added correct texture space vectors for the bump, gave results so crispy that normals could invert after normalize. This only when the normal "fac" slider was > 1.0. The normals from imagetextures now get clipped to prevent it to result in flipping normals. Will do more tests though... Also note that the real good way would be have the tangent vectors for the actual render normal available to perturb for bump, thats another story.
2006-01-03 19:49:38 +00:00
}
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
// bumped normal
nu[0] += ud*nn[0];
nu[1] += ud*nn[1];
nu[2] += ud*nn[2];
nv[0] += vd*nn[0];
nv[1] += vd*nn[1];
nv[2] += vd*nn[2];
Crossf(nvec, nu, nv);
nvec[0] = -nvec[0];
nvec[1] = -nvec[1];
nvec[2] = -nvec[2];
texres.nor = nvec;
rgbnor |= TEX_NOR;
}
else {
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
rgbnor = multitex(tex, texvec, dxt, dyt, shi->osatex, &texres, shi->thread, mtex->which_output);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
else {
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
rgbnor = multitex(tex, texvec, dxt, dyt, shi->osatex, &texres, shi->thread, mtex->which_output);
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* texture output */
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if( (rgbnor & TEX_RGB) && (mtex->texflag & MTEX_RGBTOINT)) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
rgbnor-= TEX_RGB;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->texflag & MTEX_NEGATIVE) {
if(rgbnor & TEX_RGB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= 1.0-texres.tr;
texres.tg= 1.0-texres.tg;
texres.tb= 1.0-texres.tb;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= 1.0-texres.tin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->texflag & MTEX_STENCIL) {
if(rgbnor & TEX_RGB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.ta;
texres.ta*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
stencilTin*= fact;
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.tin;
texres.tin*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
stencilTin*= fact;
}
}
else {
Tnor*= stencilTin;
}
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres.nor) {
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
if((rgbnor & TEX_NOR)==0) {
/* make our own normal */
if(rgbnor & TEX_RGB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.nor[0]= texres.tr;
texres.nor[1]= texres.tg;
texres.nor[2]= texres.tb;
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
}
else {
resolve some compiler warnings with intel c/c++ compiler * subsurf code had a lot of unused variables, removed these where they are obviously not needed. commented if they could be useful later. * some variables declorations hide existing variables (many of these left), but fixed some that could cause confusion. * removed unused vars * obscure python memory leak with colorband. * make_sample_tables had a loop running wasnt used. * if 0'd functions in arithb.c that are not used yet. * made many functions static
2008-09-29 17:08:11 +00:00
float co_nor= 0.5*cos(texres.tin-0.5);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
float si= 0.5*sin(texres.tin-0.5);
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
float f1, f2;
f1= shi->vn[0];
f2= shi->vn[1];
resolve some compiler warnings with intel c/c++ compiler * subsurf code had a lot of unused variables, removed these where they are obviously not needed. commented if they could be useful later. * some variables declorations hide existing variables (many of these left), but fixed some that could cause confusion. * removed unused vars * obscure python memory leak with colorband. * make_sample_tables had a loop running wasnt used. * if 0'd functions in arithb.c that are not used yet. * made many functions static
2008-09-29 17:08:11 +00:00
texres.nor[0]= f1*co_nor+f2*si;
texres.nor[1]= f2*co_nor-f1*si;
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
f1= shi->vn[1];
f2= shi->vn[2];
resolve some compiler warnings with intel c/c++ compiler * subsurf code had a lot of unused variables, removed these where they are obviously not needed. commented if they could be useful later. * some variables declorations hide existing variables (many of these left), but fixed some that could cause confusion. * removed unused vars * obscure python memory leak with colorband. * make_sample_tables had a loop running wasnt used. * if 0'd functions in arithb.c that are not used yet. * made many functions static
2008-09-29 17:08:11 +00:00
texres.nor[1]= f1*co_nor+f2*si;
texres.nor[2]= f2*co_nor-f1*si;
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Sneak in little feature for texture editing pleasure; - 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).
2004-12-07 17:46:14 +00:00
// warping, local space
if(mtex->mapto & MAP_WARP) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
warpvec[0]= mtex->warpfac*texres.nor[0];
warpvec[1]= mtex->warpfac*texres.nor[1];
warpvec[2]= mtex->warpfac*texres.nor[2];
Sneak in little feature for texture editing pleasure; - 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).
2004-12-07 17:46:14 +00:00
warpdone= 1;
}
Bugfix #2841 Ancient issue with Image bumpmap & orientation... this report was about UV textures, which flipped bump direction when UV coordinates rotate. So... time to dive deeper into it, and I found a very bad old construction in the way image textures handled bump normals. Instead of using the correct dx,dy vectors it was calculating the boundbox for it, and applied it as such (loosing negative direction for the dx or dy that way). Anyhoo! To make a long story short; the weird "correct Nor Map" option now can be removed... but requires careful testing! Here's renders from file I got from env, 239 means old and 240 is this cvs. http://www.blender.org/bf/dino239.jpg http://www.blender.org/bf/dino240.jpg http://www.blender.org/bf/dino239a.jpg http://www.blender.org/bf/dino240a.jpg Note the much finer detail, and the more consistant normals direction. No, go render testing dudes!
2005-11-21 22:47:23 +00:00
#if 0
Bug fix #2323 The addition in 2.36 to correct bumpmapping for View and Object rotation, made many nice bumpmap setups in older files less nice. Especially apparent when you apply "flipped" mappings in "Map Input" Panel, like map the X to Z and the Z to X. A correction then gives wrong results. Since the "correct bumpmapping" is actually a new option, causing extra rendertime too, I've made it an option now. With the "Map To" Panel being fully used, I've put the new button option (temporally I hope) in the first "Texture" Panel in material context. Will be updated in release log page!
2005-04-12 11:45:06 +00:00
if(mtex->texflag & MTEX_VIEWSPACE) {
// rotate to global coords
if(mtex->texco==TEXCO_ORCO || mtex->texco==TEXCO_UV) {
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
if(shi->vlr && shi->obr && shi->obr->ob) {
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 13:18:41 +00:00
float len= Normalize(texres.nor);
Bug fix #2292 Bumpmaps for skin on Env's dinosaurs appeared to be less nice in 2.36. This was caused by the bugfix to make bumpmapping correct for rotations, which should only work for flat/cube mapping. It also rotated it for sphere/tube though, which gives less interesting bumps. So; now the correction is skipped for tube/sphere mapping bumping.
2005-03-07 12:41:23 +00:00
// can be optimized... (ton)
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
Mat4Mul3Vecfl(shi->obr->ob->obmat, texres.nor);
Bug fix #2292 Bumpmaps for skin on Env's dinosaurs appeared to be less nice in 2.36. This was caused by the bugfix to make bumpmapping correct for rotations, which should only work for flat/cube mapping. It also rotated it for sphere/tube though, which gives less interesting bumps. So; now the correction is skipped for tube/sphere mapping bumping.
2005-03-07 12:41:23 +00:00
Mat4Mul3Vecfl(R.viewmat, texres.nor);
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 13:18:41 +00:00
Normalize(texres.nor);
Bug fix #2292 Bumpmaps for skin on Env's dinosaurs appeared to be less nice in 2.36. This was caused by the bugfix to make bumpmapping correct for rotations, which should only work for flat/cube mapping. It also rotated it for sphere/tube though, which gives less interesting bumps. So; now the correction is skipped for tube/sphere mapping bumping.
2005-03-07 12:41:23 +00:00
VecMulf(texres.nor, len);
}
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Bugfix #2841 Ancient issue with Image bumpmap & orientation... this report was about UV textures, which flipped bump direction when UV coordinates rotate. So... time to dive deeper into it, and I found a very bad old construction in the way image textures handled bump normals. Instead of using the correct dx,dy vectors it was calculating the boundbox for it, and applied it as such (loosing negative direction for the dx or dy that way). Anyhoo! To make a long story short; the weird "correct Nor Map" option now can be removed... but requires careful testing! Here's renders from file I got from env, 239 means old and 240 is this cvs. http://www.blender.org/bf/dino239.jpg http://www.blender.org/bf/dino240.jpg http://www.blender.org/bf/dino239a.jpg http://www.blender.org/bf/dino240a.jpg Note the much finer detail, and the more consistant normals direction. No, go render testing dudes!
2005-11-21 22:47:23 +00:00
#endif
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* mapping */
if(mtex->mapto & (MAP_COL+MAP_COLSPEC+MAP_COLMIR)) {
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
float tcol[3], colfac;
/* stencil maps on the texture control slider, not texture intensity value */
colfac= mtex->colfac*stencilTin;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tcol[0]=texres.tr; tcol[1]=texres.tg; tcol[2]=texres.tb;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if((rgbnor & TEX_RGB)==0) {
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
tcol[0]= mtex->r;
tcol[1]= mtex->g;
tcol[2]= mtex->b;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->mapto & MAP_ALPHA) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= texres.ta;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
Colour Management - 1st stage: Linear Workflow This implements automatic linear workflow in Blender's renderer. With the new Colour Management option on in the Render buttons, all inputs to the renderer and compositor are converted to linear colour space before rendering, and gamma corrected afterwards. In essence, this makes all manual gamma correction with nodes, etc unnecessary, since it's done automatically through the pipeline. It's all explained much better in the notes/doc here, so please have a look: http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management And an example of the sort of difference it makes: http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg This also enables Colour Management in the default B.blend, and changes the default lamp falloff to inverse square, which is more correct, and much easier to use now it's all gamma corrected properly. Next step is to look into profiles/soft proofing for the compositor. Thanks to brecht for reviewing and fixing some oversights!
2009-07-17 02:43:15 +00:00
/* inverse gamma correction */
if (R.r.color_mgt_flag & R_COLOR_MANAGEMENT) {
color_manage_linearize(tcol, tcol);
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->mapto & MAP_COL) {
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
texture_rgb_blend(&shi->r, tcol, &shi->r, texres.tin, colfac, mtex->blendtype);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_COLSPEC) {
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
texture_rgb_blend(&shi->specr, tcol, &shi->specr, texres.tin, colfac, mtex->blendtype);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_COLMIR) {
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
// exception for envmap only
if(tex->type==TEX_ENVMAP && mtex->blendtype==MTEX_BLEND) {
Bugfix #4564 Environment mapping on channel "Mirror color" didn't support stencilling.
2006-07-02 10:42:29 +00:00
fact= texres.tin*colfac;
Fixed rendering of image textures with alpha... it gave ugly dark outlines. Please note the following: - pictures need to be saved as 'premul' sky render if you want to use it in Blender as texture - but for alpha-over in sequencer it has to be 'key alpha'... This inconsistancy needs to be solved.. for example as option for both texture as sequencer.
2004-07-02 20:49:08 +00:00
facm= 1.0- fact;
shi->refcol[0]= fact + facm*shi->refcol[0];
shi->refcol[1]= fact*tcol[0] + facm*shi->refcol[1];
shi->refcol[2]= fact*tcol[1] + facm*shi->refcol[2];
shi->refcol[3]= fact*tcol[2] + facm*shi->refcol[3];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else {
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
texture_rgb_blend(&shi->mirr, tcol, &shi->mirr, texres.tin, colfac, mtex->blendtype);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
if( (mtex->mapto & MAP_NORM) ) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres.nor) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->maptoneg & MAP_NORM) tex->norfac= -mtex->norfac;
else tex->norfac= mtex->norfac;
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
/* we need to code blending modes for normals too once.. now 1 exception hardcoded */
New stuff! - Tangent vectors now can also be derived from orcos (No UV needed) - Normalmaps now properly support tangent space as well (Patch provided by Alfredo de Greef) Full log is here: http://www.blender3d.org/cms/New_Render_features.774.0.html
2006-09-05 13:28:59 +00:00
if ((tex->type==TEX_IMAGE) && (tex->imaflag & TEX_NORMALMAP)) {
/* qdn: for normalmaps, to invert the normalmap vector,
it is better to negate x & y instead of subtracting the vector as was done before */
tex->norfac = mtex->norfac;
if (mtex->maptoneg & MAP_NORM) {
texres.nor[0] = -texres.nor[0];
texres.nor[1] = -texres.nor[1];
}
fact = Tnor*tex->norfac;
if (fact>1.f) fact = 1.f;
facm = 1.f-fact;
Render Baking ============= A new "Selected to Active" option in the Bake panel, to (typically) bake a high poly object onto a low poly object. Code based on patch #7339 by Frank Richter (Crystal Space developer), thanks!. Normal Mapping ============== Camera, World, Object and Tangent space is now supported for baking, and for material textures. The "NMap TS" setting is replaced with a dropdown of the four choices in the image texture buttons. http://www.blender.org/development/current-projects/changes-since-244/render-baking/
2007-11-28 22:21:12 +00:00
if(mtex->normapspace == MTEX_NSPACE_TANGENT) {
New stuff! - Tangent vectors now can also be derived from orcos (No UV needed) - Normalmaps now properly support tangent space as well (Patch provided by Alfredo de Greef) Full log is here: http://www.blender3d.org/cms/New_Render_features.774.0.html
2006-09-05 13:28:59 +00:00
/* qdn: tangent space */
float B[3], tv[3];
Normal map tangents are now not always averaged at vertices anymore, but only when the UV's are connected. That fixes some artifacts when baking and using tangent space normal maps. It does mean increased memory usage because it now stores 4 tangents per face like UV's, and increased processing time, but there's no simple way around that.
2008-03-07 15:38:56 +00:00
Crossf(B, shi->vn, shi->nmaptang); /* bitangent */
New stuff! - Tangent vectors now can also be derived from orcos (No UV needed) - Normalmaps now properly support tangent space as well (Patch provided by Alfredo de Greef) Full log is here: http://www.blender3d.org/cms/New_Render_features.774.0.html
2006-09-05 13:28:59 +00:00
/* transform norvec from tangent space to object surface in camera space */
Normal map tangents are now not always averaged at vertices anymore, but only when the UV's are connected. That fixes some artifacts when baking and using tangent space normal maps. It does mean increased memory usage because it now stores 4 tangents per face like UV's, and increased processing time, but there's no simple way around that.
2008-03-07 15:38:56 +00:00
tv[0] = texres.nor[0]*shi->nmaptang[0] + texres.nor[1]*B[0] + texres.nor[2]*shi->vn[0];
tv[1] = texres.nor[0]*shi->nmaptang[1] + texres.nor[1]*B[1] + texres.nor[2]*shi->vn[1];
tv[2] = texres.nor[0]*shi->nmaptang[2] + texres.nor[1]*B[2] + texres.nor[2]*shi->vn[2];
New stuff! - Tangent vectors now can also be derived from orcos (No UV needed) - Normalmaps now properly support tangent space as well (Patch provided by Alfredo de Greef) Full log is here: http://www.blender3d.org/cms/New_Render_features.774.0.html
2006-09-05 13:28:59 +00:00
shi->vn[0]= facm*shi->vn[0] + fact*tv[0];
shi->vn[1]= facm*shi->vn[1] + fact*tv[1];
shi->vn[2]= facm*shi->vn[2] + fact*tv[2];
Orange; WIP commit for inclusion of "Tangent" vector in rendering. This first implementation only supports it for Meshes with UV maps, and only tangents in V direction. Tangent diffuse: http://www.blender.org/bf/0001_0080.avi Tangent spec, diffuse, and bump: http://www.blender.org/bf/20001_0080.avi NOTE: since UV coordinates are still very badly subsurfed, this won't work well for subsurf meshes... on the todo. On the todo; - generate tangents for meshes without UV (with some options) - use tangents from Curve/Surface - add the Ashkimin shader from tracker ----- Important bugfix; curves didn't render anymore since yesterday. :)
2005-12-09 15:14:32 +00:00
}
else {
Render Baking ============= A new "Selected to Active" option in the Bake panel, to (typically) bake a high poly object onto a low poly object. Code based on patch #7339 by Frank Richter (Crystal Space developer), thanks!. Normal Mapping ============== Camera, World, Object and Tangent space is now supported for baking, and for material textures. The "NMap TS" setting is replaced with a dropdown of the four choices in the image texture buttons. http://www.blender.org/development/current-projects/changes-since-244/render-baking/
2007-11-28 22:21:12 +00:00
float nor[3];
VECCOPY(nor, texres.nor);
if(mtex->normapspace == MTEX_NSPACE_CAMERA);
else if(mtex->normapspace == MTEX_NSPACE_WORLD) {
Mat4Mul3Vecfl(R.viewmat, nor);
}
else if(mtex->normapspace == MTEX_NSPACE_OBJECT) {
Fix for error in approximate AO in last commit, made it really slow. Also, duplis are now taking into account, the proper way to exclude them is to set the material to be not traceable. Removed an unnecessary pointer from the VlakRen struct to save some memory, not really that significant, but still, saves 70 mb for 10 million faces.
2008-01-21 23:17:19 +00:00
if(shi->obr && shi->obr->ob)
Mat4Mul3Vecfl(shi->obr->ob->obmat, nor);
Render Baking ============= A new "Selected to Active" option in the Bake panel, to (typically) bake a high poly object onto a low poly object. Code based on patch #7339 by Frank Richter (Crystal Space developer), thanks!. Normal Mapping ============== Camera, World, Object and Tangent space is now supported for baking, and for material textures. The "NMap TS" setting is replaced with a dropdown of the four choices in the image texture buttons. http://www.blender.org/development/current-projects/changes-since-244/render-baking/
2007-11-28 22:21:12 +00:00
Mat4Mul3Vecfl(R.viewmat, nor);
}
Normalize(nor);
New stuff! - Tangent vectors now can also be derived from orcos (No UV needed) - Normalmaps now properly support tangent space as well (Patch provided by Alfredo de Greef) Full log is here: http://www.blender3d.org/cms/New_Render_features.774.0.html
2006-09-05 13:28:59 +00:00
/* qdn: worldspace */
Render Baking ============= A new "Selected to Active" option in the Bake panel, to (typically) bake a high poly object onto a low poly object. Code based on patch #7339 by Frank Richter (Crystal Space developer), thanks!. Normal Mapping ============== Camera, World, Object and Tangent space is now supported for baking, and for material textures. The "NMap TS" setting is replaced with a dropdown of the four choices in the image texture buttons. http://www.blender.org/development/current-projects/changes-since-244/render-baking/
2007-11-28 22:21:12 +00:00
shi->vn[0]= facm*shi->vn[0] + fact*nor[0];
shi->vn[1]= facm*shi->vn[1] + fact*nor[1];
shi->vn[2]= facm*shi->vn[2] + fact*nor[2];
Orange; WIP commit for inclusion of "Tangent" vector in rendering. This first implementation only supports it for Meshes with UV maps, and only tangents in V direction. Tangent diffuse: http://www.blender.org/bf/0001_0080.avi Tangent spec, diffuse, and bump: http://www.blender.org/bf/20001_0080.avi NOTE: since UV coordinates are still very badly subsurfed, this won't work well for subsurf meshes... on the todo. On the todo; - generate tangents for meshes without UV (with some options) - use tangents from Curve/Surface - add the Ashkimin shader from tracker ----- Important bugfix; curves didn't render anymore since yesterday. :)
2005-12-09 15:14:32 +00:00
}
Bugfix: normal mapping for textures wasn't rotated back to view space, 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.
2004-12-05 21:49:13 +00:00
}
else {
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
if (mtex->texflag & MTEX_NEW_BUMP) {
shi->vn[0] = texres.nor[0];
shi->vn[1] = texres.nor[1];
shi->vn[2] = texres.nor[2];
Orange; WIP commit for inclusion of "Tangent" vector in rendering. This first implementation only supports it for Meshes with UV maps, and only tangents in V direction. Tangent diffuse: http://www.blender.org/bf/0001_0080.avi Tangent spec, diffuse, and bump: http://www.blender.org/bf/20001_0080.avi NOTE: since UV coordinates are still very badly subsurfed, this won't work well for subsurf meshes... on the todo. On the todo; - generate tangents for meshes without UV (with some options) - use tangents from Curve/Surface - add the Ashkimin shader from tracker ----- Important bugfix; curves didn't render anymore since yesterday. :)
2005-12-09 15:14:32 +00:00
}
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
else {
float nor[3], dot;
if(shi->mat->mode & MA_TANGENT_V) {
shi->tang[0]+= Tnor*tex->norfac*texres.nor[0];
shi->tang[1]+= Tnor*tex->norfac*texres.nor[1];
shi->tang[2]+= Tnor*tex->norfac*texres.nor[2];
}
/* prevent bump to become negative normal */
nor[0]= Tnor*tex->norfac*texres.nor[0];
nor[1]= Tnor*tex->norfac*texres.nor[1];
nor[2]= Tnor*tex->norfac*texres.nor[2];
dot= 0.5f + 0.5f*INPR(nor, shi->vn);
shi->vn[0]+= dot*nor[0];
shi->vn[1]+= dot*nor[1];
shi->vn[2]+= dot*nor[2];
}
}
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 13:18:41 +00:00
Normalize(shi->vn);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* this makes sure the bump is passed on to the next texture */
Tweaked support for normalmaps to be OK. http://www.blender3d.org/cms/Normal_Mapping.491.0.html main changes: - The "Map Input" in Blender for normals was negated - Range for Z in normal map is Z (0-1) to Blue (0-255)
2004-12-06 18:05:42 +00:00
shi->orn[0]= -shi->vn[0];
shi->orn[1]= -shi->vn[1];
shi->orn[2]= -shi->vn[2];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* reflection vector */
calc_R_ref(shi);
}
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Displacement map - changed code to make use of actual textures, not the hackish 'externtex', which is only for tools - added a 'displacement' vector in ShadeInput, and moved calculation of displacement vector to texture.c itself. So it works with stencil, but also for options as 'add', 'mult' and 'sub'. - for RGB textures it uses the brightness value of color for displace - for stucci, and plugin textures returning a normal, it uses that - Also: wrote call in end of preparing renderfaces, to split non-flat quad faces in triangles. gives a lot fewer errors in displace textures, but also raytracing irregular subsurfs goes better now. - texture mapping that works for displace: orco, sticky, global, obj, normal. UV not yet. Reflection-displace? uhh! :)
2004-01-05 20:25:07 +00:00
if( mtex->mapto & MAP_DISPLACE ) {
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
/* Now that most textures offer both Nor and Intensity, allow */
- Better fake for displace preview.
2004-01-11 00:39:17 +00:00
/* both to work, and let user select with slider. */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres.nor) {
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
if(mtex->maptoneg & MAP_DISPLACE) tex->norfac= -mtex->norfac;
else tex->norfac= mtex->norfac;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
shi->displace[0]+= 0.2f*Tnor*tex->norfac*texres.nor[0];
shi->displace[1]+= 0.2f*Tnor*tex->norfac*texres.nor[1];
shi->displace[2]+= 0.2f*Tnor*tex->norfac*texres.nor[2];
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
}
if(rgbnor & TEX_RGB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres.talpha) texres.tin= texres.ta;
This is the famous proverbal example of someone trying to get a 4 legged table stable... you keep correcting leg sizes until no table is left anymore! :) This commit restores the displacement direction from 2.37a code, which was negated 5 months ago to fix a change in renderconverter.c, but somehow is not needed anymore. The regression displacement file now renders OK again.
2005-11-11 10:14:27 +00:00
else texres.tin= (0.35f*texres.tr+0.45f*texres.tg+0.2f*texres.tb);
Displacement map - changed code to make use of actual textures, not the hackish 'externtex', which is only for tools - added a 'displacement' vector in ShadeInput, and moved calculation of displacement vector to texture.c itself. So it works with stencil, but also for options as 'add', 'mult' and 'sub'. - for RGB textures it uses the brightness value of color for displace - for stucci, and plugin textures returning a normal, it uses that - Also: wrote call in end of preparing renderfaces, to split non-flat quad faces in triangles. gives a lot fewer errors in displace textures, but also raytracing irregular subsurfs goes better now. - texture mapping that works for displace: orco, sticky, global, obj, normal. UV not yet. Reflection-displace? uhh! :)
2004-01-05 20:25:07 +00:00
}
- displacement 'map to' channel now has three values, to allow to negate the effect as well.
2004-01-05 23:33:22 +00:00
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
if(mtex->maptoneg & MAP_DISPLACE) {
Displacement didn't react correct for stencilling. Our confusing system has both geometry-normal displace as texture-normal displace. The first didn't get stencilled.
2006-06-25 16:54:06 +00:00
factt= (texres.tin-0.5f)*mtex->dispfac*stencilTin; facmm= 1.0f-factt;
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
}
else {
Displacement didn't react correct for stencilling. Our confusing system has both geometry-normal displace as texture-normal displace. The first didn't get stencilled.
2006-06-25 16:54:06 +00:00
factt= (0.5f-texres.tin)*mtex->dispfac*stencilTin; facmm= 1.0f-factt;
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
- Displacement now allows use of either Var or Nor slider. Nor uses texture's Nor channel, Var uses intensity channel.
2004-01-10 23:00:52 +00:00
if(mtex->blendtype==MTEX_BLEND) {
shi->displace[0]= factt*shi->vn[0] + facmm*shi->displace[0];
shi->displace[1]= factt*shi->vn[1] + facmm*shi->displace[1];
shi->displace[2]= factt*shi->vn[2] + facmm*shi->displace[2];
}
else if(mtex->blendtype==MTEX_MUL) {
shi->displace[0]*= factt*shi->vn[0];
shi->displace[1]*= factt*shi->vn[1];
shi->displace[2]*= factt*shi->vn[2];
}
else { /* add or sub */
if(mtex->blendtype==MTEX_SUB) factt= -factt;
else factt= factt;
shi->displace[0]+= factt*shi->vn[0];
shi->displace[1]+= factt*shi->vn[1];
shi->displace[2]+= factt*shi->vn[2];
Displacement map - changed code to make use of actual textures, not the hackish 'externtex', which is only for tools - added a 'displacement' vector in ShadeInput, and moved calculation of displacement vector to texture.c itself. So it works with stencil, but also for options as 'add', 'mult' and 'sub'. - for RGB textures it uses the brightness value of color for displace - for stucci, and plugin textures returning a normal, it uses that - Also: wrote call in end of preparing renderfaces, to split non-flat quad faces in triangles. gives a lot fewer errors in displace textures, but also raytracing irregular subsurfs goes better now. - texture mapping that works for displace: orco, sticky, global, obj, normal. UV not yet. Reflection-displace? uhh! :)
2004-01-05 20:25:07 +00:00
}
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->mapto & MAP_VARS) {
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
/* stencil maps on the texture control slider, not texture intensity value */
float varfac= mtex->varfac*stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(rgbnor & TEX_RGB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres.talpha) texres.tin= texres.ta;
else texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->mapto & MAP_REF) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_REF;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->refl= texture_value_blend(mtex->def_var, shi->refl, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->refl<0.0) shi->refl= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_SPEC) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_SPEC;
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->spec= texture_value_blend(mtex->def_var, shi->spec, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->spec<0.0) shi->spec= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_EMIT) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_EMIT;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->emit= texture_value_blend(mtex->def_var, shi->emit, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->emit<0.0) shi->emit= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_ALPHA) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_ALPHA;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->alpha= texture_value_blend(mtex->def_var, shi->alpha, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->alpha<0.0) shi->alpha= 0.0;
else if(shi->alpha>1.0) shi->alpha= 1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_HAR) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_HAR;
float har; // have to map to 0-1
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
har= ((float)shi->har)/128.0;
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
har= 128.0*texture_value_blend(mtex->def_var, har, texres.tin, varfac, mtex->blendtype, flip);
Three in one: - 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.
2004-07-03 14:18:21 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(har<1.0) shi->har= 1;
else if(har>511.0) shi->har= 511;
else shi->har= (int)har;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_RAYMIRR) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_RAYMIRR;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->ray_mirror= texture_value_blend(mtex->def_var, shi->ray_mirror, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->ray_mirror<0.0) shi->ray_mirror= 0.0;
else if(shi->ray_mirror>1.0) shi->ray_mirror= 1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & MAP_TRANSLU) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_TRANSLU;
Improved method to calculate normals for procedural textures such as Marble, wood, clouds. Instead of the retarded (but faster :) old method it now derives the normal based on displacement of a 'nabla' vector; sampling the texture additionally with three little offsets in x, y and z. Code provided by Eeshlo, and gratefully accepted!
2004-01-10 12:41:47 +00:00
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->translucency= texture_value_blend(mtex->def_var, shi->translucency, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->translucency<0.0) shi->translucency= 0.0;
else if(shi->translucency>1.0) shi->translucency= 1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Orange branch feature; Material Layering (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!
2005-12-04 14:32:21 +00:00
if(mtex->mapto & MAP_LAYER) {
int flip= mtex->maptoneg & MAP_LAYER;
shi->layerfac= texture_value_blend(mtex->def_var, shi->layerfac, texres.tin, varfac, mtex->blendtype, flip);
if(shi->layerfac<0.0) shi->layerfac= 0.0;
else if(shi->layerfac>1.0) shi->layerfac= 1.0;
}
Added Ambient channel in "Map To" Panel for materials. Is now means to control AO and Radio with texture too.
2004-04-26 16:49:05 +00:00
if(mtex->mapto & MAP_AMB) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
int flip= mtex->maptoneg & MAP_AMB;
Added Ambient channel in "Map To" Panel for materials. Is now means to control AO and Radio with texture too.
2004-04-26 16:49:05 +00:00
Bugfix #3163 Materials; using "Stencil" option, didn't work properly for multiply, and other related filters. This is a very old issue, but now I found the good way to fix it! :)
2005-10-11 20:47:45 +00:00
shi->amb= texture_value_blend(mtex->def_var, shi->amb, texres.tin, varfac, mtex->blendtype, flip);
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(shi->amb<0.0) shi->amb= 0.0;
else if(shi->amb>1.0) shi->amb= 1.0;
2.50: svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD Notes: * Game and sequencer RNA, and sequencer header are now out of date a bit after changes in trunk. * I didn't know how to port these bugfixes, most likely they are not needed anymore. * Fix "duplicate strip" always increase the user count for ipo. * IPO pinning on sequencer strips was lost during Undo.
2009-06-08 20:08:19 +00:00
shi->ambr= shi->amb*R.wrld.ambr;
shi->ambg= shi->amb*R.wrld.ambg;
shi->ambb= shi->amb*R.wrld.ambb;
Added Ambient channel in "Map To" Panel for materials. Is now means to control AO and Radio with texture too.
2004-04-26 16:49:05 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
}
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
void do_volume_tex(ShadeInput *shi, float *xyz, int mapto_flag, float *col, float *val)
{
MTex *mtex;
Tex *tex;
TexResult texres= {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0, NULL};
int tex_nr, rgbnor= 0;
float co[3], texvec[3];
float fact, stencilTin=1.0;
if (R.r.scemode & R_NO_TEX) return;
/* here: test flag if there's a tex (todo) */
for(tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
/* separate tex switching */
if(shi->mat->septex & (1<<tex_nr)) continue;
if(shi->mat->mtex[tex_nr]) {
mtex= shi->mat->mtex[tex_nr];
tex= mtex->tex;
if(tex==0) continue;
/* only process if this texture is mapped
* to one that we're interested in */
if (!(mtex->mapto & mapto_flag)) continue;
/* which coords */
if(mtex->texco==TEXCO_OBJECT) {
Object *ob= mtex->object;
ob= mtex->object;
if(ob) {
VECCOPY(co, xyz);
if(mtex->texflag & MTEX_OB_DUPLI_ORIG) {
if(shi->obi && shi->obi->duplitexmat)
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(shi->obi->duplitexmat, co);
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
}
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(ob->imat, co);
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
}
}
/* not really orco, but 'local' */
else if(mtex->texco==TEXCO_ORCO) {
if(mtex->texflag & MTEX_DUPLI_MAPTO) {
VECCOPY(co, shi->duplilo);
}
else {
Object *ob= shi->obi->ob;
VECCOPY(co, xyz);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(ob->imat, co);
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
}
}
else if(mtex->texco==TEXCO_GLOB) {
VECCOPY(co, xyz);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(R.viewinv, co);
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
}
else continue; // can happen when texco defines disappear and it renders old files
texres.nor= NULL;
if(tex->type==TEX_IMAGE) {
continue; /* not supported yet */
//do_2d_mapping(mtex, texvec, NULL, NULL, dxt, dyt);
}
else {
/* placement */
if(mtex->projx) texvec[0]= mtex->size[0]*(co[mtex->projx-1]+mtex->ofs[0]);
else texvec[0]= mtex->size[0]*(mtex->ofs[0]);
if(mtex->projy) texvec[1]= mtex->size[1]*(co[mtex->projy-1]+mtex->ofs[1]);
else texvec[1]= mtex->size[1]*(mtex->ofs[1]);
if(mtex->projz) texvec[2]= mtex->size[2]*(co[mtex->projz-1]+mtex->ofs[2]);
else texvec[2]= mtex->size[2]*(mtex->ofs[2]);
}
rgbnor= multitex(tex, texvec, NULL, NULL, 0, &texres, 0, mtex->which_output); /* NULL = dxt/dyt, 0 = shi->osatex - not supported */
/* texture output */
if( (rgbnor & TEX_RGB) && (mtex->texflag & MTEX_RGBTOINT)) {
texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
rgbnor-= TEX_RGB;
}
if(mtex->texflag & MTEX_NEGATIVE) {
if(rgbnor & TEX_RGB) {
texres.tr= 1.0-texres.tr;
texres.tg= 1.0-texres.tg;
texres.tb= 1.0-texres.tb;
}
texres.tin= 1.0-texres.tin;
}
if(mtex->texflag & MTEX_STENCIL) {
if(rgbnor & TEX_RGB) {
fact= texres.ta;
texres.ta*= stencilTin;
stencilTin*= fact;
}
else {
fact= texres.tin;
texres.tin*= stencilTin;
stencilTin*= fact;
}
}
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
if((mapto_flag & (MAP_EMISSION_COL+MAP_TRANSMISSION_COL+MAP_REFLECTION_COL)) && (mtex->mapto & (MAP_EMISSION_COL+MAP_TRANSMISSION_COL+MAP_REFLECTION_COL))) {
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
float tcol[3], colfac;
/* stencil maps on the texture control slider, not texture intensity value */
colfac= mtex->colfac*stencilTin;
if((rgbnor & TEX_RGB)==0) {
tcol[0]= mtex->r;
tcol[1]= mtex->g;
tcol[2]= mtex->b;
} else {
tcol[0]=texres.tr;
tcol[1]=texres.tg;
tcol[2]=texres.tb;
if(texres.talpha)
texres.tin= texres.ta;
}
/* inverse gamma correction */
if (R.r.color_mgt_flag & R_COLOR_MANAGEMENT) {
color_manage_linearize(tcol, tcol);
}
/* used for emit */
volume material * data reorganisation - uses own values now instead of reusing surface material properties (i.e. an individual density value, rather than reusing alpha) Files saved with the old system won't load up the same after this. * improved defaults and ui
2009-08-16 06:10:31 +00:00
if((mapto_flag & MAP_EMISSION_COL) && (mtex->mapto & MAP_EMISSION_COL)) {
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
texture_rgb_blend(col, tcol, col, texres.tin, colfac, mtex->blendtype);
}
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
if((mapto_flag & MAP_REFLECTION_COL) && (mtex->mapto & MAP_REFLECTION_COL)) {
texture_rgb_blend(col, tcol, col, texres.tin, colfac, mtex->blendtype);
}
if((mapto_flag & MAP_TRANSMISSION_COL) && (mtex->mapto & MAP_TRANSMISSION_COL)) {
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
texture_rgb_blend(col, tcol, col, texres.tin, colfac, mtex->blendtype);
}
}
if((mapto_flag & MAP_VARS) && (mtex->mapto & MAP_VARS)) {
/* stencil maps on the texture control slider, not texture intensity value */
float varfac= mtex->varfac*stencilTin;
/* convert RGB to intensity if intensity info isn't provided */
if (!(rgbnor & TEX_INT)) {
if (rgbnor & TEX_RGB) {
if(texres.talpha) texres.tin= texres.ta;
else texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
}
}
volume material * data reorganisation - uses own values now instead of reusing surface material properties (i.e. an individual density value, rather than reusing alpha) Files saved with the old system won't load up the same after this. * improved defaults and ui
2009-08-16 06:10:31 +00:00
if((mapto_flag & MAP_EMISSION) && (mtex->mapto & MAP_EMISSION)) {
int flip= mtex->maptoneg & MAP_EMISSION;
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, varfac, mtex->blendtype, flip);
if(*val<0.0) *val= 0.0;
}
volume material * data reorganisation - uses own values now instead of reusing surface material properties (i.e. an individual density value, rather than reusing alpha) Files saved with the old system won't load up the same after this. * improved defaults and ui
2009-08-16 06:10:31 +00:00
if((mapto_flag & MAP_DENSITY) && (mtex->mapto & MAP_DENSITY)) {
int flip= mtex->maptoneg & MAP_DENSITY;
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
volume material * data reorganisation - uses own values now instead of reusing surface material properties (i.e. an individual density value, rather than reusing alpha) Files saved with the old system won't load up the same after this. * improved defaults and ui
2009-08-16 06:10:31 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, varfac, mtex->blendtype, flip);
CLAMP(*val, 0.0, 1.0);
}
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
if((mapto_flag & MAP_SCATTERING) && (mtex->mapto & MAP_SCATTERING)) {
int flip= mtex->maptoneg & MAP_SCATTERING;
volume material * data reorganisation - uses own values now instead of reusing surface material properties (i.e. an individual density value, rather than reusing alpha) Files saved with the old system won't load up the same after this. * improved defaults and ui
2009-08-16 06:10:31 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, varfac, mtex->blendtype, flip);
CLAMP(*val, 0.0, 1.0);
}
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
if((mapto_flag & MAP_REFLECTION) && (mtex->mapto & MAP_REFLECTION)) {
int flip= mtex->maptoneg & MAP_REFLECTION;
volume material * data reorganisation - uses own values now instead of reusing surface material properties (i.e. an individual density value, rather than reusing alpha) Files saved with the old system won't load up the same after this. * improved defaults and ui
2009-08-16 06:10:31 +00:00
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, varfac, mtex->blendtype, flip);
CLAMP(*val, 0.0, 1.0);
Added Ambient channel in "Map To" Panel for materials. Is now means to control AO and Radio with texture too.
2004-04-26 16:49:05 +00:00
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
}
* First commit merging 2.4-based sim_physics in to volume25 branch. Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983 More to come, but this makes things much easier to work on for me :)
2009-08-13 05:21:25 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* ------------------------------------------------------------------------- */
void do_halo_tex(HaloRen *har, float xn, float yn, float *colf)
{
MTex *mtex;
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
TexResult texres= {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0, NULL};
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
float texvec[3], dxt[3], dyt[3], fact, facm, dx;
int rgb, osatex;
Small plumiferos wishlist item. Adds a button next to the threads button to disable texture processing in a render. If anyone doesn't like the button feel free to revert this one, its pretty simple. Kent
2006-12-07 16:48:15 +00:00
if (R.r.scemode & R_NO_TEX) return;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
mtex= har->mat->mtex[0];
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(mtex->tex==NULL) return;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* no normal mapping */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.nor= NULL;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
texvec[0]= xn/har->rad;
texvec[1]= yn/har->rad;
texvec[2]= 0.0;
osatex= (har->mat->texco & TEXCO_OSA);
/* placement */
if(mtex->projx) texvec[0]= mtex->size[0]*(texvec[mtex->projx-1]+mtex->ofs[0]);
else texvec[0]= mtex->size[0]*(mtex->ofs[0]);
if(mtex->projy) texvec[1]= mtex->size[1]*(texvec[mtex->projy-1]+mtex->ofs[1]);
else texvec[1]= mtex->size[1]*(mtex->ofs[1]);
if(mtex->projz) texvec[2]= mtex->size[2]*(texvec[mtex->projz-1]+mtex->ofs[2]);
else texvec[2]= mtex->size[2]*(mtex->ofs[2]);
if(osatex) {
dx= 1.0/har->rad;
if(mtex->projx) {
dxt[0]= mtex->size[0]*dx;
dyt[0]= mtex->size[0]*dx;
}
Three cases of unitialized variables found. Hopefully it fixes the black scanlines error, as reported in #1842, but need MSVC compiler to test it. ;)
2004-11-22 15:32:57 +00:00
else dxt[0]= dyt[0]= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->projy) {
dxt[1]= mtex->size[1]*dx;
dyt[1]= mtex->size[1]*dx;
}
Three cases of unitialized variables found. Hopefully it fixes the black scanlines error, as reported in #1842, but need MSVC compiler to test it. ;)
2004-11-22 15:32:57 +00:00
else dxt[1]= dyt[1]= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->projz) {
dxt[2]= 0.0;
dyt[2]= 0.0;
}
Three cases of unitialized variables found. Hopefully it fixes the black scanlines error, as reported in #1842, but need MSVC compiler to test it. ;)
2004-11-22 15:32:57 +00:00
else dxt[2]= dyt[2]= 0.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
if(mtex->tex->type==TEX_IMAGE) do_2d_mapping(mtex, texvec, NULL, NULL, dxt, dyt);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
rgb= multitex(mtex->tex, texvec, dxt, dyt, osatex, &texres, 0, mtex->which_output);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* texture output */
if(rgb && (mtex->texflag & MTEX_RGBTOINT)) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
rgb= 0;
}
if(mtex->texflag & MTEX_NEGATIVE) {
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= 1.0-texres.tr;
texres.tg= 1.0-texres.tg;
texres.tb= 1.0-texres.tb;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= 1.0-texres.tin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* mapping */
if(mtex->mapto & MAP_COL) {
if(rgb==0) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= mtex->r;
texres.tg= mtex->g;
texres.tb= mtex->b;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->mapto & MAP_ALPHA) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= 1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= texres.ta;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Colour Management - 1st stage: Linear Workflow This implements automatic linear workflow in Blender's renderer. With the new Colour Management option on in the Render buttons, all inputs to the renderer and compositor are converted to linear colour space before rendering, and gamma corrected afterwards. In essence, this makes all manual gamma correction with nodes, etc unnecessary, since it's done automatically through the pipeline. It's all explained much better in the notes/doc here, so please have a look: http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management And an example of the sort of difference it makes: http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg This also enables Colour Management in the default B.blend, and changes the default lamp falloff to inverse square, which is more correct, and much easier to use now it's all gamma corrected properly. Next step is to look into profiles/soft proofing for the compositor. Thanks to brecht for reviewing and fixing some oversights!
2009-07-17 02:43:15 +00:00
/* inverse gamma correction */
if (R.r.color_mgt_flag & R_COLOR_MANAGEMENT) {
color_manage_linearize(&texres.tr, &texres.tr);
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.tin*mtex->colfac;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
facm= 1.0-fact;
if(mtex->blendtype==MTEX_MUL) {
facm= 1.0-mtex->colfac;
}
Three in one: - 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.
2004-07-03 14:18:21 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->blendtype==MTEX_SUB) fact= -fact;
if(mtex->blendtype==MTEX_BLEND) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
colf[0]= (fact*texres.tr + facm*har->r);
colf[1]= (fact*texres.tg + facm*har->g);
colf[2]= (fact*texres.tb + facm*har->b);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->blendtype==MTEX_MUL) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
colf[0]= (facm+fact*texres.tr)*har->r;
colf[1]= (facm+fact*texres.tg)*har->g;
colf[2]= (facm+fact*texres.tb)*har->b;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
colf[0]= (fact*texres.tr + har->r);
colf[1]= (fact*texres.tg + har->g);
colf[2]= (fact*texres.tb + har->b);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
CLAMP(colf[0], 0.0, 1.0);
CLAMP(colf[1], 0.0, 1.0);
CLAMP(colf[2], 0.0, 1.0);
}
}
if(mtex->mapto & MAP_ALPHA) {
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(texres.talpha) texres.tin= texres.ta;
else texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
colf[3]*= texres.tin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
/* ------------------------------------------------------------------------- */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
/* hor and zen are RGB vectors, blend is 1 float, should all be initialized */
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
void do_sky_tex(float *rco, float *lo, float *dxyview, float *hor, float *zen, float *blend, int skyflag, short thread)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
MTex *mtex;
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
TexResult texres= {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0, NULL};
Three in one: - 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.
2004-07-03 14:18:21 +00:00
float *co, fact, stencilTin=1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
float tempvec[3], texvec[3], dxt[3], dyt[3];
int tex_nr, rgb= 0, ok;
Small plumiferos wishlist item. Adds a button next to the threads button to disable texture processing in a render. If anyone doesn't like the button feel free to revert this one, its pretty simple. Kent
2006-12-07 16:48:15 +00:00
if (R.r.scemode & R_NO_TEX) return;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* todo: add flag to test if there's a tex */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.nor= NULL;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Special bf-committers request; Lamp/World/Material now each have 10 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!)
2004-12-04 21:49:02 +00:00
for(tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(R.wrld.mtex[tex_nr]) {
mtex= R.wrld.mtex[tex_nr];
if(mtex->tex==0) continue;
/* if(mtex->mapto==0) continue; */
/* which coords */
co= lo;
More AO fun to play with: - AO energy slider to control amount - option "Use sky color" for colored AO. The horizon color will define bottom diffuse color, the zenith works on top - option "Use sky texture" will do a full sky render to define AO color Please note that AO energy and color only is found when a ray does not intersect. So for interior scenes make sure 'Dist' value is sufficient low. New also is: - World "Map input" allows "Ang Map" (Angular mapping) which can be used for 360 degree spherical maps, aka as Light Probes. Check samples here: http://www.debevec.org/Probes/ Note that Blender doesn't support HDRI images yet, but option "Use sky tex" already gives intersting results with such images - World sky rendering with Image Textures now correctly filters and uses antialiasing. Also noticable for raytrace mirror reflections - World preview render for sky type "Real" now gives correct view as defined by current used camera. I tried to speed up AO tracing with coherence systems, none of it really worked yet... time to tackle octree itself i guess!
2004-04-12 14:53:17 +00:00
/* dxt dyt just from 1 value */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(dxyview) {
dxt[0]= dxt[1]= dxt[2]= dxyview[0];
dyt[0]= dyt[1]= dyt[2]= dxyview[1];
}
else {
dxt[0]= dxt[1]= dxt[2]= 0.0;
dyt[0]= dyt[1]= dyt[2]= 0.0;
}
More AO fun to play with: - AO energy slider to control amount - option "Use sky color" for colored AO. The horizon color will define bottom diffuse color, the zenith works on top - option "Use sky texture" will do a full sky render to define AO color Please note that AO energy and color only is found when a ray does not intersect. So for interior scenes make sure 'Dist' value is sufficient low. New also is: - World "Map input" allows "Ang Map" (Angular mapping) which can be used for 360 degree spherical maps, aka as Light Probes. Check samples here: http://www.debevec.org/Probes/ Note that Blender doesn't support HDRI images yet, but option "Use sky tex" already gives intersting results with such images - World sky rendering with Image Textures now correctly filters and uses antialiasing. Also noticable for raytrace mirror reflections - World preview render for sky type "Real" now gives correct view as defined by current used camera. I tried to speed up AO tracing with coherence systems, none of it really worked yet... time to tackle octree itself i guess!
2004-04-12 14:53:17 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* Grab the mapping settings for this texture */
Added two more mapping types to World buttons for sky render. "Sphere": spherical mapping for a 360 degree panorama "Tube": cylindrical mapping for a 360 degree panorama Both mappings by default do only the sky (upper) hemisphere. The color below is same as regular Horiz and Zenith colors, useful for setting an AO effect. Sample pics: http://www.1000skies.com/fullpanos/index.htm (commercial)
2004-05-07 18:03:40 +00:00
switch(mtex->texco) {
case TEXCO_ANGMAP:
Bugfix #5912 Bugfix #5912 Fix for Angmap and Spheremap (sky render). This is a rewind of bugfix #4999 (sept 18). That bug appeared to be a user error... the option "real" for sky had to be set.
2007-02-04 17:11:18 +00:00
/* only works with texture being "real" */
fact= (1.0/M_PI)*acos(lo[2])/(sqrt(lo[0]*lo[0] + lo[1]*lo[1]));
tempvec[0]= lo[0]*fact;
tempvec[1]= lo[1]*fact;
tempvec[2]= 0.0;
More AO fun to play with: - AO energy slider to control amount - option "Use sky color" for colored AO. The horizon color will define bottom diffuse color, the zenith works on top - option "Use sky texture" will do a full sky render to define AO color Please note that AO energy and color only is found when a ray does not intersect. So for interior scenes make sure 'Dist' value is sufficient low. New also is: - World "Map input" allows "Ang Map" (Angular mapping) which can be used for 360 degree spherical maps, aka as Light Probes. Check samples here: http://www.debevec.org/Probes/ Note that Blender doesn't support HDRI images yet, but option "Use sky tex" already gives intersting results with such images - World sky rendering with Image Textures now correctly filters and uses antialiasing. Also noticable for raytrace mirror reflections - World preview render for sky type "Real" now gives correct view as defined by current used camera. I tried to speed up AO tracing with coherence systems, none of it really worked yet... time to tackle octree itself i guess!
2004-04-12 14:53:17 +00:00
co= tempvec;
Added two more mapping types to World buttons for sky render. "Sphere": spherical mapping for a 360 degree panorama "Tube": cylindrical mapping for a 360 degree panorama Both mappings by default do only the sky (upper) hemisphere. The color below is same as regular Horiz and Zenith colors, useful for setting an AO effect. Sample pics: http://www.1000skies.com/fullpanos/index.htm (commercial)
2004-05-07 18:03:40 +00:00
break;
Bugfix #5912 Bugfix #5912 Fix for Angmap and Spheremap (sky render). This is a rewind of bugfix #4999 (sept 18). That bug appeared to be a user error... the option "real" for sky had to be set.
2007-02-04 17:11:18 +00:00
Added two more mapping types to World buttons for sky render. "Sphere": spherical mapping for a 360 degree panorama "Tube": cylindrical mapping for a 360 degree panorama Both mappings by default do only the sky (upper) hemisphere. The color below is same as regular Horiz and Zenith colors, useful for setting an AO effect. Sample pics: http://www.1000skies.com/fullpanos/index.htm (commercial)
2004-05-07 18:03:40 +00:00
case TEXCO_H_SPHEREMAP:
case TEXCO_H_TUBEMAP:
Bugfix #4558 Thread render error: a flag was stored in read-only data to indicate whether top or bottom hemisphere of sky was rendered. That can't work with tiles (but did work when scanlines were threads).
2006-07-02 07:59:42 +00:00
if(skyflag & WO_ZENUP) {
Bugfix #5912 Bugfix #5912 Fix for Angmap and Spheremap (sky render). This is a rewind of bugfix #4999 (sept 18). That bug appeared to be a user error... the option "real" for sky had to be set.
2007-02-04 17:11:18 +00:00
if(mtex->texco==TEXCO_H_TUBEMAP) tubemap(lo[0], lo[2], lo[1], tempvec, tempvec+1);
else spheremap(lo[0], lo[2], lo[1], tempvec, tempvec+1);
Added two more mapping types to World buttons for sky render. "Sphere": spherical mapping for a 360 degree panorama "Tube": cylindrical mapping for a 360 degree panorama Both mappings by default do only the sky (upper) hemisphere. The color below is same as regular Horiz and Zenith colors, useful for setting an AO effect. Sample pics: http://www.1000skies.com/fullpanos/index.htm (commercial)
2004-05-07 18:03:40 +00:00
/* tube/spheremap maps for outside view, not inside */
tempvec[0]= 1.0-tempvec[0];
/* only top half */
tempvec[1]= 2.0*tempvec[1]-1.0;
tempvec[2]= 0.0;
/* and correction for do_2d_mapping */
tempvec[0]= 2.0*tempvec[0]-1.0;
tempvec[1]= 2.0*tempvec[1]-1.0;
co= tempvec;
}
else {
/* potentially dangerous... check with multitex! */
continue;
}
break;
case TEXCO_OBJECT:
if(mtex->object) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
VECCOPY(tempvec, lo);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(mtex->object->imat, tempvec);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
co= tempvec;
}
Extra texture channel input for Mist effect; "Global". This feeds the global coordinate (from faces) to the sky texture color calculus, this to make textured mist a bit less transparent (was only view coordinate).
2005-12-01 22:16:07 +00:00
break;
case TEXCO_GLOB:
if(rco) {
VECCOPY(tempvec, rco);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(R.viewinv, tempvec);
Extra texture channel input for Mist effect; "Global". This feeds the global coordinate (from faces) to the sky texture color calculus, this to make textured mist a bit less transparent (was only view coordinate).
2005-12-01 22:16:07 +00:00
co= tempvec;
}
else
co= lo;
// VECCOPY(shi->dxgl, shi->dxco);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
// Mat3MulVecfl(R.imat, shi->dxco);
Extra texture channel input for Mist effect; "Global". This feeds the global coordinate (from faces) to the sky texture color calculus, this to make textured mist a bit less transparent (was only view coordinate).
2005-12-01 22:16:07 +00:00
// VECCOPY(shi->dygl, shi->dyco);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
// Mat3MulVecfl(R.imat, shi->dyco);
Extra texture channel input for Mist effect; "Global". This feeds the global coordinate (from faces) to the sky texture color calculus, this to make textured mist a bit less transparent (was only view coordinate).
2005-12-01 22:16:07 +00:00
break;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* placement */
if(mtex->projx) texvec[0]= mtex->size[0]*(co[mtex->projx-1]+mtex->ofs[0]);
else texvec[0]= mtex->size[0]*(mtex->ofs[0]);
if(mtex->projy) texvec[1]= mtex->size[1]*(co[mtex->projy-1]+mtex->ofs[1]);
else texvec[1]= mtex->size[1]*(mtex->ofs[1]);
if(mtex->projz) texvec[2]= mtex->size[2]*(co[mtex->projz-1]+mtex->ofs[2]);
else texvec[2]= mtex->size[2]*(mtex->ofs[2]);
/* texture */
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
if(mtex->tex->type==TEX_IMAGE) do_2d_mapping(mtex, texvec, NULL, NULL, dxt, dyt);
Added two more mapping types to World buttons for sky render. "Sphere": spherical mapping for a 360 degree panorama "Tube": cylindrical mapping for a 360 degree panorama Both mappings by default do only the sky (upper) hemisphere. The color below is same as regular Horiz and Zenith colors, useful for setting an AO effect. Sample pics: http://www.1000skies.com/fullpanos/index.htm (commercial)
2004-05-07 18:03:40 +00:00
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
rgb= multitex(mtex->tex, texvec, dxt, dyt, R.osa, &texres, thread, mtex->which_output);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* texture output */
if(rgb && (mtex->texflag & MTEX_RGBTOINT)) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
rgb= 0;
}
if(mtex->texflag & MTEX_NEGATIVE) {
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= 1.0-texres.tr;
texres.tg= 1.0-texres.tg;
texres.tb= 1.0-texres.tb;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= 1.0-texres.tin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->texflag & MTEX_STENCIL) {
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.ta;
texres.ta*= stencilTin;
Bug fix #1978 Stencil in World didn't work with RGB textures (like what returns from colorbands).
2004-12-06 19:14:53 +00:00
stencilTin*= fact;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.tin;
texres.tin*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
stencilTin*= fact;
}
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(rgb) texres.ta *= stencilTin;
else texres.tin*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 13:18:41 +00:00
/* color mapping */
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->mapto & (WOMAP_HORIZ+WOMAP_ZENUP+WOMAP_ZENDOWN)) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
float tcol[3];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(rgb==0) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= mtex->r;
texres.tg= mtex->g;
texres.tb= mtex->b;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= texres.ta;
Three in one: - 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.
2004-07-03 14:18:21 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
tcol[0]= texres.tr; tcol[1]= texres.tg; tcol[2]= texres.tb;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Colour Management - 1st stage: Linear Workflow This implements automatic linear workflow in Blender's renderer. With the new Colour Management option on in the Render buttons, all inputs to the renderer and compositor are converted to linear colour space before rendering, and gamma corrected afterwards. In essence, this makes all manual gamma correction with nodes, etc unnecessary, since it's done automatically through the pipeline. It's all explained much better in the notes/doc here, so please have a look: http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management And an example of the sort of difference it makes: http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg This also enables Colour Management in the default B.blend, and changes the default lamp falloff to inverse square, which is more correct, and much easier to use now it's all gamma corrected properly. Next step is to look into profiles/soft proofing for the compositor. Thanks to brecht for reviewing and fixing some oversights!
2009-07-17 02:43:15 +00:00
/* inverse gamma correction */
if (R.r.color_mgt_flag & R_COLOR_MANAGEMENT) {
color_manage_linearize(tcol, tcol);
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->mapto & WOMAP_HORIZ) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texture_rgb_blend(hor, tcol, hor, texres.tin, mtex->colfac, mtex->blendtype);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->mapto & (WOMAP_ZENUP+WOMAP_ZENDOWN)) {
ok= 0;
if(R.wrld.skytype & WO_SKYREAL) {
Bugfix #4558 Thread render error: a flag was stored in read-only data to indicate whether top or bottom hemisphere of sky was rendered. That can't work with tiles (but did work when scanlines were threads).
2006-07-02 07:59:42 +00:00
if((skyflag & WO_ZENUP)) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(mtex->mapto & WOMAP_ZENUP) ok= 1;
}
else if(mtex->mapto & WOMAP_ZENDOWN) ok= 1;
}
else ok= 1;
if(ok) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texture_rgb_blend(zen, tcol, zen, texres.tin, mtex->colfac, mtex->blendtype);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
if(mtex->mapto & WOMAP_BLEND) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(rgb) texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
*blend= texture_value_blend(mtex->def_var, *blend, texres.tin, mtex->varfac, mtex->blendtype, 0);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
}
/* ------------------------------------------------------------------------- */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
/* colf supposed to be initialized with la->r,g,b */
Fix for gcc compiler warning about a call to do_lamp_tex() resulting in "overflow in implicit constant conversion"
2008-09-20 09:17:40 +00:00
void do_lamp_tex(LampRen *la, float *lavec, ShadeInput *shi, float *colf, int effect)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Object *ob;
MTex *mtex;
Tex *tex;
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
TexResult texres= {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0, NULL};
Three in one: - 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.
2004-07-03 14:18:21 +00:00
float *co = NULL, *dx = NULL, *dy = NULL, fact, stencilTin=1.0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
float texvec[3], dxt[3], dyt[3], tempvec[3];
coverity issue CID: 596 Checker: FORWARD_NULL (help) File: base/src/source/blender/render/intern/source/texture.c Function: do_lamp_tex Description: Variable "dx" tracked as NULL was dereferenced. Also found a typo the 3rd check was checking projx instead of projz I also expanded the elses to set dyt as well as dxt. Kent
2009-06-18 12:57:39 +00:00
int i, tex_nr, rgb= 0;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Small plumiferos wishlist item. Adds a button next to the threads button to disable texture processing in a render. If anyone doesn't like the button feel free to revert this one, its pretty simple. Kent
2006-12-07 16:48:15 +00:00
if (R.r.scemode & R_NO_TEX) return;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
tex_nr= 0;
Special bf-committers request; Lamp/World/Material now each have 10 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!)
2004-12-04 21:49:02 +00:00
for(; tex_nr<MAX_MTEX; tex_nr++) {
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(la->mtex[tex_nr]) {
mtex= la->mtex[tex_nr];
tex= mtex->tex;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(tex==NULL) continue;
texres.nor= NULL;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* which coords */
if(mtex->texco==TEXCO_OBJECT) {
ob= mtex->object;
if(ob) {
co= tempvec;
dx= dxt;
dy= dyt;
VECCOPY(tempvec, shi->co);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(ob->imat, tempvec);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(shi->osatex) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
VECCOPY(dxt, shi->dxco);
VECCOPY(dyt, shi->dyco);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4Mul3Vecfl(ob->imat, dxt);
Mat4Mul3Vecfl(ob->imat, dyt);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
else {
co= shi->co;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
dx= shi->dxco; dy= shi->dyco;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
else if(mtex->texco==TEXCO_GLOB) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
co= shi->gl; dx= shi->dxco; dy= shi->dyco;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
VECCOPY(shi->gl, shi->co);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat4MulVecfl(R.viewinv, shi->gl);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->texco==TEXCO_VIEW) {
VECCOPY(tempvec, lavec);
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat3MulVecfl(la->imat, tempvec);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Special bf-committers request; Lamp/World/Material now each have 10 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!)
2004-12-04 21:49:02 +00:00
if(la->type==LA_SPOT) {
tempvec[0]*= la->spottexfac;
tempvec[1]*= la->spottexfac;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
co= tempvec;
dx= dxt; dy= dyt;
if(shi->osatex) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
VECCOPY(dxt, shi->dxlv);
VECCOPY(dyt, shi->dylv);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* need some matrix conversion here? la->imat is a [3][3] matrix!!! **/
easier to re-apply the replacement table then merge from 2.4x, same as 23023 replacements... MTC_cross3Float -> Crossf MTC_diff3Float -> VecSubf MTC_dot3Float -> Inpf MTC_Mat3CpyMat4 -> Mat3CpyMat4 MTC_Mat3MulVecd -> Mat3MulVecd MTC_Mat3MulVecfl -> Mat3MulVecfl MTC_Mat4CpyMat4 -> Mat4CpyMat4 MTC_Mat4Invert -> Mat4Invert MTC_Mat4Mul3Vecfl -> Mat4Mul3Vecfl MTC_Mat4MulMat4 -> Mat4MulMat4 MTC_Mat4MulSerie -> Mat4MulSerie MTC_Mat4MulVec4fl -> Mat4MulVec4fl MTC_Mat4MulVecfl -> Mat4MulVecfl MTC_Mat4One -> Mat4One MTC_Mat4Ortho -> Mat4Ortho MTC_Mat4SwapMat4 -> Mat4SwapMat4
2009-09-06 00:36:26 +00:00
Mat3MulVecfl(la->imat, dxt);
Mat3MulVecfl(la->imat, dyt);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
VecMulf(dxt, la->spottexfac);
VecMulf(dyt, la->spottexfac);
}
}
/* placement */
coverity issue CID: 44 Checker: FORWARD_NULL (help) File: base/src/source/blender/render/intern/source/texture.c Function: do_lamp_tex Description: Variable "co" tracked as NULL was dereferenced. co was set to NULL at the beginning of the function and it could possibly slip through all the logic above so lets test it before we use it blindly. Kent
2009-06-13 15:54:39 +00:00
if(mtex->projx && co) texvec[0]= mtex->size[0]*(co[mtex->projx-1]+mtex->ofs[0]);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
else texvec[0]= mtex->size[0]*(mtex->ofs[0]);
coverity issue CID: 44 Checker: FORWARD_NULL (help) File: base/src/source/blender/render/intern/source/texture.c Function: do_lamp_tex Description: Variable "co" tracked as NULL was dereferenced. co was set to NULL at the beginning of the function and it could possibly slip through all the logic above so lets test it before we use it blindly. Kent
2009-06-13 15:54:39 +00:00
if(mtex->projy && co) texvec[1]= mtex->size[1]*(co[mtex->projy-1]+mtex->ofs[1]);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
else texvec[1]= mtex->size[1]*(mtex->ofs[1]);
coverity issue CID: 44 Checker: FORWARD_NULL (help) File: base/src/source/blender/render/intern/source/texture.c Function: do_lamp_tex Description: Variable "co" tracked as NULL was dereferenced. co was set to NULL at the beginning of the function and it could possibly slip through all the logic above so lets test it before we use it blindly. Kent
2009-06-13 15:54:39 +00:00
if(mtex->projz && co) texvec[2]= mtex->size[2]*(co[mtex->projz-1]+mtex->ofs[2]);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
else texvec[2]= mtex->size[2]*(mtex->ofs[2]);
if(shi->osatex) {
coverity issue CID: 596 Checker: FORWARD_NULL (help) File: base/src/source/blender/render/intern/source/texture.c Function: do_lamp_tex Description: Variable "dx" tracked as NULL was dereferenced. Also found a typo the 3rd check was checking projx instead of projz I also expanded the elses to set dyt as well as dxt. Kent
2009-06-18 12:57:39 +00:00
if (!dx) {
for(i=0;i<2;i++) {
dxt[i] = dyt[i] = 0.0;
}
} else {
if(mtex->projx) {
dxt[0]= mtex->size[0]*dx[mtex->projx-1];
dyt[0]= mtex->size[0]*dy[mtex->projx-1];
} else {
dxt[0]= 0.0;
dyt[0]= 0.0;
}
if(mtex->projy) {
dxt[1]= mtex->size[1]*dx[mtex->projy-1];
dyt[1]= mtex->size[1]*dy[mtex->projy-1];
} else {
dxt[1]= 0.0;
dyt[1]= 0.0;
}
if(mtex->projz) {
dxt[2]= mtex->size[2]*dx[mtex->projz-1];
dyt[2]= mtex->size[2]*dy[mtex->projz-1];
} else {
dxt[2]= 0.0;
dyt[2]= 0.0;
}
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
/* texture */
if(tex->type==TEX_IMAGE) {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
do_2d_mapping(mtex, texvec, NULL, NULL, dxt, dyt);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
rgb= multitex(tex, texvec, dxt, dyt, shi->osatex, &texres, shi->thread, mtex->which_output);
- tex->nor was not reset to zero for lamp texture. this caused weird thing to happen when you use lamp textures with material textures. Bug provided by aphex, thanks!
2004-01-11 20:58:12 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* texture output */
if(rgb && (mtex->texflag & MTEX_RGBTOINT)) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= (0.35*texres.tr+0.45*texres.tg+0.2*texres.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
rgb= 0;
}
if(mtex->texflag & MTEX_NEGATIVE) {
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= 1.0-texres.tr;
texres.tg= 1.0-texres.tg;
texres.tb= 1.0-texres.tb;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= 1.0-texres.tin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
if(mtex->texflag & MTEX_STENCIL) {
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.ta;
texres.ta*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
stencilTin*= fact;
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
fact= texres.tin;
texres.tin*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
stencilTin*= fact;
}
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
if(rgb) texres.ta*= stencilTin;
else texres.tin*= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* mapping */
Patch #13422, By Roland Hess, Shadow Color Finally, after a long time new render candy for the non-game peoples! :) Good doc is here: (url splits in two) http://www.harkyman.com/2008/08/06/controllable-shadow-intensity- and-color/ Note the colorpicker for shadow is in "Shadow and Spot" panel. A bit hidden, could get more attention. For later. :)
2008-09-19 16:01:22 +00:00
if(((mtex->mapto & LAMAP_COL) && (effect & LA_TEXTURE))||((mtex->mapto & LAMAP_SHAD) && (effect & LA_SHAD_TEX))) {
Three in one: - 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.
2004-07-03 14:18:21 +00:00
float col[3];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(rgb==0) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tr= mtex->r;
texres.tg= mtex->g;
texres.tb= mtex->b;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else if(mtex->mapto & MAP_ALPHA) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texres.tin= stencilTin;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
else texres.tin= texres.ta;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
Colour Management - 1st stage: Linear Workflow This implements automatic linear workflow in Blender's renderer. With the new Colour Management option on in the Render buttons, all inputs to the renderer and compositor are converted to linear colour space before rendering, and gamma corrected afterwards. In essence, this makes all manual gamma correction with nodes, etc unnecessary, since it's done automatically through the pipeline. It's all explained much better in the notes/doc here, so please have a look: http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management And an example of the sort of difference it makes: http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg This also enables Colour Management in the default B.blend, and changes the default lamp falloff to inverse square, which is more correct, and much easier to use now it's all gamma corrected properly. Next step is to look into profiles/soft proofing for the compositor. Thanks to brecht for reviewing and fixing some oversights!
2009-07-17 02:43:15 +00:00
/* inverse gamma correction */
if (R.r.color_mgt_flag & R_COLOR_MANAGEMENT) {
color_manage_linearize(&texres.tr, &texres.tr);
}
Three in one: - 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.
2004-07-03 14:18:21 +00:00
/* lamp colors were premultiplied with this */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
col[0]= texres.tr*la->energy;
col[1]= texres.tg*la->energy;
col[2]= texres.tb*la->energy;
Three in one: - 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.
2004-07-03 14:18:21 +00:00
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texture_rgb_blend(colf, col, colf, texres.tin, mtex->colfac, mtex->blendtype);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
}
}
}
/* ------------------------------------------------------------------------- */
ImagePaint Refactoring: - ImagePaint now uses ImBuf directly, and the rect blending functions were moved into the imbuf module. - The brush spacing, timing and sampling was abstracted into brush.c, for later reuse in other paint modes. Float ImagePaint support. Textured Brushes: - Only the first texture channel is used now. - Options for size and offset should be added, but need to find some space in the panel, or add a second one ..
2006-07-31 15:53:03 +00:00
int externtex(MTex *mtex, float *vec, float *tin, float *tr, float *tg, float *tb, float *ta)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Tex *tex;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
TexResult texr;
float dxt[3], dyt[3], texvec[3];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
int rgb;
tex= mtex->tex;
Bugfix #4830 Preview render in 3d window: when window type changes (like 3d window to UV window), and you change the window size, and restore to 3d view, the rendered preview had to be re-initialized. texture.c: a return was added without value.
2006-08-09 10:49:52 +00:00
if(tex==NULL) return 0;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texr.nor= NULL;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* placement */
if(mtex->projx) texvec[0]= mtex->size[0]*(vec[mtex->projx-1]+mtex->ofs[0]);
else texvec[0]= mtex->size[0]*(mtex->ofs[0]);
if(mtex->projy) texvec[1]= mtex->size[1]*(vec[mtex->projy-1]+mtex->ofs[1]);
else texvec[1]= mtex->size[1]*(mtex->ofs[1]);
if(mtex->projz) texvec[2]= mtex->size[2]*(vec[mtex->projz-1]+mtex->ofs[2]);
else texvec[2]= mtex->size[2]*(mtex->ofs[2]);
/* texture */
if(tex->type==TEX_IMAGE) {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
do_2d_mapping(mtex, texvec, NULL, NULL, dxt, dyt);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
2.5: merge with trunk, previous merge was only up to yesterday. svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r17416:HEAD
2008-11-12 22:03:11 +00:00
rgb= multitex(tex, texvec, dxt, dyt, 0, &texr, 0, mtex->which_output);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(rgb) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texr.tin= (0.35*texr.tr+0.45*texr.tg+0.2*texr.tb);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
else {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
texr.tr= mtex->r;
texr.tg= mtex->g;
texr.tb= mtex->b;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
*tin= texr.tin;
*tr= texr.tr;
*tg= texr.tg;
*tb= texr.tb;
*ta= texr.ta;
ImagePaint Refactoring: - ImagePaint now uses ImBuf directly, and the rect blending functions were moved into the imbuf module. - The brush spacing, timing and sampling was abstracted into brush.c, for later reuse in other paint modes. Float ImagePaint support. Textured Brushes: - Only the first texture channel is used now. - Options for size and offset should be added, but need to find some space in the panel, or add a second one ..
2006-07-31 15:53:03 +00:00
return (rgb != 0);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
/* ------------------------------------------------------------------------- */
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
void render_realtime_texture(ShadeInput *shi, Image *ima)
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
{
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
TexResult texr;
Bugfix: image texture with texface would not render sometimes, wasn't setting image user correct. Also found that this texface rendering was not threadsafe for > 2 threads.
2008-03-17 12:27:17 +00:00
static Tex imatex[BLENDER_MAX_THREADS]; // threadsafe
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
static int firsttime= 1;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
Tex *tex;
Two hours of fixing details based on Klocwork source review. Useful report, although it has a lot of noise. Not to mention our bad string code gives a load of warnings. I've reviewed specifically: - file reading/write - dna and library code - node system - entire render module Done a couple of files in src/ too, seemed to be nice errors.
2006-12-01 19:52:04 +00:00
float texvec[3], dx[2], dy[2];
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
ShadeInputUV *suv= &shi->uv[shi->actuv];
Bugfix: image texture with texface would not render sometimes, wasn't setting image user correct. Also found that this texface rendering was not threadsafe for > 2 threads.
2008-03-17 12:27:17 +00:00
int a;
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
Fix for bug #12334: the Disable Tex option didn't disable textures for the Texface material option.
2008-05-22 13:46:05 +00:00
if(R.r.scemode & R_NO_TEX) return;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
if(firsttime) {
Bugfix: image texture with texface would not render sometimes, wasn't setting image user correct. Also found that this texface rendering was not threadsafe for > 2 threads.
2008-03-17 12:27:17 +00:00
BLI_lock_thread(LOCK_IMAGE);
if(firsttime) {
for(a=0; a<BLENDER_MAX_THREADS; a++) {
memset(&imatex[a], 0, sizeof(Tex));
default_tex(&imatex[a]);
imatex[a].type= TEX_IMAGE;
}
firsttime= 0;
}
BLI_unlock_thread(LOCK_IMAGE);
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Bugfix: image texture with texface would not render sometimes, wasn't setting image user correct. Also found that this texface rendering was not threadsafe for > 2 threads.
2008-03-17 12:27:17 +00:00
tex= &imatex[shi->thread];
tex->iuser.ok= ima->ok;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... 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!
2004-12-27 19:28:52 +00:00
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
texvec[0]= 0.5+0.5*suv->uv[0];
texvec[1]= 0.5+0.5*suv->uv[1];
initalize texvec[2] even though its not used, imagewrap checks to make sure its in a given range. Kent
2007-06-05 19:39:19 +00:00
texvec[2] = 0; // initalize it because imagewrap looks at it.
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
if(shi->osatex) {
Render Instancing ================= Big commit, but little user visible changes. - Dupliverts and duplifaces are now rendered as instances, instead of storing all of the geometry for each dupli, now an instance is created with a matrix transform refering to the source object. This should allow us to render tree leaves more memory efficient. - Radiosity and to some degree raytracing of such objects is not really efficient still. For radiosity this is fundamentally hard to solve, but raytracing an octree could be created for each object, but the current octree code with it's fixed size doesn't allow this efficiently. - The regression tests survived, but with I expect that some bugs will pop up .. hopefully not too many :). Implementation Notes ==================== - Dupligroups and linked meshes are not rendered as instances yet, since they can in fact be different due to various reasons, instancing of these types of duplis that are the same can be added for them at a later point. - Each ObjectRen now stores it's own database, instead of there being one big databases of faces, verts, .. . Which objects that are actually rendered are defined by the list of ObjectRenInstances, which all refer to an ObjectRen. - Homogeneous coordinatess and clipping is now not stored in vertices anymore, but instead computed on the fly. This couldn't work for instances. That does mean some extra computation has to be done, but memory lookups can be slow too, and this saves some memory. Overall I didn't find a significant speed impact. - OSA rendering for solid and ztransp now is different. Instead of e.g. going 8 times over the databases times and rendering the z-buffer, it now goes over the database once and renders each polygon 8 times. That was necessary to keep instances efficient, and can also give some performance improvement without instances. - There was already instancing support in the yafray export code, now it uses Blender's render instances for export. - UV and color layer storage in the render was a bit messy before, now should be easier to understand. - convertblender.c was reorganized somewhat. Regular render, speedvector and baking now use a single function to create the database, previously there was code duplicated for it. - Some of these changes were done with future multithreading of scene and shadow buffer creation in mind, though especially for scene creation much work remains to be done to make it threadsafe, since it also involves a lot of code from blenkernel, and there is an ugly conflict with the way dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
dx[0]= 0.5*suv->dxuv[0];
dx[1]= 0.5*suv->dxuv[1];
dy[0]= 0.5*suv->dyuv[0];
dy[1]= 0.5*suv->dyuv[1];
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
texr.nor= NULL;
2.5: Bump Mapping Patch by Alfredo de Greef. Considerably improves the quality of bump mapping, and texture filtering for displacement and warp too. Mainly this is achieved by getting the texture derivatives just right in various cases, many thanks to Alfredo for figuring this one out, works great. This is enabled by default now, but disabled still for existing textures to preserve backwards compatibility. Can be enabled with the "New Bump" option in the material texture slot in the outliner. Also, I made the range for the normal factor a bit smaller since this gives stronger effects, but note that you can still type in larger values than the slider allows.
2009-07-21 13:46:49 +00:00
if(shi->osatex) imagewraposa(tex, ima, NULL, texvec, dx, dy, &texr);
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
else imagewrap(tex, ima, NULL, texvec, &texr);
Added another 2 checks for if an image has the premul flag set, 1 in the image compositor node, another in render_realtime_texture. Note that multilayer images in the image compositor node do not respect the premul flag (though I did write commented out code for it). As far as I can tell, the premul option never worked for multilayer images in the image node, so I'm a little nervous about making it work properly there. ton, any comments?
2008-02-14 13:36:59 +00:00
Added names to UV and vertex color layers, and display them as a list. Added support for multiple UVs in the render engine. This also involved changing the way faces are stored, to allow data to be added optionally per 256 faces, same as the existing system for vertices. A UV layer can be specified in the Map Input panel and the Geometry node by name. Leaving this field blank will default to the active UV layer. Also added sharing of face selection and hiding between UV layers, and at the same time improved syncing with editmode selection and hiding. Still to do: - Multi UV support for fastshade. - Multires and NMesh preservation of multiple UV sets.
2006-12-21 13:47:27 +00:00
shi->vcol[0]*= texr.tr;
shi->vcol[1]*= texr.tg;
shi->vcol[2]*= texr.tb;
* New material option: TexFace Alpha This is an additional option for 'TexFace', which uses the alpha of the UV assigned faces as well as the colour. It appears in material buttons as a little 'A' button next to 'TexFace', when 'TexFace is switched on. It's a bit horrible, but no point tweaking that layout in isolation at this stage. This image is using texface alpha, with different assigned images, all sharing the one material: http://mke3.net/blender/devel/rendering/texface_alpha.jpg Usually I consider texface (and teaching people to use it for UV mapping) to be pretty evil, but in some cases, when you have lots of separate images that you want to control in the one material, it can be quite handy.
2007-11-15 00:11:00 +00:00
shi->vcol[3]*= texr.ta;
Phew, a lot of work, and no new features... 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!
2003-12-21 21:52:51 +00:00
}
/* eof */
Copy Permalink